Re: Old Authtok when changing passwords

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

 



On Tue, Apr 16, 2002 at 11:45:31AM -0700, Andrew Morgan wrote:
> Nicolas Williams wrote:
> > 
> > Indeed, it's not very pretty to try to save the password from the
> > conversation function, but it is a workaround, and it is portable.
> 
> Surely, one could modify the pam_unix module to do this too..? (You
> could make it selectable with a module argument and cache the password
> in a pam_[gs]et_data() item.)

Yes, this can be done. But, should a module that does that also set
PAM_OLDAUTHTOK if it wasn't set.

> [Please, no more hacks in the conversation function!]

heh

> > But yes, I too have been mystified by a few silly things in PAM:

[...]

> >  - Why not allow pam_authenticate() to return PAM_NEWAUTHOTK_REQD? This
> >    can't be changed backwards compatibly now without also adding a new
> >    API by which an app may indicate to PAM which version of PAM it
> >    supports.
> 
> I guess its not clear to me why the existing account management stuff
> isn't good enough for this?

Some auth types can't validate expired tokens. Thus PAM_LDAP and
PAM_KRB5 are forced to return PAM_SUCCESS from pam_sm_authenticate()
when the token is expired even though no authentication can take place
until pam_sm_chauthtok() is called. Obnoxious, yes? We've been over
this - it's somewhere in the list archives.

> Cheers
> 
> Andrew


Cheers,

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.





[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux