Brian Candler
2017-05-03 08:04:05 UTC
Hi,
I have FreeIPA set up under CentOS 7. When I use freeipa-client to add
an ubuntu 14.04 client it works fine (*). However when do the same with
ubuntu 16.04, sudo always refuses to run:
$ 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.
I have a simple one-entry sudo policy which says that for all users in
groups X and Y, on all hosts, run all commands. (**)
If I crank up sudo logging by setting this in /etc/sudo.conf:
Debug sudo /var/log/sudo-debug ***@info
then on the working 14.04 machine I see
... various settings ...
May 2 22:05:27 sudo[19175] settings: plugin_dir=/usr/lib/sudo/
May 2 22:05:27 sudo[19175] user_info: user=brian.candler
May 2 22:05:27 sudo[19175] user_info: pid=19175
... lots more user_info, perms, netgroups etc ...
May 2 22:05:29 sudo[19175] policy plugin returns 1
...
but on the failing 16.04 machine I see only this:
May 3 07:44:56 sudo[21118] will restore signal 13 on exec
May 3 07:44:56 sudo[21118] comparing dev 34817 to /dev/pts/1: match! @
sudo_ttyname_dev() ./ttyname.c:336
May 3 07:44:56 sudo[21118] settings: run_shell=true
May 3 07:44:56 sudo[21118] settings: progname=sudo
May 3 07:44:56 sudo[21118] settings:
network_addrs=x.x.x.x/255.255.255.0
xxxx:xxxx:xxxx:xxxx::230/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
fe80::1:xxxx:xxxx:xxxx/ffff:ffff:ffff:ffff::
May 3 07:44:56 sudo[21118] settings: plugin_dir=/usr/lib/sudo/
May 3 07:44:58 sudo[21118] policy plugin returns 0
That's all that gets logged - nothing more. It seems that a return of 0
means failure:
https://www.sudo.ws/man/1.8.15/sudo_plugin.man.html
"open()
...
Returns 1 on success, 0 on failure, -1 if a general error occurred, or
-2 if there was a usage error."
But I have no idea what sort of failure or why.
/var/log/auth.log shows:
May 3 08:00:14 api-dev sudo: pam_unix(sudo:auth): authentication
failure; logname=brian.candler uid=1211000003 euid=0 tty=/dev/pts/1
ruser=brian.candler rhost= user=brian.candler
May 3 08:00:14 api-dev sudo: pam_sss(sudo:auth): authentication
success; logname=brian.candler uid=1211000003 euid=0 tty=/dev/pts/1
ruser=brian.candler rhost= user=brian.candler
May 3 08:00:14 api-dev sudo: brian.candler : user NOT in sudoers ;
TTY=pts/1 ; PWD=/home/brian.candler ; USER=root ; COMMAND=/bin/bash
(which shows I gave the correct FreeIPA password, but not why the
sudoers lookup failed)
I really can't see where else to look. Both machines have "sudo: files
sss" in /etc/nsswitch.conf, and both have the same /etc/sssd/sssd.conf.
Setting "sss_debuglevel 7" and "sss_cache -UG" shows a lot of noise but
no obvious errors.
I've also upgraded to the latest sudo_1.8.19-3_amd64.deb package from
https://www.sudo.ws/download.html, but this makes no difference.
Has anyone seen this problem before, or have some ideas where else to look?
Thanks,
Brian Candler.
(*) In Ubuntu 14.04 I had to manually add sudo to the list of sssd services:
|[sssd]|
|services = nss, pam, ssh, sudo|
but this was done automatically by freeipa-client in Ubuntu 16.04.
(**) Therefore I'm pretty sure this is not the netgroups problem, for
which the fix has been released anyway:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1607666
I have FreeIPA set up under CentOS 7. When I use freeipa-client to add
an ubuntu 14.04 client it works fine (*). However when do the same with
ubuntu 16.04, sudo always refuses to run:
$ 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.
I have a simple one-entry sudo policy which says that for all users in
groups X and Y, on all hosts, run all commands. (**)
If I crank up sudo logging by setting this in /etc/sudo.conf:
Debug sudo /var/log/sudo-debug ***@info
then on the working 14.04 machine I see
... various settings ...
May 2 22:05:27 sudo[19175] settings: plugin_dir=/usr/lib/sudo/
May 2 22:05:27 sudo[19175] user_info: user=brian.candler
May 2 22:05:27 sudo[19175] user_info: pid=19175
... lots more user_info, perms, netgroups etc ...
May 2 22:05:29 sudo[19175] policy plugin returns 1
...
but on the failing 16.04 machine I see only this:
May 3 07:44:56 sudo[21118] will restore signal 13 on exec
May 3 07:44:56 sudo[21118] comparing dev 34817 to /dev/pts/1: match! @
sudo_ttyname_dev() ./ttyname.c:336
May 3 07:44:56 sudo[21118] settings: run_shell=true
May 3 07:44:56 sudo[21118] settings: progname=sudo
May 3 07:44:56 sudo[21118] settings:
network_addrs=x.x.x.x/255.255.255.0
xxxx:xxxx:xxxx:xxxx::230/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
fe80::1:xxxx:xxxx:xxxx/ffff:ffff:ffff:ffff::
May 3 07:44:56 sudo[21118] settings: plugin_dir=/usr/lib/sudo/
May 3 07:44:58 sudo[21118] policy plugin returns 0
That's all that gets logged - nothing more. It seems that a return of 0
means failure:
https://www.sudo.ws/man/1.8.15/sudo_plugin.man.html
"open()
...
Returns 1 on success, 0 on failure, -1 if a general error occurred, or
-2 if there was a usage error."
But I have no idea what sort of failure or why.
/var/log/auth.log shows:
May 3 08:00:14 api-dev sudo: pam_unix(sudo:auth): authentication
failure; logname=brian.candler uid=1211000003 euid=0 tty=/dev/pts/1
ruser=brian.candler rhost= user=brian.candler
May 3 08:00:14 api-dev sudo: pam_sss(sudo:auth): authentication
success; logname=brian.candler uid=1211000003 euid=0 tty=/dev/pts/1
ruser=brian.candler rhost= user=brian.candler
May 3 08:00:14 api-dev sudo: brian.candler : user NOT in sudoers ;
TTY=pts/1 ; PWD=/home/brian.candler ; USER=root ; COMMAND=/bin/bash
(which shows I gave the correct FreeIPA password, but not why the
sudoers lookup failed)
I really can't see where else to look. Both machines have "sudo: files
sss" in /etc/nsswitch.conf, and both have the same /etc/sssd/sssd.conf.
Setting "sss_debuglevel 7" and "sss_cache -UG" shows a lot of noise but
no obvious errors.
I've also upgraded to the latest sudo_1.8.19-3_amd64.deb package from
https://www.sudo.ws/download.html, but this makes no difference.
Has anyone seen this problem before, or have some ideas where else to look?
Thanks,
Brian Candler.
(*) In Ubuntu 14.04 I had to manually add sudo to the list of sssd services:
|[sssd]|
|services = nss, pam, ssh, sudo|
but this was done automatically by freeipa-client in Ubuntu 16.04.
(**) Therefore I'm pretty sure this is not the netgroups problem, for
which the fix has been released anyway:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1607666