Bug 1794607
| Summary: | SSSD must be able to resolve membership involving root with files provider | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Muneaki Sugaya <msugaya> |
| Component: | sssd | Assignee: | Pavel Březina <pbrezina> |
| Status: | CLOSED ERRATA | QA Contact: | sssd-qe <sssd-qe> |
| Severity: | urgent | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.1 | CC: | abmsharm, aborah, atikhono, bugproxy, dhorak, grajaiya, hannsj_uhl, jhrozek, jomiller, lslebodn, mzidek, pbrezina, sbose, sgoveas, stephan.schultchen, thalman, tscherf |
| Target Milestone: | rc | Keywords: | Patch, Triaged |
| Target Release: | 8.3 | Flags: | pm-rhel:
mirror+
|
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | sync-to-jira | ||
| Fixed In Version: | sssd-2.3.0-4.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-11-04 02:04:37 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Muneaki Sugaya
2020-01-24 01:30:40 UTC
Hi, thank you for the bug report, I can reproduce the issue. The reason is twofold. First SSSD does not handle users with uid or gid 0 and adds them to a negative cache. Second when returning groups SSSD checks its negative cache for each group member and does not return group-members which are in the negative cache. As a result pam_wheel does not see that the user with gid 0 is a member of the wheel group because in /etc/nsswitch.conf there is 'group: sss files systemd' and since libnss_sss returns 'success' since the group is known by SSSD the other modules 'files' and 'systemd' are not tried. So we need to special case the files provider lookups here, e.g. either not do the negative cache check for group members or not return the group at all if there is a hit in the negative cache so that 'files' can handle it? Or something completely different. bye, Sumit (In reply to Sumit Bose from comment #1) > Hi, > > thank you for the bug report, I can reproduce the issue. The reason is > twofold. First SSSD does not handle users with uid or gid 0 and adds them to > a negative cache. Second when returning groups SSSD checks its negative > cache for each group member and does not return group-members which are in > the negative cache. As a result pam_wheel does not see that the user with > gid 0 is a member of the wheel group because in /etc/nsswitch.conf there is > 'group: sss files systemd' and since libnss_sss returns 'success' since > the group is known by SSSD the other modules 'files' and 'systemd' are not > tried. > > So we need to special case the files provider lookups here, e.g. either not > do the negative cache check for group members or not return the group at all > if there is a hit in the negative cache so that 'files' can handle it? Or > something completely different. > > bye, > Sumit I think this might be even more complex, because even if you hit sysdb, there are codepaths that handle the UID/GID lookups and often the code goes like this: uid = sysdb_get_id(sysdb, ldb_object, 0) if (uid == 0) { fail(); } note the zero is used as the default value and the condition then treats actually getting zero as a failure (or rather thinks that 'this is either a non-POSIX entry or it really has a zero ID in which case, let's not return it). *** Bug 1809489 has been marked as a duplicate of this bug. *** Pavel: By when can we expect a fix for this? I can't say this at the moment. This is not an easy fix and will require some time. Customers affected by this can switch 'sss files' to 'files sss' in /etc/nsswitch.conf as a workaround. (In reply to Pavel Březina from comment #5) > I can't say this at the moment. This is not an easy fix and will require > some time. > . Hello Red Hat / Pavel, ... is there already an outlook when the fix will be available ...? Is the fix targeted for RHEL8.3 ...? Please advise ... Thanks in advance for your support. Are you willing to try this scratch build? https://pbrezina.fedorapeople.org/scratch/1794607/ It is for 8.1, let me know if you need different build. Please note that it is mostly proof of concept and it should not be used in production. Upstream ticket: https://github.com/SSSD/sssd/issues/5170 Upstream PR: https://github.com/SSSD/sssd/pull/5171 Pushed PR: https://github.com/SSSD/sssd/pull/5171 * `master` * 8969c43dc2d8d0800c2f0b509d078378db855622 - files: allow root membership With Older version: [user01@ci-vm-10-0-137-189 upstream]$ rpm -qa | grep sssd sssd-common-2.2.0-19.el8.x86_64 sssd-client-2.2.0-19.el8.x86_64 sssd-nfs-idmap-2.2.0-19.el8.x86_64 sssd-kcm-2.2.0-19.el8.x86_64 [user01@ci-vm-10-0-137-189 upstream]$ cat /etc/redhat-release Red Hat Enterprise Linux release 8.1 (Ootpa) [user01@ci-vm-10-0-137-189 upstream]$ grep wheel /etc/group wheel:x:10:user01 [user01@ci-vm-10-0-137-189 upstream]$ getent group wheel wheel:x:10: [user01@ci-vm-10-0-137-189 upstream]$ With Fixed version: [root@ci-vm-10-0-138-221 yum.repos.d]# su user01 [user01@ci-vm-10-0-138-221 yum.repos.d]$ grep wheel /etc/group wheel:x:10:user01 [user01@ci-vm-10-0-138-221 yum.repos.d]$ getent group wheel wheel:x:10:user01 [user01@ci-vm-10-0-138-221 yum.repos.d]$ rpm -qa | grep sssd sssd-nfs-idmap-2.3.0-4.el8.x86_64 sssd-client-2.3.0-4.el8.x86_64 sssd-common-2.3.0-4.el8.x86_64 sssd-kcm-2.3.0-4.el8.x86_64 [user01@ci-vm-10-0-138-221 yum.repos.d]$ cat /etc/redhat-release Red Hat Enterprise Linux release 8.3 Beta (Ootpa) Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (sssd bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:4569 |