Red Hat Bugzilla – Bug 711786
sudorunasgroup automatically picks up incorrect value while adding a sudorunasuser.
Last modified: 2015-01-04 18:49:10 EST
Description of problem: Version-Release number of selected component (if applicable): ipa-server-2.0.0-25.el6.x86_64 ipa-admintools-2.0.0-25.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. # ipa user-add testuser First name: test Last name: user --------------------- Added user "testuser" --------------------- User login: testuser First name: test Last name: user Full name: test user Display name: test user Initials: tu Home directory: /home/testuser GECOS field: testuser Login shell: /bin/sh Kerberos principal: testuser@LAB.ENG.PNQ.REDHAT.COM UID: 1866400014 2. # ipa sudorule-add-runasuser sudorule3 --users=testuser Rule name: sudorule3 Enabled: TRUE Users: shanks Groups: group1 Hosts: mudflap.lab.eng.pnq.redhat.com Sudo Allow Commands: /bin/ls, /bin/df, /bin/ln, /bin/pwd, /bin/hostname Sudo Command Groups: basic cmd Run As User: testuser ------------------------- Number of members added 1 ------------------------- 3. In DS: dn: cn=sudorule3,ou=sudoers,dc=lab,dc=eng,dc=pnq,dc=redhat,dc=com objectClass: sudoRole objectClass: extensibleObject objectClass: top [...] sudorunasuser: testuser sudorunasgroup: test user <<<<<<<< cn: sudorule3 4. And in client: -sh-4.1$ sudo -l [...] [sudo] password for shanks: sudo: ldap search '(|(sudoUser=shanks)(sudoUser=%shanks)(sudoUser=%ipausers)(sudoUser=%group1)(sudoUser=ALL))' sudo: ldap sudoHost 'mudflap.lab.eng.pnq.redhat.com' ... MATCH! sudo: ldap search 'sudoUser=+*' User shanks may run the following commands on this host: (test1, test3, test2, test4, testuser : test user) /bin/ls, /bin/df, /bin/ln, /bin/pwd, /bin/hostname Actual results: 1. While adding a sudorunasuser, its corresponding sudorunasgroup get added automatically. "sudorunasgroup: test user" in this case. 2. "test user" gets displayed as a runasgroup on the ldap and client. I believe "cn:" attribute is picked up here which is incorrect group name. Expected results: As no new members can be added to the private group, I am inclined to say that automatically adding the users private group as sudorunasgroup is valid, however, it should pick up the correct value which is "uid". Additional info:
https://fedorahosted.org/freeipa/ticket/1309
master: 9821160d893bf35069119339cf9edb15a697afe1 78c3abd6bae2e2b8f2725beeeda41d718ba5dc17 ipa-2-0: 104b1b801c030c396870e234898b8daaddb667a6 13ad21135e993adda39ffbc5749a710ff2e3c148
verified: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Bug 711786: sudorunasgroup automatically picks up incorrect value while adding a sudorunasuser. :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: kinit as admin with password Secret123 was successful. :: [ PASS ] :: Kinit as admin user :: [ PASS ] :: Running 'ipa user-add shanks --first=shanks --last=r' :: [ PASS ] :: Running 'ipa sudorule-add rule1' :: [ PASS ] :: Running 'ipa sudorule-add-runasuser rule1 --users=shanks' :: [ PASS ] :: Running '/usr/bin/ldapsearch -x -h apollo.testrelm -D "cn=Directory Manager" -w Secret123 -b cn=rule1,ou=sudoers,dc=testrelm > /tmp/tmp.2wPVb2wcQB/bug711786.ldif' :: [ PASS ] :: File '/tmp/tmp.2wPVb2wcQB/bug711786.ldif' should not contain 'sudorunasgroup: shanks r' :: [ PASS ] :: Running 'cat /tmp/tmp.2wPVb2wcQB/bug711786.ldif' :: [ PASS ] :: Running 'ipa sudorule-del rule1' :: [ PASS ] :: Running 'ipa user-del shanks' :: [ LOG ] :: Duration: 12s :: [ LOG ] :: Assertions: 9 good, 0 bad :: [ PASS ] :: RESULT: Bug 711786: sudorunasgroup automatically picks up incorrect value while adding a sudorunasuser. version: ipa-server-2.1.1-4.el6.x86_64
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: When setting runAsGroup in a sudurole as a user the name of that user is returned as the name of a group that may also be used as the runAsGroup. Consequence: The sudorule was incorrect, referring to a non-existent group. Fix: The search filter for determining the cn value was too generic. Added a test for objectclass=posixGroup. Result: User names will no longer appear as runAsGroup values.
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, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2011-1533.html