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