On Linux all it takes is for Jenkins to be able to read /etc/shadow. We now explicitly check for the permission to access this file and provide a friendly error message.

I wonder if this bug report predates that change, or if Solaris behaves differently.

Hey Kohsuke,

I have not worked at that job since 2009 (this was reported May 2009) - so it very well could predate that change.

Comparing hashes in the shadow file is NOT PAM authentication. What if I am authenticating against LDAP/Kerberos/Active Directory? That has nothing to do with the shadow file, yet the module still unhelpfully requires it to be readable.

~tommy

I'm trying to use pam_exec.so to authenticate using a script. I created a PAM service called "jenkins" (/etc/pam.d/jenkins) with "auth" and "account" lines. Authentication succeeds, but I see this in the Jenkins log: "org.jvnet.libpam.PAMException: Authentication succeeded but no user information is available". I believe the problem described in this ticket results from the fact that libpam4j attempts to retrieve an account record using the libc function getpwnam() rather than relying solely on PAM calls.

https://github.com/kohsuke/libpam4j/blob/377d71a2b73c11b7c21bea0fb4ac5050ba8fc5c9/src/main/java/org/jvnet/libpam/PAM.java

I have been using the Security Realm by custom script (script-realm) Jenkins plugin to authenticate via script, which has been working fine without any entries in /etc/passwd. However, that plugin is unmaintained and pulls in the deprecated WMI Windows Agents Plugin, so I tried replacing it with a PAM configuration. Since I don't want to have to modify /etc/passwd, I'll probably find a different solution.