[Fwd: kclient version 2 [PSARC/2007/401 FastTrack timeout 07/13/2007]]

Darren J Moffat Darren.Moffat at Sun.COM
Fri Jul 13 04:48:22 PDT 2007


Shawn M. Emery wrote:
> The -s option will place a pam_krb5(5) auth entry in the specified 
> service stack.  If the service stack does not exist it could base the 
> new stack off of the "other" stack and place the entry after the 
> pam_unix_cred(5).  If the other module types were to be included I could 
> make an assumption that they are performing password/account expiration 
> and that the only auth tok to be changed is Kerberos.  Any failure would 
> be considered optional and would continue with the other modules.  Is 
> this a safe assumption for most cases?

I think that is actually a bad idea and could easily lead to quite 
strange configurations.   Past experience with modifying the pam.conf 
has show that it is unfortunately very complex as soon as there is a 
single change from one of the default versions we have shipped.

I think this area needs some more thought.  I suspect what what we 
really want to do with kclient is put the pam.conf file in to one of the 
known good and recommended states that is documented in pam_krb5(5) already.

Maybe this project should be using PSARC 2005/217 and delivering one of 
more include files that have the different recommended ways of using 
pam_krb5.


-- 
Darren J Moffat



More information about the opensolaris-arc mailing list