33

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?

Improve this question

5 Answers 5

Reset to default
47

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/

Improve this answer
3
  • 3
    And if sudoers: is not present in /etc/nsswitch.conf at all? (No sssd installed...)
    – Gert van den Berg
    Oct 22, 2018 at 17:08
  • 1
    Another issue with the accepted solution is that the problem can be caused by various other issues, for instance issues with the /etc/hosts file. See the comments to the last link in the references section.
    – Kevin Keane
    May 3, 2020 at 6:04
  • No answer can solve everyone's problem, but this was indeed the cause of mine, thanks @bgStack15. I'd been tearing apart my /etc/sudoers.d/ files looking for a syntax issue that wasn't there.
    – FeRD
    Aug 30, 2020 at 6:00
11

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

Improve this answer
3
  • 2
    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, 2018 at 21:43
  • 1
    @Quattro et al: 1. What does When you've got an actual upstream provider for sudo directives mean? Does an "upstream provider" mean something more than a freeipa client? 2. Is there any problem making this /etc/sssd/sssd.conf change prior to having such an upstream provider, in order to make my system config(s) more flexible for the future?
    – Johnny Utahh
    Mar 9, 2020 at 15:03
  • 1
    @JohnnyUtahh Yes, there could potentially be other sources of sudoers. That's the point of nsswitch.conf, it lets you configure where to look for the various databases. I would recommend not making the change to sssd.conf early. For one, it can cause erroneous attempts to access non-existent configurations. For another, with anything security-related, you will want to maintain a minimalist configuration. Only enable what you really need.
    – Kevin Keane
    May 3, 2020 at 6:00
2

This is a symptom that sssd is not reachable.

If you aren't using sssd, the accepted answer is good, and you should follow it and remove sssd from /etc/nsswitch.

But if you are using freeipa, or redhat ipa, or similar, then you need sssd, so don't touch /etc/nsswitch.

Instead, make sure that sssd is running and is happy.

Start with:

systemctl status sssd
systemctl restart sssd

If that doesn't fix it (did for me), then check for clues in /var/log/secure.

Improve this answer
1

In my case, the above described symptom ended as I changed /etc/hosts:

before:

127.0.0.1       localhost

after:

127.0.0.1       foo.example.com foo localhost

There was another symptom: Mails with...

unable to resolve host

Improve this answer
0

These answers are fine, in their way.

However, we're using sssd (via FreeIPA), and need to keep sss in the sudoers line of /etc/nsswitch.conf. This is on Ubuntu 20.04.

Sudo appears to be working perfectly, with the exception of this constant drip-drip-drip of these emails.

Here are two different solutions I've come up with:

  1. Changing the mailto address to an address that is aliased to /dev/null. While the latest versions of sudo allow you to turn it off, that was not the case with version 1.9.7p2 or earlier. Note, this stops all email, which will also prevent legitimate security emails from being sent from sudo:
# grep mailto= /etc/sudoers
Defaults           mailto="[email protected]"

# grep devnull /etc/aliases
devnull: /dev/null
  1. Change the sudoers line in /etc/nsswitch.conf:
sudoers: sss[!success=continue] files
Improve this answer
1
  • Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Feb 6, 2023 at 21:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .