On Fri, 2012-05-25 at 00:11 -0400, Edward Z. Yang wrote:
Excerpts from Stephen Gallagher's message of Wed May 23 08:12:33
> I'm working under the assumption that when you speak of "local
> here, you're talking about /etc/passwd. If this is wrong, please correct
Yes, we are in agreement here.
> This means that any lookup calling 'getpwnam()' or 'getpwuid()'
> first check to see if it exists in the files map (aka /etc/passwd). If
> it does, it will return that value and that will be that.
> Let's work with the following sample data. (We'll use LDAP as the SSSD
> domain name, for simplicity)
> In /etc/passwd: username 'geofft' with UID 2000
> in LDAP: username 'geofft' with UID 3000
> in LDAP: username 'imposter' with UID 2000
> So if you have user 'geofft' in /etc/passwd and also in LDAP, you will
> get back the information from /etc/passwd for getpwnam("geofft"). So you
> will get back UID 2000.
> If you call getpwnam("geofft@LDAP"), you will bypass the /etc/passwd
> file and get back UID 3000
> If you call getpwuid(2000), you will get back user 'geofft'
> from /etc/passwd
> If you call getpwuid(3000), you will get back user 'geofft' from LDAP
OK, the further case we worry about is as follows: If you call
getpwnam("imposter"), will we get back UID 2000, or will this be rejected?
> This cannot happen. Similar to the /etc/passwd example I described
> above, lookups for a particular group name or GID would stop
> at /etc/group if the name or GID matched there first. It would not take
> ANY group membership information for groups in /etc/group from LDAP. If
> you wanted to add a remote user to a local group, you would need to add
> that user's name to /etc/group manually.
We do not believe the traditional nsswitch semantics work this way. If you
look at initgroups(), what will happen is that the lookup for groups of a
remote user will fail on the local groups source (/etc/group), and then NSS
will consult the remote source for groups, and initgroups_dyn will add them as
secondary groups for the user. These groups are not normally distinguished
from the normal groups.
It is possible that SSSD has different semantics, but this is not
obvious to us.
Right, this is correct (and is one of the headaches with the libc
interface: the behavior of initgroups() and getgrnam() are not
> The one catch is the user's primary group ID. Most of the
> would be set to a user private group for security reasons, but it's
> theoretically possible that an LDAP user could have it set to be e.g. 10
> ('wheel' on RHEL). In this case, the local system WILL honor it.
> That said, I think maybe we want to add an option to filter out certain
> values for primary group ID in order to avoid this issue. It's a valid
> concern. Please file an RFE at https://fedorahosted.org/sssd
> get an account from https://admin.fedoraproject.org/accounts
if you do
> not have one).
Yes, and secondary GIDs have the same problem, unless SSSD does something
dramatically different. I will file this report.
Yeah, I think I see the issue here now. If there's an LDAP group with ID
10, and they're a member, initgroups() of that user WILL list 10. So
you're right here.
> SSSD does not currently have any such functionality. I'd be
> to see how this module works, as I have a feeling it would be broken by
> recent changes glibc made to the initgroups interface.
You can access nss_nonlocal from here:
It also contains the code for our security checks, so if you're
interested in the precise semantics, I suggest taking a look.
(And yes, we use internal glibc APIs, check nsswitch-internal.h)
Ok, I get the gist of this. It's pretty hackish though (and will likely
only work with glibc, which is a problem because we're at least *trying*
to maintain compatibility with any libc in SSSD).
Also, as I originally suspected, I'm pretty sure this code is not going
to work with the new initgroups() semantics added to the last two
releases of glibc.
The core problem here is that this is basically a hack. The libc
interface for initgroups() is intentionally-written to be additive. This
is working around that by suppressing some values if they happen to also
exist locally. It's not a bad solution, necessarily, but it's against
the spirit of the interface.
Basically, the expectation of both SSSD and libc is that if you add a
source for NSS data, it's *authoritative*. As in, you're asserting that
what's in that central database is the correct answer for your
environment. If that's not the case, then it's worth looking into fixing
your central store (which is usually easier than futzing with individual
Also, there are valid reasons that you might want to extend local groups
from the central server. For example, an application like a database
might use a hard-coded group ID to determine which users can access the
management console. Being able to add users to this list centrally is a
I'm not sure we want to build a specialized control in SSSD to suppress
IDs that exist in /etc/group. For one thing, it's only a stop-gap
solution, as a client still might have groups added from other NSS
sources that we won't know about.
In recent versions of SSSD (1.7.0 and later), we have added support for
more complex group search base filtering. You can now specify an LDAP
search filter as part of the group search base to specifically eliminate
groups you don't want to make visible to the local machine. For example:
ldap_group_search_base = \
This search base means that we'll look up and use any group in the
cn=groups subtree except for those that have gidNumber 10 or 11.
Here is another common security concern we are worried about: many
(e.g. chown and chgrp, see http://debathena.mit.edu/trac/ticket/367
confused if you pass them a numeric username, interpreting it as a UID if it
exists. So nss_nonlocal also rejects remote users which have numeric IDs that
match a local UID, and remote groups that have numeric IDs that match a local
I don't think that's something we're likely to fix, but you're welcome
to file an RFE. That really sounds like bugs in chown and chgrp. I'd
prefer not to be adding in workarounds for unrelated software.
On the whole, I think we have different concepts about the expectations
of a central identity store. Everything we're discussing here suggests
that you have concerns about trusting your identity store. That says to
me that you're not in control of it, which is a security breach waiting
to happen. I think you need to examine why you are relying on identities
you don't control.