Given the following sudo rule:
[root@vm-243 tbabej]# ipa sudorule-show testrule Rule name: testrule Enabled: TRUE User category: all Host category: all Sudo Allow Commands: /usr/bin/yum Sudo Allow Command Groups: readers Sudo Option: !authenticate RunAs Groups: testgroup2
The RunAs group is not available on the client:
[root@vm-246 ~]# su -c "sudo -ll" testuser1 User testuser1 may run the following commands on vm-246: RunAsUsers: root Options: !authenticate Commands: /usr/bin/cat /usr/bin/yum
Reason being - it is not generated in the sudo compat tree:
[root@vm-243 tbabej]# ldapsearch -h `hostname` -D 'cn=Directory Manager' -w Secret123 -b 'dc=ipa,dc=test' "cn=testrule" # extended LDIF # # LDAPv3 # base <dc=ipa,dc=test> with scope subtree # filter: cn=testrule # requesting: ALL # # testrule, sudoers, ipa.test dn: cn=testrule,ou=sudoers,dc=ipa,dc=test sudoCommand: /usr/bin/cat sudoCommand: /usr/bin/yum objectClass: sudoRole objectClass: top sudoUser: ALL sudoHost: ALL sudoOption: !authenticate cn: testrule # a2533874-cb9d-11e3-bcb0-001a4a2221cd, sudorules, sudo, ipa.test dn: ipaUniqueID=a2533874-cb9d-11e3-bcb0-001a4a2221cd,cn=sudorules,cn=sudo,dc=i pa,dc=test cn: testrule objectClass: ipasudorule objectClass: ipaassociation ipaEnabledFlag: TRUE ipaUniqueID: a2533874-cb9d-11e3-bcb0-001a4a2221cd ipaSudoOpt: !authenticate userCategory: all hostCategory: all memberAllowCmd: cn=readers,cn=sudocmdgroups,cn=sudo,dc=ipa,dc=test memberAllowCmd: ipaUniqueID=a13bda22-cb9d-11e3-9e89-001a4a2221cd,cn=sudocmds,c n=sudo,dc=ipa,dc=test ipaSudoRunAsGroup: cn=testgroup2,cn=groups,cn=accounts,dc=ipa,dc=test # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2
Note the difference between # testrule, sudoers, ipa.test and # a2533874-cb9d-11e3-bcb0-001a4a2221cd, sudorules, sudo, ipa.test on ipaSudoRunAsGroup entry.
What kind of group is testgroup2? It needs to be a POSIX group. See ticket #4314
Both groups are POSIX groups:
[tbabej@vm-105 ~]$ ipa group-show testgroup1 Group name: testgroup1 Description: "1. testing group" GID: 729000003 Member users: testuser1 [tbabej@vm-105 ~]$ ipa group-show testgroup2 Group name: testgroup2 Description: "2. testing group" GID: 729000005 Member users: testuser2
Additional info:
When some RunAsUser is set for the testrule, strangely enough, that user's full name is stated as the RunAsGroup!
[tbabej@vm-105 ~]$ ipa sudorule-show testrule Rule name: testrule Enabled: TRUE User category: all Host category: all Command category: all RunAs Users: testuser1 Sudo Option: !authenticate RunAs Groups: testgroup1, testgroup2
However, the entry exported by the compat tree contains:
[tbabej@vm-105 ~]$ ldapsearch -h `hostname` -D 'cn=Directory Manager' -w Secret123 -b 'dc=ipa,dc=test' "cn=testrule" # extended LDIF # # LDAPv3 # base <dc=ipa,dc=test> with scope subtree # filter: cn=testrule # requesting: ALL # # testrule, sudoers, ipa.test dn: cn=testrule,ou=sudoers,dc=ipa,dc=test sudoCommand: ALL sudoRunAsUser: testuser1 objectClass: sudoRole objectClass: top sudoRunAsGroup: Test User1 sudoUser: ALL sudoHost: ALL sudoOption: !authenticate cn: testrule
Even though the testrule in LDAP definition is correct:
# 28f3f78a-cee9-11e3-b81a-001a4a2221c2, sudorules, sudo, ipa.test dn: ipaUniqueID=28f3f78a-cee9-11e3-b81a-001a4a2221c2,cn=sudorules,cn=sudo,dc=i pa,dc=test cn: testrule objectClass: ipasudorule objectClass: ipaassociation ipaEnabledFlag: TRUE ipaUniqueID: 28f3f78a-cee9-11e3-b81a-001a4a2221c2 ipaSudoOpt: !authenticate userCategory: all hostCategory: all cmdCategory: all ipaSudoRunAsGroup: cn=testgroup2,cn=groups,cn=accounts,dc=ipa,dc=test ipaSudoRunAsGroup: cn=testgroup1,cn=groups,cn=accounts,dc=ipa,dc=test ipaSudoRunAs: uid=testuser1,cn=users,cn=accounts,dc=ipa,dc=test
Note: This happens regardless of the fact if the rule has any RunAsGroups already configured.
What does your configuration look like?
cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
It should contain
sudoRunAsGroup=%deref_f("ipaSudoRunAsGroup","(objectclass=posixGroup)","cn")
Which is dereferencing the group to test the objectclass correctly but apparently getting the cn value from the user defined by ipaSudoRunAs.
It contains:
sudoRunAsGroup=%deref("ipaSudoRunAs","cn") sudoRunAsGroup=%{ipaSudoRunAsExtGroup}
which is clearly the source of the error, as the sudoRunAsGroup dereferences the ipaSudoRunAs attribute.
That should have been fixed by https://fedorahosted.org/freeipa/ticket/1309
May be regression of https://bugzilla.redhat.com/show_bug.cgi?id=711786. We should fix in 4.0.
Starting review
Patch is already on review - Tomas forgot to switch the flag.
pushed to master as part of sudorule enhancements:
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1113920
Metadata Update from @tbabej: - Issue assigned to tbabej - Issue set to the milestone: FreeIPA 4.0 - 2014/06
Login to comment on this ticket.