[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Linux PAM fixes

> But pam_setcred() can be called without calling pam_open_session().
> Right?


> Since su shouldn't call the open/close session calls, should it call
> pam_setcred()? In the case of pam_krb5 that would make sense, as long as
> pam_setcred() is called again to destroy the ccache when the user exits
> the su session. In fact, su might well be useless in a Kerberos
> environment unless it does call pam_setcred().

Right, su should call pam_setcred to both create and delete the credentials.
The current distribution of su in Linux-Mandrake sh-utils only calls it
to create them.  I suspect other Linux distributions are using the
same PAM patches, but I haven't checked.

> The pam_krb5 pam_sm_close_session() method can do some useful things:
>  - print the time of last login (i.e., last initial TGT issuance);
>    granted, MIT doesn't maintain that datum, so it's useless with MIT
>    krb5
>  - warn the user about upcoming password expiration (e.g., "Your
>    password will expire in 3 days")
> By the way, there are a number of different pam_krb5 implementations
> out there.

Sorry, I should have been explicit.  I'm referring to the Red Hat 7 one.
I've also looked at Frank Cusack's, which is in the FreeBSD ports collection
and doesn't have most of the problems I described.

> This brings up an issue with PAM and the Kerberos password aging model,
> namely that with Kerberos an expired password must be changed BEFORE
> proceeding with authentication, but in the PAM model authentication is
> done first, then authorization and only then can password expiration be
> discovered and corrected (i.e., it's pam_acct_mgmt()'s job to indicate
> the password expired case to the application so it cam call
> pam_chauthtok()).

I don't have strong opinions about how to handle password aging, as I 
don't use it.

If anyone in the recipient list doesn't want to be in on any further
discussions of these topics, just reply to the rest of us and we'll
leave you out of any future messages.  I don't expect (or hope) that
a long discussion will ensue, though.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []