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

[Shawn M. Emery]

Gary Winiger wrote:
>>>> This is left untouched as well.
>>>>     
>>>>         
>>> 	Now I am confused.  The default delivered pam.conf(4) doesn't
>>> 	deliver account management, password or session entries for
>>> 	pam_krb5(5).  Are you saying these stacks are unnecessary and
>>> 	the pam_krb5(5) man page is incorrect?
>>>   
>>>       
>> The man page describes various permutations of these stacks.  Which one 
>> is incorrect?  That is difficult to know.  Should we provide another 
>> interface that we can specify the control flag and hope that they know 
>> which account authorities will be updated during change password?
>>     
>
> 	Let's try again.  I initially asked about the stacks other than
> 	the auth stack and how that related to the -s option.  I understood
> 	you to say that nothing was done with them: "This is left untouched
> 	as well."  So I tried to ask how the other stacks were intended
> 	to be populated in the pam.conf file.  If they were unnecessary,
> 	then why were they shown in pam_krb5(5) and why does the default
> 	pam.conf(4) state:
> # Support for Kerberos V5 authentication and example configurations can
> # be found in the pam_krb5(5) man page under the "EXAMPLES" section.
>
> 	So, I'm confused about what this project is doing or recommending
> 	relative to the -s option.
>
>   
>>> 	As I read kclient, I would have expected all I needed to correctly
>>> 	configure a service would have been -s <service>.
>>> 	If that's not the case, then it seems to me that either the
>>> 	pam_krb5(5) man page needs correction, or kclient needs to do more
>>> 	work, or the kclient man page needs to say -s only does part of the
>>> 	job and the admin must use $EDITOR to do the rest as described on
>>> 	the pam_krb5(5) man page.
>>>       
>> The point was to cover a broad range of environments w/o having to know 
>> about control flags and their affects.  But if this is not sufficient we 
>> need to either increase the complexity of the interface or make more 
>> assumptions of their environment.
>>     
>
> 	From the project spec and the various man pages and the default
> 	pam.conf, I don't know what is sufficient.  If adding a single
> 	line to the auth stack of a service will do it or not.
> 	What if that service is not in the existing pam.conf file, does
> 	it take the default service stack and replicate it adding pam_krb5?
> 	
> 	I'm having trouble understanding the efficacy of -s.
>   

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?

Shawn.
--