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

[Darren Moffat]

>> >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.

Oops.  I meant PAM_REFRESH_CRED

>PAM_RENEW_CREDS is there for credential renewal (i.e., ticket renewal,
>in the Kerberos case). That's clear from its name.

It is called PAM_REFRESH_CRED.

>PAM_REINITIALIZE_CREDS is, well, completely undocumented (I'll recheck
>the XSSO docs). The OpenSSH interpretation is clear.

Agreed and it is very ambiquous.  I think it is quite easy to make
the assumption that ESTABLISH and REINITIALIZE care synonymous but both
are different from REFRESH.

>And, IMO, as I think about it, the OpenSSH interpretation makes plenty
>of sense. Consider an app that will not fork() a child that runs as the
>PAM_USER (e.g., a web server) but which nonetheless needs the user's
>Kerberos creds -- why bother creating a user-owned ccache then?

I can see that from a PAM view point but it won't really work from
a Kerberos view point (it isn't how kerberos was designed to work).

>> "The pam_setcred() function is used to establish, modify, or delete the 
>> credentials of the current user associated with the authentication handle,
>> pamh. "
>
>Why does that description not jive with my interpretation of the OpenSSH
>interpretation of the pam_setcred() flags' semantics? I mean, I don't
>see why.

I guess it does at the PAM level but at the level of Kerberos the creds
are always placed in a cred file owned by that user since their is no
concept of acting onbehalf of another.

>I've written parts of a PAM_KRB5 (based on Frank Cusack's original)
>which behaves slightly differently: its auth method saves the user's
>Kerberos creds in a memory ccache and stuffs that into the pam handle as
>pam data, and its setcred method actually creates the file ccache (and
>destroys the memory ccache).

The Solaris one does that as well, the ccache file is created as
	/tmp/krb5cc_<uid> with permissions 600 and owner <uid>

>> 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).
>
>This is silly -- why create a user-owned ccache *before* the account
>management part of PAM has been called and suceeded??

Because you are supposed to call pam functions in this order:

pam_start(pamh,...);
pam_authenticate(pamh, ...);
pam_acct_mgmt(pamh, 
pam_setcred(pamh, PAM_ESTABLISH_CRED)
...
pam_setcred(pamh, PAM_DELETE_CRED);
pam_end(pamh);


This is quite clear from the Solaris man page for pam_setcred(3pam)

"    The pam_setcred() function is used to establish, modify,  or
     delete  user  credentials.  It is typically called after the
     user has been authenticated and after  a  session  has  been
     opened.   See  pam_authenticate(3PAM),  pam_acct_mgmt(3PAM),
     and pam_open_session(3PAM).
"     


>In fact, it seems clear to me that no user-owned ccache should be
>created outside pam_krb5:pam_sm_setcred().

In Solaris it isn't.

>> 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 ?
>
>See above about apps that don't fork() a process that runs as the
>PAM_USER.

I don't believe that is well defined for Kerberos and it isn't how
pam_krb5 in Solaris is designed to work.

--
Darren J Moffat