#4324 Sudo runasgroup entry not generated by the sudo compat tree
Closed: Fixed None Opened 8 years ago by tbabej.

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.

Patch is already on review - Tomas forgot to switch the flag.

pushed to master as part of sudorule enhancements:

  • 5a1207c sudorule: PEP8 fixes in sudorule.py
  • a228d7a sudorule: Allow using hostmasks for setting allowed hosts
  • 9304b64 sudorule: Allow using external groups as groups of runAsUsers
  • fix: 3a56b15 sudorule: Make sure sudoRunAsGroup is dereferencing the correct attribute
  • c7da22c sudorule: Include externalhost and ipasudorunasextgroup in the list of default attributes
  • af2eb4d sudorule: Allow adding deny commands when command category set to ALL
  • 9bb88a1 sudorule: Make sure all the relevant attributes are checked when setting category to ALL
  • a1d6c9a sudorule: Fix the order of the parameters to have less chaotic output
  • b1275c5 sudorule: Enforce category ALL checks on dirsrv level
  • d537da8 ipatests: test_sudo: Add tests for allowing hosts via hostmasks
  • c50d190 ipatests: test_sudo: Add coverage for external entries
  • ec2050b ipatests: test_sudo: Add coverage for category ALL validation
  • e0fd269 ipatests: test_sudo: Fix assertions not assuming runasgroupcat set to ALL
  • 701f1fc ipatests: test_sudo: Do not expect enumeration of runasuser groups
  • e7969f5 ipatests: test_sudo: Expect root listed out if no RunAsUser available
  • af4518b sudorule: Refactor add and remove external_post_callback

Metadata Update from @tbabej:
- Issue assigned to tbabej
- Issue set to the milestone: FreeIPA 4.0 - 2014/06

5 years ago

Login to comment on this ticket.

Metadata