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

Re: PAM_PRELIM_CHECK && pam_krb5

Use the devl branch of Frank's module. Check it out in the SourceForge
CVS repository for Linux-PAM.

The right thing to do with the PRELIM check, if there's nothing to do,
is to do nothing and return PAM_SUCCESS.



On Tue, Dec 11, 2001 at 05:32:48PM -0500, Swanson, Bryan wrote:
> Linux-PAM-0.75
> Kerberos 1.2.2
> Frank Cusack's pam_krb5 module
> I have a question regarding proper behaviour of pam_chauthtok 
> my service config looks like the following:
> #/etc/pam.d/passwd
> passwd    requisite    pam_krb5.so
> passwd    required     pam_shadow_update.so
> what's happening is this, i run /usr/bin/passwd, i key in an
> invalid password,  pam_krb5 does not update my password,
> but any stacked modules are still run even though i've set
> pam_krb5 to requisite (exit on failure, right?)
> Now, I think I understand what's going on, so here goes,
> correct me if my understanding of the calling order is wrong...
> pam_chauthok is called initially with flags|PAM_PRELIM_CHECK
> (presumably this is to allow the module a chance to verify everything
> before actually doing the commit)
> 	1.  Are all modules called with PAM_PRELIM then called a second time
> 	    with PAM_UPDATE?
> 	2.  What should I return if my modules doesn't want to worry about
> 	3.  Is (2) even valid?  or am I not following PAM's rules?
> pam_chauthtok is then called a second time with flags|PAM_UPDATE_AUTHTOK 
> looking through pam_dispatch.c [~ line 285]  it seems that when
> pam_chauthtok
> is called with PAM_UPDATE_AUTHTOK set, use_cached_chain gets set to 1
> then, in _pam_dispatch_aux() [~ line 102] the cached return value gets used
> instead of the actual return code (from the second call) ... is this really
> the desired
> behaviour?  are we assuming that the second call cannot fail because the
> prelim 
> check didn't?  this seems wrong to me...
> BTW, Frank's module doesn't implement PRELIM, so I'm trying to figure out
> the
> best way to fix this with the least amount of work...if the answer is that
> i'll need to
> implement PRELIM checking, so be it...
> thanks,
> -b
> _______________________________________________
> Pam-list mailing list
> Pam-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/pam-list
-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.

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