Learn more about these different git repos.
Other Git URLs
A Unix client expects user and group names to be case-sensitive, but the prevalent schema on a server usually doesn't treat it as so. This can lead to hard-to-diagnose problems when people try to log in with a user name that's slightly off:
- the user's entry will be found in the directory server
- mapping from the user's name to a Kerberos principal name will turn up an unrecognized client name
- depending on how supplemental groups are resolved, the user may or may not count among the members of a group or netgroup
It's probably unreasonable to expect that people will fix their servers, so having a way to safeguard against these problems at the client would be appreciated. What I'm suggesting is that the backend add an additional check that the naming attribute in the retrieved entry matches the query exactly, and that it ignore entries that don't match.
There are a few things that we need to do within sssd to handle case-sensitive names, and we probably also need to have an "force lower case names" option.
There are 3 things to keep in mind when dealing with user/group names.
1) At the moments we use an attribute called "name" to store the user's name.
This attribute is marked CASE-INSENSTIVE in the sysdb schema (see sysdb_private.h).
So we need code that is able to change the @ATTRIBITES attribute in the ldb file if we switch between case sensitive/case insensitive names and reindexes the db.
Alternatively we can also just clear the cache if the option changes (hopefully people will not change it while offline :)
2) When reading from the remote server we need to decide how to deal with the incoming data.
a) we trust the server, so we accept that data as is whatever the capitalization of the names and trust the server to be consistent internally (for example user names in the memberUid attribute of groups are case-correct wrt the user's object attribute holding the user name).
b) We do not trust the server to have consistent capitalization for names.
In this case the only way to have something sane is to use "force lower case names". We always lower case all names before storing them. We need to have a way to make sure we handle the case where the server have 2 users/groups with the same name differing only for the name. We probably need to store the original user name attribute, and do extra checks if, for some reason the data we get back from the server does not match.
3) When serving user requests we need to deal with case mismatches.
If we change the ldb attribute to turn "name" into a case sensitive attribute, then this is easy as queries will simply fail if the case does not match. Although we may need to have additional interfaces in future if we want to allow some non-posix interface to be able to not care about case.
If we don't change the ldb attribute to case sensitive then we may have to check that the requested user/group name case matches what we found. Or also immediately return with error if the requested name has a capital letter and the "force lower case names" is set.
Changing the ldb attribute "name" to be case-sensitive, and setting "force lower case name" to be on by default is probably the best default configuration from a posix-compliance point of view.
milestone: SSSD Deferred => SSSD 1.0
owner: simo => sgallagh
status: new => assigned
Moving this to 1.0.0rc, as it is a functionality change that should be complete before feature-complete state.
milestone: SSSD 1.0 => SSSD 1.0 RC
I've been wracking my brain for two days now trying to figure out what you think we're doing wrong here right now. Let me try to put my thoughts in order.
Most LDAP servers are case-insensitive. This means that they may not be internally consistent, because user sgallagh might potentially be listed elsewhere as memberuid=Sgallagh (for example).
POSIX users should be case-sensitive (meaning that it should be possible to have distinct users "sgallagh" and "Sgallagh" on a system)
Currently, the SSSD enforces a case-insensitive system where name fields (used for both users and group names) are treated as case-insensitive.
So in essence, what SSSD is doing is behaving in a way identical to the majority of LDAP servers out there, and just adding an additional restriction on POSIX.
Thus, I can only see one possible configuration that would be considered potentially harmful in our current situation:
Some user has an LDAP server that is configured to use case-sensitive users or groups AND is not internally consistent (either they've actually got two users with names differing only by case or they're inconsistent with their group memberships). I'm inclined to consider this to be a deployment bug, rather than a situation to address in the SSSD. I think the proper response to a support issue of this type would be "Fix your entries to be consistent."
I'd like someone to explain to me why we should perform complicated comparisons on the SSSD side, rather than have them fix their deployment.
I think the problem is reverse. Per recent discussion about MPG the posixName attribute that will be used by IPA to store the real names for user and groups will be case sensitive for the first time fixing the broken LDAP schemas that for quite a while ignored the fact that the user and group names must be case sensitive. This makes the situation of SSSD even worse. It should in some way be capable of working with back ends that do it right in the case sensitive way and do it wrong in the case insensitive way. May be SSSD should query the back end for some attribute in the rootDSE that indicates if the source is case sensitive or not. By default it would assume it is case insensitive. Only IPA will have it attribute (yet another value of IPA) so far and will do it right. For the sources that do it wrong I think SSSD should have a configurable mode : trust the source is correct vs. convert everything to one case.
Dmitri, while it would be possible to make IPA behave this way, we need to solve the general case.
Simo and I had a long discussion this morning on IRC, where we came up with the following main points:
Yes. This is what I was talking about. I agree 100%.
I was just suggesting that may be (in addition to what you said) it makes sense to query the actual back end to see if it has case sensitive schema or not and have the "force" configuration option only for the providers that do not support case sensitive schema. But I guess it is a very minor optimisation.
Other than that we are on the same page.
tests: 0 => 1
Fixed in e5d8e5e
We've decided to make the cache case-sensitive but not support the force_lowercase_names feature in 1.0. It will require more thought.
fixedin: => 1.0.0rc
resolution: => fixed
status: assigned => closed
tests: 1 => 0
testsupdated: 0 => 1
rhbz: => 0
Metadata Update from @nalin:
- Issue assigned to sgallagh
- Issue set to the milestone: SSSD 1.0 RC
to comment on this ticket.