>Neither the Sun PAM documentation nor the Linux-PAM documentation >describe the semantics of PAM_REINITIALIZE_CREDS in any useful detail. I would agree it is vague, but then that is also a problem with the XSSO document (http://www.opengroup.org/onlinepubs/008329799/) >Could we please have a clarification on the semantics of >PAM_CRED_ESTABLISH vs. the semantics of PAM_REINITIALIZE_CREDS? My interpretation is: You call PAM_ESTABLISH_CRED to create them You call PAM_REINITIALIZE_CRED to update creds that can expire over time, for example a kerberos ticket. >My guess, given what OpenSSH does with PAM: PAM_CRED_ESTABLISH means >"make it so we can use your module's credentials as root" whereas >PAM_REINITIALIZE_CREDS means "make it so we can use your module's >credentials as pam_get_item(PAM_USER)." That is wrong and is one thing the XSSO doc is clear on: "The pam_setcred() function is used to establish, modify, or delete the credentials of the current user associated with the authentication handle, pamh. " The Solaris pam_setcred(3pam) man page is less clear - I'll file a man page bug for Solaris to get it clarified better. >And, given what OpenSSH does, it seems that >pam_setcred(PAM_REINITIALIZE_CREDS) should be called with >(euid==0 || uid==0) and gid/egid/groups setup to be the PAM_USER's. That depends and unfortunately the whole issue of what the uids should be in effect for the application calling any pam_* function is not specified. For Kerberos it will work just fine if called as the PAM_USER but for Secure RPC creds that get established in pam_unix on Solaris there are some times that the euid needs to be root. Also for doing getspnam lookups to statisfy pam_authenticate when using /etc/shadow. >But none of this is documented! Agreed the docs do not specify the level of privilege required by the application for calling pam_* functions. In someways I think it should be upto the modules to document what they need but I also think this could break the abstraction that PAM is supposed to provide. >As for PAM_KRB5, assuming my interpretation of PAM_REINITIALIZE_CREDS is >correct, it should create a root-owned ccache when it's pam_sm_setcred() >is called to PAM_CRED_ESTABLISH and it should create PAM_USER-owned >ccache when it's pam_sm_setcred() is called to PAM_REINITIALIZE_CREDS. That is not how pam_krb5 on Solaris is designed to work. If you call pam_setcred() with pam_krb5 on the stack it assumes that you have already called pam_authenticate to get the kerberos password and do the kerberos authentication. That is fine for the case that started this disucssion since pam_authenticate had been called since password authentication was used. It will always create a cred cache file owned by PAM_USER, the only way you could get the effect you describe above is if you called pam_setcred with PAM_USER as root, changed PAM_USER using pam_set_item to be <user> - but this isn't what OpenSSH does (and it is wrong anyway). I'm not sure the call to pam_setcred with PAM_REINITIALIZE_CREDS is actually required in session.c. Why was it put there ? Is there a particular pam module that causes a problem ? -- Darren J Moffat
