>>>>> "Steve" == Steve Langasek <vorlon@netexpress.net> writes:
Steve> If an NSS module your system depends on is so badly messed
Steve> up that you can't reliably call getpwnam() and getgroups()
Steve> for a local account, you will have significant difficulties
Steve> logging in *regardless* of what PAM module you're using: a
Steve> local_only option for pam_unix would only add unnecessary
Steve> complexity to the module.
The NSS module in question (nss_ldap) isn't messed up. As Sam already
posted, to find out what supplementary groups a user is in, you need
to retrieve all groups that NSS knows about, which implicitly includes
the LDAP ones (if that's what nsswitch.conf says to do). To avoid
doing that for a locally defined user, you would need to look in only
the local files, which is part of what I'm advocating.
By the way, getgroups() is irrelevant to this discussion. It just
pulls a list of groups out of the current process's task_struct (or
similar, for non-Linux OSes). The list of groups is put into
task_struct using setgroups(), and has to be got from somewhere. This
looks like it is usually implemented using initgroups(), which calls
the NSS functions. I guess you meant initgroups()...
Now for the bad news: initgroups() is called from the application
(login/sshd) and not from PAM. Now that's pretty crappy, because it
means it can't be configured per application: I can't tell login to
only look at local users...
As far as I'm concerned the initgroups() call should happen in PAM so
that a different implementation can be substituted. That's what the
'P' in "PAM" is all about. The current design is broken. I don't
think I stand a strong chance of having that design changed,
reimplemented and accepted upstream (even though I'm willing to do
great chunks of it myself), so it's time to give up (or rely on an
LD_PRELOAD hack to get to my root account... ummm... no! :-)
"Farewell, ye old Spanish ladies..." :-)
Steve> FWIW, I've never had trouble logging in as root on
Steve> LDAP-aware systems when the network (or LDAP server) is
Steve> down. This is using 'passwd: files ldap' in nsswitch.conf.
Steve> It may be that this would not work very well if there were
Steve> a segfault-inducing bug in a library that nss_ldap depends
Steve> on, but bugs in any code loaded by libc are /always/
Steve> serious problems. Adding options to PAM modules won't
Steve> change that.
* Last week we were experiencing 30 second delays. That's suboptimal
and far from acceptable in some contexts.
I guess I'm just going to have to set the LDAP timeouts to something
like 5 seconds and live with it.
* Risk analysis:
As a system administrator, one of my jobs is to:
- perform risk analysis;
- make policy based on that analysis; and
- implement that policy.
I see an unecessary risk having a complex system like
pam_ldap+nss_ldap+OpenLDAP between my login prompt and my root
prompt. My policy is that I want to *avoid that particular risk*.
This *should* be easy to implement, but it isn't...
I realise there are other risks and I'm willing to ignore them.
Steve> If what you're really after is making sure pam_unix is not
Steve> used for authenticating LDAP-based accounts when the server
Steve> /is/ available, then between nss_ldap and the LDAP server
Steve> you already have all the access controls you need to make
Steve> sure password hashes are never sent in the clear across the
Steve> network.
No, I want to make sure that pam_ldap is not used for authenticating
non-LDAP-based accounts!
peace & happiness,
martin
