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 -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?
If you set id ranges so that 2000 is not valid in the domain it will 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.
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 backends. 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 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, 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 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.gitIt 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.
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 uid number.
Simo.