Learn more about these different git repos.
Other Git URLs
In many places in the SSSD, we assume that the attribute being used for the RDN of an LDAP entry is single-valued. However, LDAP allows the use of one instance of a multi-valued attribute for this purpose.
The particular example that discovered this problem was that a customer had a group with multiple 'cn' attributes listed. One of these was the group name, but others were aliases.
We need to figure out how to handle this, as right now we throw an error.
There isn't much we can do here.
Unfortunately the RFC sucks in this area. For example CN is not even case sensitive, while unix groups are.
So although the RFC doesn't explicitly forbid setting the CN to multiple values, we simply have no way to know which one is the right one to pick.
I don't think we can really support this situation, we should probably punt.
When you say "punt", do you mean we should just skip over this group, or should we do as we are now, which is throw an error and abort the initgroups call?
cc: => simo
log and skip. we should never abort imo.
Currently I have two comments - this is not restricted to the RDN related attribute. E.g the gidNumber attribute can be used as RDN or a different multivalued attribute can be used to hold the name of the group. So there is really no chance to find the "right" group name if the corresponding attribute is multivalued - currently we behave inconsistently:
$ id user2 uid=1002(user2) gid=2000 Gruppen=2000 $ getent group g2 g2:*:1501:user2 $ id user2 uid=1002(user2) gid=2000 Gruppen=2000,1501(g2)
So initgr() does not like multivalued names, but getgrnam() works.
Here is what nss_ldap and nss-pam-ldapd are doing: - pam_ldap
$ id user2 uid=1002(user2) gid=2000 Gruppen=2000,1501(g2) $ getent group g2 g2:*:1501:user2 $ getent group g2_copy g2:*:1501:user2 $ getent group g2_clone g2:*:1501:user2 - nss-pam-ldapd $ id user2 uid=1002(user2) gid=2000 Gruppen=2000,1501(g2),1501(g2),1501(g2) $ getent group g2 g2:*:1501:user2 $ getent group g2_copy g2_copy:*:1501:user2 $ getent group g2_clone g2_clone:*:1501:user2
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.7.0
As there is no formal standard, it would be best if we maintain consistency in behavior amongst our different authentication mechanisms. pam_ldap has been behaving in this fashion since RHEL4 at least, so please use that model as an example until the standard is fixed.
I will be opening a similar bug against nss-pam-ldapd.
cc: simo => simo, gbarros
milestone: SSSD 1.7.0 => SSSD 1.5.4 owner: somebody => sgallagh status: new => assigned
Pulling back into NEEDS_TRIAGE
The fix was incomplete and needs more time to bake.
milestone: SSSD 1.5.4 => NEEDS_TRIAGE
milestone: NEEDS_TRIAGE => SSSD 1.6.0
Fixed in
master: - 42d8e67 - d86c2d2 - de96baa - 0c9ebc7 - 7196eba
sssd-1-5: - 9c5f876 - b4706b5 - a31b54b - f43f774 - ed0f813
milestone: SSSD 1.6.0 => SSSD 1.5.4 patch: => 0 resolution: => fixed status: assigned => closed
rhbz: => 0
Metadata Update from @sgallagh: - Issue assigned to sgallagh - Issue set to the milestone: SSSD 1.5.4
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/1860
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.