lightdm combined with pam_ldap and mixed case usernames results in broken group enumeration, etc.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Light Display Manager |
New
|
Undecided
|
Unassigned |
Bug Description
(copy and pasted from https:/
We have an environment that uses pam_ldap to authenticate most of our
users.
Due to some nuances of the core (open)LDAP schema, the uid attribute
will return success on "equality" matches even if the requested query
includes spaces or mixed case. See Also:
http://
So, if you attempt to login as " Bkroth" instead of "bkroth", the LDAP
server will respond successfully.
Unfortunately, pam_ldap (probably reasonably) just takes that to mean
that the provided username is valid and passes it through (it did ask
for an equality match after all). A better thing to do at that stage
would probably be to hand back the value in the uid attribute that the
LDAP server responded with, but I'll leave that for a separate pam_ldap
bug report. Somewhat related:
https:/
The trouble is that lightdm, takes the user provided value and
1) assigns it to the USER and LOGNAME environment variables, and
2) uses it to try and initgroups(), which then fails (group memberships
in LDAP are usually done with fully qualified DNs which don't do the
loose equality matching described above).
The combination of incorrect USER environment variables and missing
supplementary groups causes lots of other problems.
Note that programs like su, login, ssh, etc. don't exhibit this behavior
since they turn around and perform a lookup of the "true" username
against the NSS database again when populating the environment
variables. Here's a few examples:
https:/
https:/
The attached patch essentially just adjusts lightdm's behavior to
perform the same sort of NSS lookup to get the true username.
I also have a dumbed down sample test program to illustrate the issue
outside of lightdm in case it helps.
Let me know if you have any questions or comments.
Thanks,
Brian
Original patch link from Debian bug report:
https:/