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