> > The submitter has updated the spec and I believe all of the issues have
> > been addressed. The timer expired yesterday, this case is now
> > approved.
>
> I believe this is premature. In any case Darren and I discussed
> things Wed afternoon and came up with a number of points.
Again thanks for the time to do another review. I split out the "final"
man page into the case directory for easier viewing. Using it as the
"final" spec along with pkinit-final.txt, unfortunately, I believe there
are still open issues. I've been told the project team is on holiday.
I'll move the timer to 3 Dec if the project team is not at the next PSARC
meeting.
As I said, Darren and I chatted last week. (I'm sure he'll correct me
if I've misstated our conversation.) I also received unsolicited
mail from someone in the Sun field who supports large customers stating
that PAM is difficult enough to configure, so my previous points 1 and 2
should not be taken lightly. That was also part of Darren and my discussion.
1 I'm still uncomfortable with stacking pam_krb5 multiple
times within the same stack type. IMO, it will lead
to more confusion than the cost of generating a new
module. I'll "hold my nose[tm]" here and hope the project
team doesn't get customer calls.
2 I'm uncomfortable about keying off of an empty PAM_AUTHTOK
to mean do PKINIT. See above.
With this input in mind, I'm no longer comfortable holding my nose and
feel TCR strong about having this resolved. Darren and I believe there
are straight forward solutions to 1-2:
* provide a separate pam_pkinit module (my and the field person's
preference),
* add a "pkinit" option to pam_krb5.
and do not key off of an empty PAM_AUTHTOK. I feel TCA strong about
the separate module. Given the project's schedule, according to the
manager, first chance to integrate isn't until 2010/02, I believe
factoring the code, most of which is library, into a separate module
is doable and the cleanest way to view a pam.conf configuration.
The man page and pkinit-final differ with respect to keying off
of PAM items:
"In order to avoid misleading prompting by pam_authtok_get (which
assumes a password must be prompted for) pam_krb5 would be modified
to do its own prompting when it determines that the PAM_USER and
PAM_AUTHTOK are not available which indicates it is above pam_authtok_get
in the auth stack. pam_krb5 would assume at this point that PKINIT
is to be used to acquire the user's Kerberos credential. If PKINIT
fails to acquire a Kerberos credential an error would be returned."
I assume that the man page is accurate and only PAM_AUTHOTK is keyed (recall
the TCR strongness to resolve this as above).
Relative to my previous point 3
3 In the case of stacking two pam_krb5(5) modules such that
the first will pass through to pam_authtok_get(5), I'm unclear
from the pam_sm_authenticate() spec what pam_authtok_get will
do. Please specify what PAM items are set by the first
instance so the admin knows what they will get from
pam_authtok_get. I suspect there are two cases here:
* PKINIT is not done, or fails;
* PKINIT succeeds.
The man page seems silent, however pkinit-final says:
"pam_krb does not set any PAM items when doing PKINIT on the auth
stack."
Independent of how pkinit is stacked, PAM_USER must be set to the
authenticated user's name if the auth stack succeeds. Perhaps I've
missed something in my reading, I don't see where PAM_USER is set by
this proposal. (Calling pam_get_user(3) ensures that PAM_USER is set ;-)
Viz:
+ login auth required pam_unix_cred.so.1
+ login auth sufficient pam_krb5.so.1
+ login auth requisite pam_authtok_get.so.1
+ login auth required pam_dhkeys.so.1
+ login auth required pam_unix_auth.so.1
>From pkinit-final:
"The pam_krb5 password module will change in that if PKINIT
authentication was done it will return PAM_IGNORE in the following
cases:
- the new passwd is NULL
- the old passwd is NULL
- verification of the old passwd fails.
If none of the above is true then pam_krb tries to change the password
and will return an error if that fails. The rational behind this is if
some PAM module causes pam_acct_mgmt() to return PAM_NEW_AUTHTOK_REQD
and/or the app subsequently calls pam_chauthtok(), pam_krb5 will change
a user's password. But this may well fail: the KDC may not want to
allow a PKINIT user to change/set a password since the user may be
expected to use PKINIT."
This information does not seem to be in the man page. How does the
administrator know it? Not being a pkinit expert, I'd like to understand
how the password stack will know if the user was authenticated by pkinit?
I feel TCR strong that the man page needs to be complete relative to this
part of the spec. I'm also concerned that pam_krb5 in the password stack
won't likely be called without PAM_AUTHTOK or PAM_OLDAUTHTOK set.
Which call to pam_sm_chauthtok() PAM_PRELIM_CHECK and/or PAM_UPDATE_AUTHTOK
will be making these checks?
>From pkinit-final:
"The other pam_krb5 modules (account and session) will not change."
>From the man page:
"Kerberos V5 Account Management Module
The Kerberos account management component provides a func-
tion to perform account management, pam_sm_acct_mgmt(). This
function checks to see if the pam_krb5 authentication module
has noted that the user's password has not expired. The fol-
lowing options may be passed in to the Kerberos V5 account
management module:"
If pam_sm_acct_mgmt() is unchanged, what is it that the "pam_krb5
authentication module" has told pam_sm_acct_mgmt? How does this all
interact with pkinit?
>From pkinit-final:
"Interface Stability Release Binding
new pam_krb5 options Committed Minor"
Nit, I presume the new options is a typo.
My personal recommendation: Develop a pam_pkinit (or similarly named) module
with a separate man page. Have that man page describe the interactions
between pam_pkinit and pam_krb5.
Thanks for the extra time,
Gary..
