Re: reinit_creds (was Re: OpenSSHd barfs upon reauthentication: PAM,Solaris 8)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux