>>>>> "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
