Re: sufficient account management checking for locally definedusers

["Martin Schwenke" <martin meltin net>]

>>>>> "Sam" == Sam Hartman <hartmans@mit.edu> writes:

    Sam> [I suspect Martin knows what I think quite well, but thought
    Sam> I'd bring up my thought for the list.]

Yep...  :-)

    Martin> things in the wrong direction...

    Martin> I have 2 sets of users:

    Martin> * Locally defined users in /etc/{passwd,shadow}.

    Martin> * Remotely defined users in an LDAP directory.

    Martin> [...]

    Martin> Therefore, I want to do this:

    Martin> account sufficient pam_unix.so

    Sam> [...]

    Sam> The pam_unix account module is designed to apply restrictions
    Sam> to any unix authentication.  It has nothing to do with local
    Sam> users; pam_unix can be used for any user that NSS can find.

    Sam> You seem to be asking for a pam module that does two distinct
    Sam> things.  First, it applies the restrictions that pam_unix
    Sam> would apply if the user is local.  Then, it succeeds only for
    Sam> local users.

That would be easy to add to pam_unix (via a "local_only" option) and
would avoid the need for a new module.  I would also be happy with a
PAM module that only handles local users.  However, currently pam_unix
is the closest thing I have.

    Sam> Why not split these two distinct checks into two modules.
    Sam> Have pam_unix do the checks for pam_unix.  Then have another
    Sam> module that determines whether you want to bypass
    Sam> network-based checks for the current user.

That's what I'm doing right now.  It contorts the logic and introduces
an unnecessary inefficiency.

    Sam> Such a second module could either be a pam_is_local module or
    Sam> could be something like pam_access that checked to see if the
    Sam> user was a member of a group.  I actually like the second
    Sam> option better because it's really hard to determine where NSS
    Sam> is getting a particular user from.  The concept of local user
    Sam> is very configuration dependent.

Which is why, as a system administrator, I should be free to make
policy and PAM should be flexible enough to implement it... without me
needing to write a stack of code...  :-)

    Sam> So you could have:

    Sam> account required pam_unix.so
    Sam> account sufficient pam_access.so (or something more specialized)
    Sam> account required pam_ldap.so

pam_access uses NSS functions, although it shouldn't if I point it at
a locally defined group...

The problem with using a pam_access + a group is that I have to
complicate my user management process and increase my system
administration load by adding locally defined users to a group, and
make sure that I don't use that group for remotely defined users.
It's extra work and it complicates the configuration.  Shouldn't my
security configuration be as simple as possible?

In this particular case (and, I suspect, many others) it is much
easier to let the system do the work of checking if a user is locally
defined, instead of requiring me to define whether each user is
locally defined or not.

    Sam> P.S.  You're doomed on the whole not dependening on network
    Sam> front if nss_ldap appears anywhere in your group nsswitch
    Sam> configuration.

"getent passwd root", "getent group root" and "ls -l /root" don't
generate any LDAP traffic.  If they did, I'd argue that NSS is broken.
The only LDAP traffic I see when I try to login as root looks to be
generated by pam_unix!  :-(

[Right now I can't confirm that, because I don't have a working ltrace
 on the boxes where I'm using pam_ldap.  I should have a working
 ltrace some time today...  if the LDAP traffic doesn't come from
 somewhere in pam_unix then I'll post a correction...]

Having said all that, I think we're getting closer to a solution.  If
pam_localuser is accepted into Linux-PAM and then makes its way into
Debian, I'll be happy enough...  even though it isn't the most
efficient solution.

peace & happiness,
martin