> On Sun, Jan 20, 2002 at 23:14:13 +0000, Mark Murray wrote:
> > 
> > The PAM OPIE may only do OPIE authentication. It is entirely up to the
> > PAM stack to decide what the login policy is.
> > 
> > (Well, the PAM stack as specified by the pam configs in /etc/pam*)
> Yes. And to allow PAM stack to make right decision, pam_opie pass special
> information to PAM stack. Look at the patch, pam_opie not breaks from the
> stack by yourself, it is /etc/pam* do that using information from
> pam_opie.

Sure - but you are making specialised use of the return value that
assumes that pam_opie will be followed by pam_unix. This violates
the PAM spec.

> > However - the module may pass on the authentication token (the password)
> > and any following modules are allowed to use this if they find it.
> > (look at the try_first_pass and use_fist_pass options).
> I was thinking about that way but not find a good solution. That way 
> workatround is:
> 1) In the failure case when Unix (plaintext) passwords are disabled 
> pam_opie can pass specially-generated incorrect password down to pam_unix.
> 2) pam_unix option must be changed from "try_first_pass" to 
> "use_first_pass", because it asks again for password if "try_first_pass" 
> active, i.e. allows user to enter Unix (plaintext) password again. So we 
> have the same bug, but shifted to one prompt step.

You may be able to do something with options. Example: if the sysadmin
allows a password to be passed down the stack, otherwise pass a dummy.

ftpd    auth    required        pam_opie.so     keep_password
or similar)

> I have doubts about 1): what specially-generated incorrect password 
> can be? It seems that any combination is legal and MAY be equal to real 
> password.

Nope. kill the password if it is not allowed. Pass a NULL.

o       Mark Murray
\_      FreeBSD Services Limited
O.\_    Warning: this .sig is umop ap!sdn

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to