Bug 872619
| Summary: | sudoUser group and netgroup specifications don't work | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Nikolai Kondrashov <nikolai.kondrashov> |
| Component: | sssd | Assignee: | Jakub Hrozek <jhrozek> |
| Status: | CLOSED NOTABUG | QA Contact: | Kaushik Banerjee <kbanerje> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.4 | CC: | grajaiya, jgalipea, pbrezina |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-11-26 18:19:51 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: | |||
| Attachments: | |||
Created attachment 638717 [details]
Reproduction script for LDAP sudo backend
The same directory entries work with sudo using LDAP backend instead of sssd. A reproduction script is attached.
Pavel, this one is yours. Upstream ticket: https://fedorahosted.org/sssd/ticket/1624 Hi, these LDAP values didn't work correctly for me even with direct sudo <-> ldap. I believe the ldif is wrong. Why do you use multivalued cn to express group membership? Instead of using multivalued cn, you should use memberUid attribute. %group works fine for me with memberUid attribute %#gid does not work, it is not yet implemented +netgroups allow all rules containing netgroup, I will investigate that. It is a bug on sudo side. Thank you. Created attachment 645827 [details]
The corrected LDIF file with memberUid added
The multiple cn's were the result of a bug in my test code which generated this directory state, sorry. However, removing them didn't affect the test outcome.
I was under the impression that memberUid wasn't required for group members which have the group as primary (have gidNumber set to the group's gidNumber). The regular tools I tried worked OK with this. Does SSSD require memberUid in this case? This isn't specified in the documentation.
Still, adding memberUid to posixGroup's didn't affect the outcome of the test (the executable attached to the bug).
I've attached the fixed directory contents I used this time.
Hi, memberUid surprisingly should not contain uid number, but username (or to be more precise value of user's uid attribute e.g. uid: user1). But you have a good point that it should recognize user's primary group without the need of memberUid attribute. I'll prepare a patch. Netgroup issue is indeed a problem on sudo side, so we need to file sudo bug on that. We made a design decision that sssd will send all rules that contains +netgroup to sudo (this works ok) and sudo will filter them out (this does not happen). Upstream ticket for implementing %#gid support: https://fedorahosted.org/sssd/ticket/1667 (In reply to comment #8) > Upstream ticket for implementing %#gid support: > https://fedorahosted.org/sssd/ticket/1667 Can you either reword this bugzilla or close it and open a new one? I've submitted Bug 880150 on the netgroup issue. I've confirmed that adding "memberUid: user1" to "cn=group_user1,ou=Groups,dc=example,dc=com" makes "sudoUser: %group_user1" work, so I can make a bug on "memberUid" requirement. However, it doesn't make "sudoUser: %#20001" work. Bare LDAP sudo backend works with this. Shall I make another bug on this? Ah, sorry, I assume that https://fedorahosted.org/sssd/ticket/1667 was opened for that. Shall we submit a corresponding bug to Bugzilla? Bug 880176 opened for primary group memberUid issue. Fixing the component. Not sure how it changed. Split into three: Bug 880150 Bug 880176 Bug 880335 |
Created attachment 637129 [details] The reproduction script, base LDIF file, sssd.conf and logs from the reproduction script execution Description of problem: sudoUser %group_name and %#group_id values result in always denied access, +netgroup_name values result in always allowed access. Version-Release number of selected component (if applicable): sssd-1.9.2-4.el6.x86_64 libsss_idmap-1.9.2-4.el6.x86_64 libsss_autofs-1.9.2-4.el6.x86_64 sssd-client-1.9.2-4.el6.x86_64 libsss_sudo-1.9.2-4.el6.x86_64 How reproducible: always Steps to Reproduce: 1. Use attached LDIF file to fill LDAP directory 2. Use attached sssd.conf as the base for client configuration 3. Execute attached sudo_user_spec_test on the client Actual results: %group_user1: DENIED %group_user2: DENIED %#20001: DENIED %#20002: DENIED +netgroup_user1: ALLOWED +netgroup_user2: ALLOWED Expected results: %group_user1: ALLOWED %group_user2: DENIED %#20001: ALLOWED %#20002: DENIED +netgroup_user1: ALLOWED +netgroup_user2: DENIED