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

Re: sufficient account management checking for locally definedusers



[I suspect Martin knows what I think quite well, but thought I'd bring
up my thought for the list.]
    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> For the locally defined users, I want to use standard flat
    Martin> files.  This means that the only PAM module available to
    Martin> me is pam_unix (I'm running Debian GNU/Linux, so pam_pwdb
    Martin> is no longer available).  For the remotely defined users I
    Martin> want to use pam_ldap.

    Martin> Therefore, I want to do this:

    Martin>   account sufficient pam_unix.so account required

I disagree this is what you want to do in an ideal world.

It seems to me that most account modules provide restrictions on the
set of valid accounts that should log in.  For such a module
(including both pam_unix and pam_ldap), it seems that sufficient is
rarely going to be what you want.  Certainly it doesn't seem
reasonable to have either of these modules be sufficient for account;
let's look at why this is true.

The pam_unix account module is designed to apply restrictions to any
unix authentication.    It has nothing to do with local users;
pam_unix can be used for any user that NSS can find.  
\
You seem to be asking for a pam module that  does two distinct
things.  First, it applies the restrictions that pam_unix would apply
if the user is local.  Then, it succeeds only for local users.

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

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

So you could have:

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

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





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