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

[Darren J Moffat]

Shawn M. Emery wrote:
>> 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.
> 
> 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

That is interesting but it assumes you always want it at the end.  As 
you can see this is quite complex.

I think that setting up pam.conf to do one of the normal Kerberos 
configurations is a key part of this project.

My recommendation is that the kclient interface be quite high level eg:

As per the pam_krb5(5) examples: first, only, optional are the keywords 
here.

kclient should (probably in conjunction with some other part of the 
system that we can work out offline) only update the pam.conf file if it 
is in a known original state.

If there are any customisations to pam.conf for the  services listed 
then kclient should not attempt to change those.  It is just too hard to 
work out where the correct place to put the module in a customised stack 
is.  In this case it should tell the operator that they must do it 
themselves.

-- 
Darren J Moffat