Excerpts from Stephen Gallagher's message of Wed May 23 08:12:33 -0400 2012:
I'm working under the assumption that when you speak of "local domains" here, you're talking about /etc/passwd. If this is wrong, please correct me.
Yes, we are in agreement here.
This means that any lookup calling 'getpwnam()' or 'getpwuid()' will 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.
The one catch is the user's primary group ID. Most of the time, this 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 (you can 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 currently have any such functionality. I'd be interested 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:
http://debathena.mit.edu/nss_nonlocal/ git://andersk.mit.edu/nss_nonlocal http://andersk.mit.edu/gitweb/nss_nonlocal.git
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) get 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 GID.
Cheers, Edward