16

tl;dr

Sudo causes extra, useless alerts of "problem with defaults entries"

The environment

Ubuntu 16.04 Server LTS, sudo 1.8.16

The problem

Whenever a user (whether sssd-ad authenticated user, or local user, or root) uses sudo, it works. However, it also sends the administrator a useless email:

host1.example.com : Jun  6 14:40:44 : root : problem with defaults entries ; TTY=pts/2 ; PWD=/root ; 

There are no defaults entries anymore! I removed them during my troubleshooting. I tried leaving them in. They were, by the way:

Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

I cannot find the problem! I removed all my extra sudoers directives, and sudo (from root) still throws the error!

How do I make sudo stop sending me useless emails?

31

Solution

This problem is caused by sudo looking for directives in a place it cannot find them: sss. Check the /etc/nsswitch.conf file and modify the sudoers entry.

sudoers:        files sss

The sss should not be there. The sssd-ad package adds itself there, but very few environments store sudoers directives in sss. It’s far more likely your directives are local, so you should have a /etc/nsswitch file entry like the following:

sudoers:        files

References

A user of RHEL6 had the same issue. https://bugzilla.redhat.com/show_bug.cgi?id=879633
The issue is solvable, including on Ubuntu 16.04 https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1249777
https://bgstack15.wordpress.com/2016/06/06/solve-sudo-sending-useless-emails-problem-with-defaults-entries/

  • 1
    And if sudoers: is not present in /etc/nsswitch.conf at all? (No sssd installed...) – Gert van den Berg Oct 22 '18 at 17:08
3

Be aware, the accepted Solution will only take care of shutting up the emails when you're not actually using sudoers capabilities of sssd.

It's working around the problem until the next update of sssd-ad, and it will start sending again at the next update. I believe the packagers are looking into solving this clobbering of nsswitch directives.

When you DO want to use sudoers entries from AD/freeIPA, read on:

When you've got an actual upstream provider for sudo directives, you should set this:

$ grep -A 1 "[sssd]" /etc/sssd/sssd.conf
[sssd]
services = nss, sudo, pam, ssh

This will sadly not stop messages being send while freeipa-client installs. Still working on this. If i find something i'll add here

  • 1
    I ran into the same error and am using FreeIPA. As you mention, the accepted solution is not workable if you need sudoers to work with non-local FreeIPA users. In my case, a systemd service was calling sudo (as root) to switch users, and this occurred before the NSS user lookup service was running. I added this to the Unit section of the service file and it appears to have resolved the issue for my case: After=sssd.target nss-user-lookup.target – cherdt Feb 26 '18 at 21:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.