[Touch-packages] [Bug 1688034] Re: 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: sudo (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1688034 Title: 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd Status in sudo package in Ubuntu: Confirmed Bug description: ubuntu 16.04, enrolled with freeipa-client to FreeIPA 4.4.0 (under CentOS 7) With sudo 1.8.16-0ubuntu1, everything is fine: brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: root@api-dev:~# After update to 1.8.16-0ubuntu1.3, it no longer works: brian.candler@api-dev:~$ sudo -k brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: brian.candler is not allowed to run sudo on api-dev.int.example.com. This incident will be reported. This is repeatable: downgrade sudo and it works again. Seems very likely related to change made as part of #1607666, which changes how sudo policies are matched, but has unexpected regression. --- Additional info --- The sudo policy in IPA is extremely simple. It has a single rule, which says: - applies to users in groups "system_administrators" and "security_administrators" - applies to any host - applies to any command In LDAP under ou=sudoers tree, the groups are flattened out: # system administrators on all hosts, sudoers, ipa.example.com dn: cn=system administrators on all hosts,ou=sudoers,dc=ipa,dc=example,dc=com sudoRunAsGroup: ALL objectClass: sudoRole objectClass: top sudoUser: brian.candler sudoUser: ... sudoUser: ... list more users sudoUser: ... sudoRunAsUser: ALL sudoCommand: ALL sudoHost: ALL cn: system administrators on all hosts Under cn=sudorules,cn=sudo it refers to the groups rather than the individuals: # 59ffb10a-9c61-11e6-b5b8-00163efd5284, sudorules, sudo, ipa.example.com dn: ipaUniqueID=59ffb10a-9c61-11e6-b5b8-00163efd5284,cn=sudorules,cn=sudo,dc=ipa,dc=example,dc=com ipaSudoRunAsUserCategory: all ipaSudoRunAsGroupCategory: all description: admins have full sudo access on any host they can ssh into cmdCategory: all hostCategory: all memberUser: cn=system_administrators,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com memberUser: cn=security_administrators,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com objectClass: ipasudorule objectClass: ipaassociation ipaEnabledFlag: TRUE cn: system administrators on all hosts ipaUniqueID: 59ffb10a-9c61-11e6-b5b8-00163efd5284 I have no workaround other than downgrade. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: sudo 1.8.16-0ubuntu1.3 ProcVersionSignature: Ubuntu 4.4.0-1016.25-aws 4.4.59 Uname: Linux 4.4.0-1016-aws x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 Date: Wed May 3 16:01:23 2017 Ec2AMI: ami-a8d2d7ce Ec2AMIManifest: (unknown) Ec2AvailabilityZone: eu-west-1a Ec2InstanceType: t2.small Ec2Kernel: unavailable Ec2Ramdisk: unavailable ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: sudo UpgradeStatus: No upgrade log present (probably fresh install) VisudoCheck: /etc/sudoers: parsed OK /etc/sudoers.d/90-cloud-init-users: parsed OK /etc/sudoers.d/README: parsed OK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1688034/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1688034] Re: 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd
I guess this also makes 1.8.16-0ubuntu1.3 a "security" update, since sudo+sssd now enforces policy which it should have done before, but didn't. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1688034 Title: 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd Status in sudo package in Ubuntu: New Bug description: ubuntu 16.04, enrolled with freeipa-client to FreeIPA 4.4.0 (under CentOS 7) With sudo 1.8.16-0ubuntu1, everything is fine: brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: root@api-dev:~# After update to 1.8.16-0ubuntu1.3, it no longer works: brian.candler@api-dev:~$ sudo -k brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: brian.candler is not allowed to run sudo on api-dev.int.example.com. This incident will be reported. This is repeatable: downgrade sudo and it works again. Seems very likely related to change made as part of #1607666, which changes how sudo policies are matched, but has unexpected regression. --- Additional info --- The sudo policy in IPA is extremely simple. It has a single rule, which says: - applies to users in groups "system_administrators" and "security_administrators" - applies to any host - applies to any command In LDAP under ou=sudoers tree, the groups are flattened out: # system administrators on all hosts, sudoers, ipa.example.com dn: cn=system administrators on all hosts,ou=sudoers,dc=ipa,dc=example,dc=com sudoRunAsGroup: ALL objectClass: sudoRole objectClass: top sudoUser: brian.candler sudoUser: ... sudoUser: ... list more users sudoUser: ... sudoRunAsUser: ALL sudoCommand: ALL sudoHost: ALL cn: system administrators on all hosts Under cn=sudorules,cn=sudo it refers to the groups rather than the individuals: # 59ffb10a-9c61-11e6-b5b8-00163efd5284, sudorules, sudo, ipa.example.com dn: ipaUniqueID=59ffb10a-9c61-11e6-b5b8-00163efd5284,cn=sudorules,cn=sudo,dc=ipa,dc=example,dc=com ipaSudoRunAsUserCategory: all ipaSudoRunAsGroupCategory: all description: admins have full sudo access on any host they can ssh into cmdCategory: all hostCategory: all memberUser: cn=system_administrators,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com memberUser: cn=security_administrators,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com objectClass: ipasudorule objectClass: ipaassociation ipaEnabledFlag: TRUE cn: system administrators on all hosts ipaUniqueID: 59ffb10a-9c61-11e6-b5b8-00163efd5284 I have no workaround other than downgrade. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: sudo 1.8.16-0ubuntu1.3 ProcVersionSignature: Ubuntu 4.4.0-1016.25-aws 4.4.59 Uname: Linux 4.4.0-1016-aws x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 Date: Wed May 3 16:01:23 2017 Ec2AMI: ami-a8d2d7ce Ec2AMIManifest: (unknown) Ec2AvailabilityZone: eu-west-1a Ec2InstanceType: t2.small Ec2Kernel: unavailable Ec2Ramdisk: unavailable ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: sudo UpgradeStatus: No upgrade log present (probably fresh install) VisudoCheck: /etc/sudoers: parsed OK /etc/sudoers.d/90-cloud-init-users: parsed OK /etc/sudoers.d/README: parsed OK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1688034/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1688034] Re: 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd
I found out how to enable debugging for sudoers: Debug sudo /var/log/sudo-debug all@info Debug sudoers.so /var/log/sudoers-debug all@info With the *new* sudo I get the following logged matching 'sssd': May 5 12:40:06 sudo[17912] sssd/ldap sudoHost 'ALL' ... MATCH! May 5 12:40:06 sudo[17912] sssd/ldap sudoUser '%system_administrators' ... not (brian.candler) May 5 12:40:06 sudo[17912] sssd/ldap sudoUser '%security_administrators' ... not (brian.candler) But with the *old* sudo I get: May 5 12:41:48 sudo[18384] sssd/ldap sudoHost 'ALL' ... MATCH! May 5 12:41:48 sudo[18384] sssd/ldap sudoRunAsUser 'ALL' ... MATCH! May 5 12:41:48 sudo[18384] sssd/ldap sudoCommand 'ALL' ... MATCH! It seems to be a behaviour change with group checking. The 'brian.candler' user *is* a member of one of those groups in IPA; but those groups are not posix groups so they are not visible using (e.g.) "id" I was able to solve the problem by adding objectClass: posixgroup gidNumber: to those group objects. After this, the sudoers log shows: May 5 13:11:50 sudo[19545] sssd/ldap sudoHost 'ALL' ... MATCH! May 5 13:11:50 sudo[19545] sssd/ldap sudoUser '%system_administrators' ... not (brian.candler) May 5 13:11:50 sudo[19545] sssd/ldap sudoUser '%security_administrators' ... MATCH! (brian.candler) May 5 13:11:50 sudo[19545] sssd/ldap sudoRunAsUser 'ALL' ... MATCH! May 5 13:11:50 sudo[19545] sssd/ldap sudoCommand 'ALL' ... MATCH! So: arguably this is not a bug, but a bug fix. Still, it would be nice if the release notes explained the potential for regression. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1688034 Title: 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd Status in sudo package in Ubuntu: New Bug description: ubuntu 16.04, enrolled with freeipa-client to FreeIPA 4.4.0 (under CentOS 7) With sudo 1.8.16-0ubuntu1, everything is fine: brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: root@api-dev:~# After update to 1.8.16-0ubuntu1.3, it no longer works: brian.candler@api-dev:~$ sudo -k brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: brian.candler is not allowed to run sudo on api-dev.int.example.com. This incident will be reported. This is repeatable: downgrade sudo and it works again. Seems very likely related to change made as part of #1607666, which changes how sudo policies are matched, but has unexpected regression. --- Additional info --- The sudo policy in IPA is extremely simple. It has a single rule, which says: - applies to users in groups "system_administrators" and "security_administrators" - applies to any host - applies to any command In LDAP under ou=sudoers tree, the groups are flattened out: # system administrators on all hosts, sudoers, ipa.example.com dn: cn=system administrators on all hosts,ou=sudoers,dc=ipa,dc=example,dc=com sudoRunAsGroup: ALL objectClass: sudoRole objectClass: top sudoUser: brian.candler sudoUser: ... sudoUser: ... list more users sudoUser: ... sudoRunAsUser: ALL sudoCommand: ALL sudoHost: ALL cn: system administrators on all hosts Under cn=sudorules,cn=sudo it refers to the groups rather than the individuals: # 59ffb10a-9c61-11e6-b5b8-00163efd5284, sudorules, sudo, ipa.example.com dn: ipaUniqueID=59ffb10a-9c61-11e6-b5b8-00163efd5284,cn=sudorules,cn=sudo,dc=ipa,dc=example,dc=com ipaSudoRunAsUserCategory: all ipaSudoRunAsGroupCategory: all description: admins have full sudo access on any host they can ssh into cmdCategory: all hostCategory: all memberUser: cn=system_administrators,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com memberUser: cn=security_administrators,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com objectClass: ipasudorule objectClass: ipaassociation ipaEnabledFlag: TRUE cn: system administrators on all hosts ipaUniqueID: 59ffb10a-9c61-11e6-b5b8-00163efd5284 I have no workaround other than downgrade. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: sudo 1.8.16-0ubuntu1.3 ProcVersionSignature: Ubuntu 4.4.0-1016.25-aws 4.4.59 Uname: Linux 4.4.0-1016-aws x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 Date: Wed May 3 16:01:23 2017 Ec2AMI: ami-a8d2d7ce Ec2AMIManifest: (unknown) Ec2AvailabilityZone: eu-west-1a Ec2InstanceType: t2.small Ec2Kernel: unavailable Ec2Ramdisk: unavailable ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: sudo UpgradeStatus: No upgrade log present (probably fresh install) VisudoCheck: /etc/sudoers: parsed OK /etc/sudoers.d/90-cloud-init-users: parsed OK /etc/sudoers.d/README: parsed OK To manage notifications about this bug go to:
[Touch-packages] [Bug 1688034] Re: 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd
Now trying with @debug instead of @info Slight munging of output to make it diffable, then diff -u: --- v1.debug.trim 2017-05-03 20:28:07.78400 + +++ v2.debug.trim 2017-05-03 20:28:14.03200 + @@ -38,87 +38,6 @@ -> parse_args @ /build/sudo-XX/sudo-1.8.16/src/parse_args.c:172 -> get_net_ifs @ /build/sudo-XX/sudo-1.8.16/src/net_ifs.c:120 <- get_net_ifs @ /build/sudo-XX/sudo-1.8.16/src/net_ifs.c:205 := 3 -<- parse_args @ /build/sudo-XX/sudo-1.8.16/src/parse_args.c:512 := 8 -sudo_mode 8 --> sudo_load_plugins @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:283 --> sudo_load_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:160 --> sudo_check_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:112 --> sudo_stat_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:46 -<- sudo_stat_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:104 := 0 -<- sudo_check_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:137 := true --> sudo_conf_debug_files_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/sudo_conf.c:509 -<- sudo_conf_debug_files_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/sudo_conf.c:535 := (nil) -<- sudo_load_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:255 := true --> sudo_load_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:160 --> sudo_check_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:112 --> sudo_stat_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:46 -<- sudo_stat_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:104 := 0 -<- sudo_check_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:137 := true --> sudo_conf_debug_files_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/sudo_conf.c:509 -<- sudo_conf_debug_files_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/sudo_conf.c:535 := (nil) -<- sudo_load_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:255 := true -<- sudo_load_plugins @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:352 := true --> policy_open @ /build/sudo-XX/sudo-1.8.16/src/sudo.c:1231 --> format_plugin_settings @ /build/sudo-XX/sudo-1.8.16/src/sudo.c:1175 --> sudo_new_key_val_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/key_val.c:44 -<- sudo_new_key_val_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/key_val.c:56 := plugin_path=/usr/lib/sudo/sudoers.so -settings: progname=sudo --> sudo_new_key_val_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/key_val.c:44 -<- sudo_new_key_val_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/key_val.c:56 := progname=sudo -settings: network_addrs=10.0.0.230/255.255.255.0 :::::230/::::::: fe80::1:::/::::: --> sudo_new_key_val_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/key_val.c:44 -<- sudo_new_key_val_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/key_val.c:56 := network_addrs=10.0.0.230/255.255.255.0 :::::230/::::::: fe80::1:::/::::: -settings: plugin_dir=/usr/lib/sudo/ --> sudo_new_key_val_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/key_val.c:44 -<- sudo_new_key_val_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/key_val.c:56 := plugin_dir=/usr/lib/sudo/ -<- format_plugin_settings @ /build/sudo-XX/sudo-1.8.16/src/sudo.c:1217 := 0x -<- policy_open @ /build/sudo-XX/sudo-1.8.16/src/sudo.c:1261 := 1 --> init_signals @ /build/sudo-XX/sudo-1.8.16/src/signal.c:121 --> pipe_nonblock @ /build/sudo-XX/sudo-1.8.16/src/exec.c:975 -<- pipe_nonblock @ /build/sudo-XX/sudo-1.8.16/src/exec.c:993 := 0 -<- init_signals @ /build/sudo-XX/sudo-1.8.16/src/signal.c:154 --> policy_invalidate @ /build/sudo-XX/sudo-1.8.16/src/sudo.c:1350 -<- policy_invalidate @ /build/sudo-XX/sudo-1.8.16/src/sudo.c:1358 --> sudo_check_suid @ /build/sudo-XX/sudo-1.8.16/src/sudo.c:828 -<- sudo_check_suid @ /build/sudo-XX/sudo-1.8.16/src/sudo.c:872 --> save_signals @ /build/sudo-XX/sudo-1.8.16/src/signal.c:64 -<- save_signals @ /build/sudo-XX/sudo-1.8.16/src/signal.c:71 --> sudo_conf_read_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/sudo_conf.c:562 --> sudo_secure_path @ /build/sudo-XX/sudo-1.8.16/lib/util/secure_path.c:43 -<- sudo_secure_path @ /build/sudo-XX/sudo-1.8.16/lib/util/secure_path.c:62 := 0 --> sudo_parseln_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/parseln.c:55 -<- sudo_parseln_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/parseln.c:118 := 40 --> sudo_parseln_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/parseln.c:55 -<- sudo_parseln_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/parseln.c:118 := 46 --> sudo_parseln_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/parseln.c:55 -<- sudo_parseln_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/parseln.c:117 := -1 -<- sudo_conf_read_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/sudo_conf.c:651 := 1 --> get_user_info @
[Touch-packages] [Bug 1688034] Re: 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd
Some additional info. I enabled sudo debugging by creating /etc/sudo.conf containing: Debug sudo /var/log/sudo-debug all@info Debug sudoers /var/log/sudoers-debug all@info With the newer (non-functioning) sudo, /var/log/sudo-debug contains: May 3 18:55:50 sudo[8003] comparing dev 34817 to /dev/pts/1: match! @ sudo_ttyname_dev() /build/sudo-40pSZP/sudo-1.8.16/src/ttyname.c:336 May 3 18:55:50 sudo[8003] settings: run_shell=true May 3 18:55:50 sudo[8003] settings: progname=sudo May 3 18:55:50 sudo[8003] settings: network_addrs=10.0.0.230/255.255.255.0 :::::230/::::::: fe80::1:::/::::: May 3 18:55:50 sudo[8003] settings: plugin_dir=/usr/lib/sudo/ May 3 18:55:51 sudo[8003] policy plugin returns 0 With the older (working) sudo, /var/log/sudo-debug contains: May 3 19:00:19 sudo[8746] comparing dev 34817 to /dev/pts/1: match! @ sudo_ttyname_dev() /build/sudo-g3ghsu/sudo-1.8.16/src/ttyname.c:336 May 3 19:00:19 sudo[8746] settings: run_shell=true May 3 19:00:19 sudo[8746] settings: progname=sudo May 3 19:00:19 sudo[8746] settings: network_addrs=10.0.0.230/255.255.255.0 :::::230/::::::: fe80::1:::/::::: May 3 19:00:19 sudo[8746] settings: plugin_dir=/usr/lib/sudo/ May 3 19:00:22 sudo[8746] policy plugin returns 1 May 3 19:00:22 sudo[8746] settings: run_shell=true May 3 19:00:22 sudo[8746] settings: progname=sudo May 3 19:00:22 sudo[8746] settings: network_addrs=10.0.0.230/255.255.255.0 :::::230/::::::: fe80::1:::/::::: May 3 19:00:22 sudo[8746] settings: plugin_dir=/usr/lib/sudo/ May 3 19:00:22 sudo[8746] command info from plugin: May 3 19:00:22 sudo[8746] 0: command=/bin/bash May 3 19:00:22 sudo[8746] 1: runas_uid=0 May 3 19:00:22 sudo[8746] 2: runas_gid=0 May 3 19:00:22 sudo[8746] 3: runas_groups=0 May 3 19:00:22 sudo[8746] 4: closefrom=3 May 3 19:00:22 sudo[8746] 5: set_utmp=true May 3 19:00:22 sudo[8746] 6: umask=022 May 3 19:00:22 sudo[8746] executed /bin/bash, pid 8754 May 3 19:00:22 sudo[8746] sudo_ev_add_v1: adding event 0x55e83b06c630 to base 0x55e83b07ea40 May 3 19:00:22 sudo[8746] sudo_ev_add_v1: adding event 0x55e83b078180 to base 0x55e83b07ea40 May 3 19:00:22 sudo[8746] signal pipe fd 10 May 3 19:00:22 sudo[8746] backchannel fd 5 May 3 19:00:22 sudo[8754] exec /bin/bash [/bin/bash] May 3 19:00:22 sudo[8746] sudo_ev_scan_impl: 1 fds ready May 3 19:00:22 sudo[8746] failed to read child status: EOF May 3 19:00:22 sudo[8746] sudo_ev_del_v1: removing event 0x55e83b078180 from base 0x55e83b07ea40 (/var/log/sudoers-debug is not created in either case) Note "policy plugin returns 0" in the first case. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1688034 Title: 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd Status in sudo package in Ubuntu: New Bug description: ubuntu 16.04, enrolled with freeipa-client to FreeIPA 4.4.0 (under CentOS 7) With sudo 1.8.16-0ubuntu1, everything is fine: brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: root@api-dev:~# After update to 1.8.16-0ubuntu1.3, it no longer works: brian.candler@api-dev:~$ sudo -k brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: brian.candler is not allowed to run sudo on api-dev.int.example.com. This incident will be reported. This is repeatable: downgrade sudo and it works again. Seems very likely related to change made as part of #1607666, which changes how sudo policies are matched, but has unexpected regression. --- Additional info --- The sudo policy in IPA is extremely simple. It has a single rule, which says: - applies to users in groups "system_administrators" and "security_administrators" - applies to any host - applies to any command In LDAP under ou=sudoers tree, the groups are flattened out: # system administrators on all hosts, sudoers, ipa.example.com dn: cn=system administrators on all hosts,ou=sudoers,dc=ipa,dc=example,dc=com sudoRunAsGroup: ALL objectClass: sudoRole objectClass: top sudoUser: brian.candler sudoUser: ... sudoUser: ... list more users sudoUser: ... sudoRunAsUser: ALL sudoCommand: ALL sudoHost: ALL cn: system administrators on all hosts Under cn=sudorules,cn=sudo it refers to the groups rather than the individuals: # 59ffb10a-9c61-11e6-b5b8-00163efd5284, sudorules, sudo, ipa.example.com dn: ipaUniqueID=59ffb10a-9c61-11e6-b5b8-00163efd5284,cn=sudorules,cn=sudo,dc=ipa,dc=example,dc=com ipaSudoRunAsUserCategory: all ipaSudoRunAsGroupCategory: all description: admins have full sudo access on any host they can ssh into cmdCategory: all
