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

[Darren Moffat]

>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