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

[Gary Winiger]

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


	Ah, OK.  That's what I missed.

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

	I would think if you're going to leverage include that you'd
	verify that <service> wasn't already specified (or maybe
	specified but including pam_krb5) and error out on that.
	If not specified perhaps produce an informational message saying
	something like,
	``Default configuration for <service> added to default pam.conf.
	You can view the default configuration at
	"/usr/lib/security/<arch>/kerberos_common".''

	kerberos_common would be read only and say something about not
	modifying the file, but customizing by making a copy.

Gary..
P.S.	I guess I need to start the backport of PSARC/2005/217 ;-)