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?
If you set id ranges so that 2000 is not valid in the domain it will be
> This cannot happen. Similar to the /etc/passwd example I
> 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.
These semantics are not soemthing SSSD can influence, they are internal
glibc semantics. On initgroups glibc asks all the group map backends
about group memberships.
However, recently glibc added an option so that you can segregate
initgroups too. In general we try not to use it becaus ein many cases
people do want to have the memberships calculated through all group
However if you enable "initgroupos: files sss", the getgrouplist call do
not continue past files into sss if entries are found in files.
I am not sure I like this option, as it is rather new, undocumented, and
the semantics may not be really useful, but you may want to experiment
with it if you have a new enough glibc. (Was committed to glibc upstream
repo on may 10 2011)
> 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.
SSSD does not, I think we could do something as we should have access to
the list of groups previous nsswitch plugins returned, but we don't, as
in many cases users do want the current initgroups semantics.
> 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)
Here is another common security concern we are worried about: many programs
(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
IIRC per posix rules usernames cannot start with a digit.
Ie they must have at least one non-digit letter in the name, which means
a numeric only input to getent passwd should always be considered as a
Simo Sorce * Red Hat, Inc * New York