Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

5.1 beta2 still in trouble with pam_ldap

0 views
Skip to first unread message

Frank Bonnet

unread,
May 22, 2003, 12:47:35 PM5/22/03
to freebsd...@freebsd.org
Hi

I've installed 5.1 beta2 but I'm still in trouble
with pam_ldap / nss_ldap

the scenario is the following

if in any file of the pam.d directory I replace
the original line :

auth required pam_unix.so no_warn try_first_pass nullok

by the following

auth sufficient /usr/local/lib/pam_ldap.so

for example in the /etc/pam.d/su file I can perform the "su -"
command WITHOUT TYPING ANY PASSWORD from a normal user login.

Do I missunderstand pam concepts or is it a real bug ?

LDAP related packages installed are

openldap-2.0.25_3
nss_ldap-1.204_1
pam_ldap-1.6.1

Thanks for any infos
--
Frank Bonnet
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

Gordon Tetlow

unread,
May 22, 2003, 5:51:01 PM5/22/03
to Frank Bonnet, freebsd...@freebsd.org
On Thu, May 22, 2003 at 06:46:31PM +0200, Frank Bonnet wrote:
> Hi
>
> I've installed 5.1 beta2 but I'm still in trouble
> with pam_ldap / nss_ldap
>
> the scenario is the following
>
> if in any file of the pam.d directory I replace
> the original line :
>
> auth required pam_unix.so no_warn try_first_pass nullok
>
> by the following
>
> auth sufficient /usr/local/lib/pam_ldap.so

Don't replace the line, add it before pam_unix.so. Having the last auth
line be sufficient causes weird behavior. If you feel like you need to
*replace* pam_unix (which is a *really* bad idea), make it required, not
sufficient. I would recommend something like this:

...
auth sufficient /usr/local/lib/pam_ldap.so


auth required pam_unix.so no_warn try_first_pass nullok

> Do I missunderstand pam concepts or is it a real bug ?

I think you might be missing a concept or two. In any event this is not
really a bug.

-gordon

Dag-Erling Smorgrav

unread,
May 22, 2003, 6:29:08 PM5/22/03
to Frank Bonnet, freebsd...@freebsd.org
Frank Bonnet <bon...@bart.esiee.fr> writes:
> if in any file of the pam.d directory I replace
> the original line :
>
> auth required pam_unix.so no_warn try_first_pass nullok
>
> by the following
>
> auth sufficient /usr/local/lib/pam_ldap.so
>
> for example in the /etc/pam.d/su file I can perform the "su -"
> command WITHOUT TYPING ANY PASSWORD from a normal user login.

If pam_ldap is the last line, it should be "required", not
"sufficient"; alternatively it should be followed by pam_deny. This
is (imperfectly) documented in /etc/pam.d/README:

Note that having a "sufficient" module as the last entry for a
particular service and module type may result in surprising behaviour.
To get the intended semantics, add a "required" entry listing the
pam_deny module at the end of the chain.

Solaris introduced the "binding" flag to try to alleviate this
problem. OpenPAM supports "binding", but does not document it
anywhere.

DES
--
Dag-Erling Smorgrav - d...@ofug.org

Gordon Tetlow

unread,
May 22, 2003, 6:57:59 PM5/22/03
to Dag-Erling Smorgrav, freebsd...@freebsd.org, Frank Bonnet
On Fri, May 23, 2003 at 12:26:20AM +0200, Dag-Erling Smorgrav wrote:
> Frank Bonnet <bon...@bart.esiee.fr> writes:
> > if in any file of the pam.d directory I replace
> > the original line :
> >
> > auth required pam_unix.so no_warn try_first_pass nullok
> >
> > by the following
> >
> > auth sufficient /usr/local/lib/pam_ldap.so
> >
> > for example in the /etc/pam.d/su file I can perform the "su -"
> > command WITHOUT TYPING ANY PASSWORD from a normal user login.
>
> If pam_ldap is the last line, it should be "required", not
> "sufficient"; alternatively it should be followed by pam_deny. This
> is (imperfectly) documented in /etc/pam.d/README:
>
> Note that having a "sufficient" module as the last entry for a
> particular service and module type may result in surprising behaviour.
> To get the intended semantics, add a "required" entry listing the
> pam_deny module at the end of the chain.

Do you think it might be a good idea to turn all the pam configuration
files to list actual providers at sufficient followed by a pam_deny:

auth sufficient pam_krb5.so
auth sufficient pam_ldap.so
auth sufficient pam_unix.so
auth required pam_deny.so

This makes it very explicit as to what's going on and makes it so the
last entry isn't different merely because it's last.

> Solaris introduced the "binding" flag to try to alleviate this
> problem. OpenPAM supports "binding", but does not document it
> anywhere.

I'm unfamiliar with this option. What's it do?

-gordon

Dag-Erling Smorgrav

unread,
May 22, 2003, 7:48:44 PM5/22/03
to Gordon Tetlow, freebsd...@freebsd.org, Frank Bonnet
Gordon Tetlow <gor...@gnf.org> writes:
> Do you think it might be a good idea to turn all the pam configuration
> files to list actual providers at sufficient followed by a pam_deny:

No. I'd rather replace "sufficient" with "binding" where appropriate.

> > Solaris introduced the "binding" flag to try to alleviate this
> > problem. OpenPAM supports "binding", but does not document it
> > anywhere.
> I'm unfamiliar with this option. What's it do?

It behaves like "sufficient" should, i.e. failure is not ignored. I'm
working on updating the documentation.

Ruslan Ermilov

unread,
May 23, 2003, 2:10:33 AM5/23/03
to Dag-Erling Smorgrav, freebsd...@freebsd.org, Frank Bonnet
On Fri, May 23, 2003 at 01:45:44AM +0200, Dag-Erling Smorgrav wrote:
> Gordon Tetlow <gor...@gnf.org> writes:
> > Do you think it might be a good idea to turn all the pam configuration
> > files to list actual providers at sufficient followed by a pam_deny:
>
> No. I'd rather replace "sufficient" with "binding" where appropriate.
>
> > > Solaris introduced the "binding" flag to try to alleviate this
> > > problem. OpenPAM supports "binding", but does not document it
> > > anywhere.
> > I'm unfamiliar with this option. What's it do?
>
> It behaves like "sufficient" should, i.e. failure is not ignored.
>
You mean, _last_ failure is not ignored?

--
Ruslan Ermilov Sysadmin and DBA,
r...@sunbay.com Sunbay Software AG,
r...@FreeBSD.org FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine

http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age

Dag-Erling Smorgrav

unread,
May 23, 2003, 2:27:05 AM5/23/03
to Ruslan Ermilov, freebsd...@freebsd.org, Frank Bonnet
Ruslan Ermilov <r...@freebsd.org> writes:
> On Fri, May 23, 2003 at 01:45:44AM +0200, Dag-Erling Smorgrav wrote:
> > Gordon Tetlow <gor...@gnf.org> writes:
> > > I'm unfamiliar with ["binding"]. What's it do?

> > It behaves like "sufficient" should, i.e. failure is not ignored.
> You mean, _last_ failure is not ignored?

I don't understand the question.

Ruslan Ermilov

unread,
May 23, 2003, 2:30:34 AM5/23/03
to Dag-Erling Smorgrav, freebsd...@freebsd.org, Frank Bonnet
On Fri, May 23, 2003 at 08:24:34AM +0200, Dag-Erling Smorgrav wrote:
> Ruslan Ermilov <r...@freebsd.org> writes:
> > On Fri, May 23, 2003 at 01:45:44AM +0200, Dag-Erling Smorgrav wrote:
> > > Gordon Tetlow <gor...@gnf.org> writes:
> > > > I'm unfamiliar with ["binding"]. What's it do?
> > > It behaves like "sufficient" should, i.e. failure is not ignored.
> > You mean, _last_ failure is not ignored?
>
> I don't understand the question.
>
In a chain with mutiple "binding" modules, only the _last_
failure gets ignored? Meaning, if some other module succeeds,
override the failure status, right?


Cheers,

Dag-Erling Smorgrav

unread,
May 23, 2003, 10:33:50 AM5/23/03
to Ruslan Ermilov, freebsd...@freebsd.org, Frank Bonnet
Ruslan Ermilov <r...@freebsd.org> writes:
> In a chain with mutiple "binding" modules, only the _last_
> failure gets ignored? Meaning, if some other module succeeds,
> override the failure status, right?

Failure of a "binding" module causes the entire chain to fail once it
has completed. The error returned is that returned by the first
non-"optional", non-"sufficient" module that failed.

Failure of a "sufficient" module, on the other hand, is always ignored
(so if no other non-"optional", non-"sufficient" module failed, the
chain will succeed). This is what constantly surprises users, and
what "binding" was introduced to alleviate.

See the PAM article for details - particularly the following two
sections:

http://www.freebsd.org/doc/en/articles/pam/pam-essentials.html#PAM-CHAINS-POLICIES
http://www.freebsd.org/doc/en/articles/pam/pam-config.html#PAM-POLICIES

Ruslan Ermilov

unread,
May 23, 2003, 3:38:33 PM5/23/03
to Dag-Erling Smorgrav, cur...@freebsd.org
On Fri, May 23, 2003 at 04:33:09PM +0200, Dag-Erling Smorgrav wrote:
> Ruslan Ermilov <r...@freebsd.org> writes:
> > In a chain with mutiple "binding" modules, only the _last_
> > failure gets ignored? Meaning, if some other module succeeds,
> > override the failure status, right?
>
> Failure of a "binding" module causes the entire chain to fail once it
> has completed. The error returned is that returned by the first
> non-"optional", non-"sufficient" module that failed.
>
> Failure of a "sufficient" module, on the other hand, is always ignored
> (so if no other non-"optional", non-"sufficient" module failed, the
> chain will succeed). This is what constantly surprises users, and
> what "binding" was introduced to alleviate.
>
> See the PAM article for details - particularly the following two
> sections:
>
> http://www.freebsd.org/doc/en/articles/pam/pam-essentials.html#PAM-CHAINS-POLICIES
> http://www.freebsd.org/doc/en/articles/pam/pam-config.html#PAM-POLICIES
>
Thanks, DES! I think I now understand this much better. :-)

And I have the following question for you:

Why pam_nologin in the "auth" chain of the "login" service is marked
"required" and not "requisite", and why do we have the "required" at
all? What's the point in continuing with the chain if we are going
to return the failure anyway? What's the real application of
"required" as compared to "requisite"?

Dag-Erling Smorgrav

unread,
May 23, 2003, 3:41:56 PM5/23/03
to Ruslan Ermilov, cur...@freebsd.org
Ruslan Ermilov <r...@FreeBSD.org> writes:
> Why pam_nologin in the "auth" chain of the "login" service is marked
> "required" and not "requisite", and why do we have the "required" at
> all? What's the point in continuing with the chain if we are going
> to return the failure anyway? What's the real application of
> "required" as compared to "requisite"?

Information leak. The applicant screwed up, but we don't want to let
him know that until he's jumped through all the *other* hoops as well;
otherwise he might learn something about our authentication setup from
the premature error message.

Ruslan Ermilov

unread,
May 23, 2003, 3:50:43 PM5/23/03
to Dag-Erling Smorgrav, cur...@freebsd.org
On Fri, May 23, 2003 at 09:41:09PM +0200, Dag-Erling Smorgrav wrote:
> Ruslan Ermilov <r...@FreeBSD.org> writes:
> > Why pam_nologin in the "auth" chain of the "login" service is marked
> > "required" and not "requisite", and why do we have the "required" at
> > all? What's the point in continuing with the chain if we are going
> > to return the failure anyway? What's the real application of
> > "required" as compared to "requisite"?
>
> Information leak. The applicant screwed up, but we don't want to let
> him know that until he's jumped through all the *other* hoops as well;
> otherwise he might learn something about our authentication setup from
> the premature error message.
>
Works for the generic case, but not for this particular example.
Just run "shutdown -k now" locally, and watch how funny the login
session looks. I don't think we're leaking something here. ;)
Hm, or maybe this is just the problem with pam_nologin(8) not
respecting the "no_warn" option?

Dag-Erling Smorgrav

unread,
May 23, 2003, 3:56:14 PM5/23/03
to Ruslan Ermilov, cur...@freebsd.org
Ruslan Ermilov <r...@FreeBSD.org> writes:
> Works for the generic case, but not for this particular example.
> Just run "shutdown -k now" locally, and watch how funny the login
> session looks. I don't think we're leaking something here. ;)
> Hm, or maybe this is just the problem with pam_nologin(8) not
> respecting the "no_warn" option?

hmm

I think you're right - in the nologin case, information leak isn't an
issue. We should change it to requisite. I need to go through the
policies and change "sufficient" to "binding" anyway, so I'll take
care of it once the freeze lifts.

0 new messages