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

[Shawn M. Emery]

Gary Winiger wrote:
>> Setting include files apart there still should be a way of specifying 
>> how Kerberos interacts with other modules.  -s could include a qualifier 
>> for pam_krb5's control flag with:
>>
>> -s service_name:{binding | sufficient | optional | required | 
>> requisite}[,...]
>>
>> As an example:
>>
>> -s xscreensaver:optional,dtlogin:optional
>>     
>      ^^^^^^^^^^^^
>
>   
>> would configure files:
>>     
> [snip]
>   
>> other auth required           pam_unix_auth.so.1
>> other auth optional           pam_krb5.so.1
>>     
>   ^^^^^
>
> 	I'm missing seeing the correlation between service name and this
> 	example.
>   
In the above example these are the contents of the include file, so 
pam.conf would only have the service name specified configured.

> 	In any case, I'm concerned that unless pam.conf is the default
> 	one delivered changing the other stacks, or cloning the other
> 	stacks for the -s specified services and adding pam_krb5.so.1
> 	optional or otherwise is a wise thing to do.
>
> 	I do believe that there's value in kclient being able to completely
> 	set up a kerberos client even (or especially) for sites with pam.conf
> 	changes in other areas.  That's why I seconded Darren's comments
> 	about using include.
>   

I would rather produce an error message to the administrator for the 
case that the pam.conf file already had a stack for the service name 
specified with -s that didn't match a vanilla version.

Shawn.
--