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

[Shawn M. Emery]

Darren J Moffat wrote:
> 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.

Given the complexity of the interface necessary to do this and the 
difficulty to represent all customer environments I will drop the -s 
option from kclient.

Shawn.
--