[Fwd: kclient version 2 [PSARC/2007/401 FastTrack timeout 07/13/2007]]
Darren J Moffat
Darren.Moffat at Sun.COM
Fri Jul 13 04:48:22 PDT 2007
Shawn M. Emery wrote:
> 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?
I think that is actually a bad idea and could easily lead to quite
strange configurations. Past experience with modifying the pam.conf
has show that it is unfortunately very complex as soon as there is a
single change from one of the default versions we have shipped.
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.
--
Darren J Moffat
More information about the opensolaris-arc
mailing list