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

[Shawn M. Emery]

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

Its behavior is how I interpret something of being optional in quality.

> 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.

I don't think the pam_krb5 examples are comprehensive enough.  I may 
wish to authenticate through Kerberos _and_ through other additional 
modules.

> 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.

Agreed.

> 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.

Yes, assumptions made could break their authentication.

Shawn.
--