On Wed, Sep 05, 2001 at 05:51:00PM -0500, Steve Langasek wrote: > 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). >From a literalist POV, clearly, PAM_REFRESH_CRED coincides with the act of renewing a [renewable] Kerberos ticket. >From a literalist POV, clearly, PAM_ESTABLISH_CRED coincides with the act of creating a Kerberos ticket cache. And I accept Steve's literalist take on PAM_REINITIALIZE_CRED, which would coincide with the act of getting new Kerberos creds and updating an existing ccache with them (because the creds in that ccache might be expired, and therefore non-renewable). This means that PAM_KRB5's setcred() might have to prompt for a password when called to PAM_REINITIALIZE_CRED. This is quite different from what I was yesterday taking OpenSSH's interpretation of PAM_REINITIALIZE_CRED to mean. Why should OpenSSH bother calling pam_setcred(PAM_REINITIALIZE_CRED)? Here's the comment from the source: /* * PAM credentials may take the form of * supplementary groups. These will have been * wiped by the above initgroups() call. * Reestablish them here. */ Is this, then, in case one has a PAM module which implements its own initgroups()? What is, then, the correct behaviour for PAM_KRB5's setcred() when called to PAM_REINITIALIZE_CRED? Taking Steve's literalist approach one would think that should be: check for expired creds in the [default] ccache and, if there are expired creds then call krb5_get_init_creds_password() with a prompter function that uses the PAM conversation function to get new creds and store them in that ccache. > 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. Well, see above. It might well be usefule to have a "check if the creds are expired and, if so, delete them then establish new ones." > > >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: Yes, I see that now. Thanks Darren, Steve. > > "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. Your literal interpretation of PAM_REINITIALIZE_CREDS has inspired me :) -- see above. > > >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. I guess we could make it so the ccache is user-owned unless the calling app lacks the privs needed to do so, in which case the ccache should be euid-owned, yes? > > 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 Cheers, Nico -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
