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

Re: sufficient account management checking for locally defined users



On Wed, May 15, 2002 at 10:03:27AM +1000, Martin Schwenke wrote:
> >>>>> "Steve" == Steve Langasek <vorlon@netexpress.net> writes:
> 
>     Steve> And the 'A' and the 'M' say 'authentication modules', which
>     Steve> succinctly defines the scope of PAM.  Retrieving group
>     Steve> lists is not an authentication problem.

> OK, fair enough...  However, a lot of the session management stuff has
> nothing to do with authentication either:

>   session    optional     pam_motd.so # [1]
>   session    optional     pam_mail.so standard noenv # [1]
>   session    required     pam_limits.so

> pam_limits is closer to initgroups than it is to authentication!

> Since session management has always been part of PAM, I think it might
> be a case of finding a cute acronym that fits pretty well...  :-)

Certainly, there are things outside of pure authentication that PAM is
able to handle, and that's to everyone's advantage; but you can only
stretch this particular API so far.  Several other respondents have
discussed the need for a strong kernel credential API, and I agree that
this is where improvements need to start.  What you're asking for calls
for a new API, not modifications to an existing, stable one.

>     Steve> Easily done:

>     Steve> auth  sufficient  pam_unix.so
>     Steve> auth  required    pam_ldap.so use_first_pass

>     Steve> -- and that's it.  If the account is local, pam_ldap will never be
>     Steve> invoked with the above configuration.  Likewise, list
>     Steve> 'files' before 'ldap' in nsswitch.conf, to give optimal
>     Steve> lookup times for getpwnam()/getgrgid() calls on local
>     Steve> accounts.

> However, I started this thread using almost exactly the same example,
> except for account modules.  That doesn't work...  :-(

IIRC, pam_ldap should not be invoked in the above for any accounts that
successfully authenticate using pam_unix.  At the very least, Linux-PAM
makes it possible to ensure pam_ldap is not invoked, via its extended 
configuration syntax.

auth  [success=done default=ignore] pam_unix.so
auth  required                      pam_ldap.so use_first_pass

This guarantees that pam_ldap will not be invoked if pam_unix succeeds.

>     Steve> The one slowdown will be with initgroups() (yes, I meant
>     Steve> initgroups() earlier, not getgroups()).  There's no way
>     Steve> around that; you can lower your timeouts in nss_ldap, or
>     Steve> you can modify your login app to not call initgroups().

> ... except that the pam_unix account management does NSS calls...

pam_unix calls getpwnam(), getspnam(), endpwent(), endspent(),
setpwent(), and setspent().  It makes no group-related calls at
all, and the NSS calls it does make MUST also work for local users
/outside/ of a PAM context as well if the app is to be able to
successfully log the user in.

>     Steve> Those are your only two options, unless you do choose to
>     Steve> modify the PAM API; and there would have to be a very good
>     Steve> reason for Linux-PAM to break compatibility with other PAM
>     Steve> implementations.

> True.  I believe that FreeBSD is running its own PAM implementation,
> but I don't know if the API has changed...

Not that I'm aware of.

Steve Langasek
postmodern programmer

Attachment: pgp00008.pgp
Description: PGP signature


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