DragonFlyBSD

On Sat, Feb 18, 2006 at 11:45:21AM -0500, nida@musc.edu wrote:

I'm still having a problem getting qpopper (and now courier-{pop|imap}) to
authenticate using pam. Both systems report a similar message in
/var/log/messages whenever a login is invoked. As I mentioned, the error
happens for both the imap and pop pam.d/ entries.

service: in openpam_load_module(): no pam_unix.so found

I have hardcoded the path to pam_unix.so (/usr/lib/security/pam_unix.so), but
that doesn't work. The permissions are as such:

lrwxr-xr-x 1 root wheel 13B Feb 18 04:27 pam_unix.so > pam_unix.so.1
-r--r--r- 1 root wheel 9.7K Feb 18 04:27 pam_unix.so.1

The machine was freshly (re)installed with the 1.4 release, and just updated to
1.4.1 last night. Before the update, the permissions on pam_unix.so.1
were 777 and I still got the error.

No, don't set it to world-writable, and you don't need executable
bits for shared libraries.

openpam_load_module() says "no pam_XXX.so found" when the module
failed to load. It failed loading because of a missing symbol
login_getpwclass, which is defined in libutil, but qpopper isn't
linked against it. The following command installs qpopper linked
against libutil, but it doesn't seem to be a correct solution though.

1. env LIBS=-lutil bmake install

Cheers.

On Sun, Feb 19, 2006 at 04:28:56AM +0900, YONETANI Tomokazu wrote:

openpam_load_module() says "no pam_XXX.so found" when the module
failed to load. It failed loading because of a missing symbol
login_getpwclass, which is defined in libutil, but qpopper isn't
linked against it. The following command installs qpopper linked
against libutil, but it doesn't seem to be a correct solution though.

I hate programs doing nasty stuff in fork() without allowing non-daemon
operation. Yeah, I've been looking at it today as well -- pam_unix
wasn't linked with -lutil.

/me slaps himself for not seeing the obvious problem when pam_permit.so
worked.

Joerg