Bug 711786

Summary: sudorunasgroup automatically picks up incorrect value while adding a sudorunasuser.
Product: Red Hat Enterprise Linux 6 Reporter: Gowrishankar Rajaiyan <grajaiya>
Component: ipaAssignee: Rob Crittenden <rcritten>
Status: CLOSED ERRATA QA Contact: Chandrasekar Kannan <ckannan>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.2CC: benl, dpal, jgalipea
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ipa-2.1.0-1.el6 Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-06 18:33:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Gowrishankar Rajaiyan 2011-06-08 13:39:05 UTC
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.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:

Comment 2 Rob Crittenden 2011-06-08 13:53:03 UTC
https://fedorahosted.org/freeipa/ticket/1309

Comment 3 Rob Crittenden 2011-07-20 03:26:40 UTC
master: 9821160d893bf35069119339cf9edb15a697afe1 78c3abd6bae2e2b8f2725beeeda41d718ba5dc17

ipa-2-0: 104b1b801c030c396870e234898b8daaddb667a6 13ad21135e993adda39ffbc5749a710ff2e3c148

Comment 5 Jenny Severance 2011-10-05 18:39:24 UTC
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

Comment 6 Rob Crittenden 2011-10-31 19:52:14 UTC
    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.

Comment 7 errata-xmlrpc 2011-12-06 18:33:31 UTC
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