On Wed, 5 Sep 2001, Darren Moffat wrote: > >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. Coming at this purely from a literalist POV, the terminology 'REINITIALIZE_CRED' implies to me that the credentials will be returned to an /initial/ state, i.e., this is somehow analogous to calling setcred(PAM_DELETE_CRED) followed by setcred(PAM_ESTABLISH_CRED). Practically speaking, I don't see where anything further than ESTABLISH, REFRESH, and DELETE is required; either REINITIALIZE is equivalent to one of the first three, in which case it should be deprecated to reduce confusion, or it has a meaning outside of the first three, in which case it should be clearly determined what that meaning is before people try to make use of it in code. > >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. " Agreed; it's counter-intuitive that a simple application which needs the credentials for only a short period of time should need to do anything more than setcred(ESTABLISH) at the beginning and setcred(DELETE) when the credentials are no longer needed. > >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. I think it's important for abstraction that this be specified. This lack of specification has more than once caused problems for both module writers and application writers. > 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). Does Solaris pam_krb5 fail gracefully if the calling application cannot setuid(PAM_USER)? As Nico rightly points out, PAM is not unique to applications that establish local Unix security contexts as the given user. Steve Langasek postmodern programmer
