Re: LDAP authentication with PAM
On 17 Apr 2001, Brian May wrote:
> >> Thanks. I think that is just what I was looking for. Errr... except I
> >> think you meant default=ignore, not default=ok, as OK seems to mean
> >> return the error.
> Steve> The meanings of the special tokens are not clearly
> Steve> expressed in English. Only 'die' and 'done' cause an
> Steve> immediate return to the application; 'bad', 'ignore', and
> Steve> 'ok' will all cause libpam to continue on with the next
> Steve> module in the stack, and differ only in how they use the
> Steve> return value of the current module. In the case described
> Steve> here the differences are moot, because for any return value
> Steve> of pam_unix other than PAM_SUCCESS, pam_ldap will
> Steve> effectively override it.
> Sorry, I think you are mistaken. if pam_unix returned an error with
> the above config, then the use couldn't log in even if pam_ldap
> returned success. Or is that behaviour wrong?
Ah, then either this is a documentation bug or a comprehension failure on my
part (c.f. my earlier comment that the meaning of these tokens is not clearly
expressed in English :). Looking at the source code, I see that all three of
'ignore', 'bad', and 'ok' will cause libpam to fall through to the next
module, but you're correct that 'ignore' is the value you want if you don't
want this module to have an effect on the final return value from the PAM
call.
> >> account [success=1 default=ignore] pam_ldap.so
> >> account required pam_unix.so
> >> account required pam_permit.so
> Steve> Reduces to:
> Steve> account sufficient pam_ldap.so
> Steve> account sufficient pam_unix.so
> Ok. I assume if neither of this work pam_deny is implied?
Yes. If both ldap and unix account management return an error, you don't want
this to be treated as a success; failures here usually indicate that the
user account is expired or administratively locked.
> >> session [success=1 default=ignore] pam_ldap.so
> >> session required pam_unix.so
> >> session required pam_permit.so
> Steve> Reduces to:
> Steve> session sufficient pam_ldap.so
> Steve> session sufficient pam_permit.so
> Steve> session optional pam_lastlog.so
> Steve> session optional pam_motd.so
> Steve> session optional pam_mail.so standard noenv
> No it doesn't!
> For starters you forgot pam_unix, and put pam_permit instead. Both are
> NOPs, but why the change? Was that a typo?
As I said, pam_unix's no-op behavior isn't going to be changing any time soon.
There are many typical "unix-like" functions that PAM could carry out at the
beginning of a session.. and there are separate PAM modules already for almost
all of these functions. It seems terribly pointless to me to include the
module here, because if pam_unix ever /did/ start doing something in the
session stage, you could suddenly have unexpected login failures as a result
of this behavior change.
> My observations have shown that sufficient means "skip all future
> operations if this one succeeds." So for the above case if pam_ldap
> succeeds, it skips pam_lastlog, pam_motd, and pam_mail.
> So if I log in (yes, I tested this) using ldap, then I don't get the
> MOTD displayed.
Source code confirms; this was a mental lapse on my part. I was thinking that
'sufficient' would still let PAM look at subsequent 'optional' modules.
However, looking at the source code I see that you could in fact use
session optional pam_lastlog.so
session optional pam_motd.so
session optional pam_mail.so standard noenv
without anything else to get the same effect. If pam_ldap has some value as a
session module, you could put
session requisite pam_ldap.so
at the top of the stack. 'required' is also an option.
Steve Langasek
postmodern programmer
Reply to: