libsss-sudo generated nsswitch.conf leads to error messages upon sudo invocation

Bug #1249777 reported by Oliver Brakmann on 2013-11-10
This bug affects 51 people
Affects Status Importance Assigned to Milestone
sssd (Ubuntu)
sudo (Debian)
sudo (Fedora)
Fix Released

Bug Description


the postinst script for libsss-sudo adds the following line to /etc/nsswitch.conf:

sudoers: files sss

On my LDAP+krb5 setup, this leads to the following error message when either LDAP or local users invoke sudo:

Nov 9 17:34:41 charon sudo: oliver : problem with defaults entries ; TTY=pts/0 ; PWD=/etc ;

The sudo invocation succeeds nonetheless, so this is mainly an annoying cosmetic issue, since a mail is sent to root everytime someone runs sudo.

Running a debug trace on sudo shows the following:

Nov 9 17:34:41 sudo[3297] <- update_defaults @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/defaults.c:528 := true
Nov 9 17:34:41 sudo[3297] <- sudo_file_setdefs @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/parse.c:146 := 0
Nov 9 17:34:41 sudo[3297] -> sudo_sss_open @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/sssd.c:243
Nov 9 17:34:41 sudo[3297] <- sudo_sss_open @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/sssd.c:298 := 0
Nov 9 17:34:41 sudo[3297] -> sudo_sss_parse @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/sssd.c:319
Nov 9 17:34:41 sudo[3297] <- sudo_sss_parse @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/sssd.c:320 := 0
Nov 9 17:34:41 sudo[3297] -> sudo_sss_setdefs @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/sssd.c:331
Nov 9 17:34:41 sudo[3297] Looking for cn=defaults
Nov 9 17:34:41 sudo[3297] handle->fn_send_recv_defaults: != 0, sss_error=32570
Nov 9 17:34:41 sudo[3297] <- sudo_sss_setdefs @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/sssd.c:343 := -1
Nov 9 17:34:41 sudo[3297] -> log_error @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/logging.c:473
Nov 9 17:34:41 sudo[3297] -> vlog_error @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/logging.c:421
Nov 9 17:34:41 sudo[3297] -> set_perms @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/set_perms.c:116
Nov 9 17:34:41 sudo[3297] set_perms: PERM_ROOT: uid: [0, 0, 0] -> [0, 0, 0]
Nov 9 17:34:41 sudo[3297] -> sudo_grlist_addref @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/pwutil.c:770
Nov 9 17:34:41 sudo[3297] <- sudo_grlist_addref @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/pwutil.c:772
Nov 9 17:34:41 sudo[3297] <- set_perms @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/set_perms.c:350 := true
Nov 9 17:34:41 sudo[3297] -> new_logline @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/logging.c:746
Nov 9 17:34:41 sudo[3297] <- new_logline @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/logging.c:867 := problem with defaults entries ; TTY=pts/0 ; PWD=/etc ;
Nov 9 17:34:41 sudo[3297] -> send_mail @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/logging.c:524
Nov 9 17:34:41 sudo[3297] -> do_syslog @ /build/buildd/sudo-1.8.6p3/plugins/sudoers/logging.c:138

I have found a similar report in Redhat's Bugzilla, but I'm not entirely sure if it's the same problem. There are slight differences in the debug trace:

Removing the "sss" statement from the sudoers line in nsswitch.conf works around the problem.

Created attachment 650460
proposed patch

Description of problem:
When sudo is used with sssd and a local user runs sudo, an e-mail is sent to administrator, because sssd does not support sudo rules for local users. It is not an error, only noise.

Version-Release number of selected component (if applicable):

Steps to Reproduce:
1. configure sudo to use sssd as data source ('sudoers: files sss' in /etc/nsswitch.conf
2. run sssd
3. log in as local user
4. run 'sudo -l' as local user

Actual results:
E-mail is sent to administrator:
"problem with defaults entries ; TTY=pts/2 ; PWD=/home/fuero"

Expected results:
No e-mail is sent.

Additional info:
From sudo logs:
Nov 23 15:06:27 sudo[18514] -> sudo_sss_setdefs @ ./sssd.c:331
Nov 23 15:06:27 sudo[18514] Looking for cn=defaults
Nov 23 15:06:27 sudo[18514] The user was not found in SSSD.
Nov 23 15:06:27 sudo[18514] <- sudo_sss_setdefs @ ./sssd.c:348 := -1
Nov 23 15:06:27 sudo[18514] -> log_error @ ./logging.c:473
Nov 23 15:06:27 sudo[18514] -> vlog_error @ ./logging.c:421
Nov 23 15:06:27 sudo[18514] -> set_perms @ ./set_perms.c:116
Nov 23 15:06:27 sudo[18514] set_perms: PERM_ROOT: uid: [0, 0, 0] -> [0, 0, 0]
Nov 23 15:06:27 sudo[18514] -> sudo_grlist_addref @ ./pwutil.c:770
Nov 23 15:06:27 sudo[18514] <- sudo_grlist_addref @ ./pwutil.c:772
Nov 23 15:06:27 sudo[18514] <- set_perms @ ./set_perms.c:350 := true
Nov 23 15:06:27 sudo[18514] -> new_logline @ ./logging.c:746
Nov 23 15:06:27 sudo[18514] <- new_logline @ ./logging.c:867 := problem with defaults entries ; TTY=pts/3 ; PWD=/home/pbrezina ;
Nov 23 15:06:27 sudo[18514] -> send_mail @ ./logging.c:524
Nov 23 15:06:27 sudo[18514] -> do_syslog @ ./logging.c:138

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

Jakub Hrozek (jakub-hrozek) wrote :

The issue filed in RHBZ was affecting local users (as in, present in /etc/passwd) who invoked sudo rules stored in LDAP. Is that your case?

Anyhow, this smells more like a sudo issue rather than sssd.. (I'm not dismissing the problem, just saying..)

Oliver Brakmann (obrakmann) wrote :

I know that the sudo package did not change _at all_ since Raring, where the problem didn't show up. sssd on the other hand changed quite a lot.

It affects both local and LDAP users. I don't have any sudo config in LDAP, which is probably the problem.

What I believe happens is that either or both of sudo and sssd do not correctly cope with the situation of the sudo configuration not being available in the sssd backing store. Sudo asks sssd for the "cn=defaults" entry from LDAP, sssd looks for it, doesn't find anything and returns an error. Sudo sees the error and complains.

I can come up with three possible solutions:

1) patch sudo to not log a message when sssd returns an error.
=> probably not the best solution, since we may miss real errors, too.

2) patch sssd to not return an error when the configuration isn't found.
=> probably slightly better than (1), but we still might miss real errors (I think). BTW, the offending code starts here:

3) patch the sssd package to not alter the nsswitch.conf.
=> this is probably the best solution. I think the people that store the sudo config in LDAP are quite the minority. I also think that those people know that they need to modify their nsswitch.conf for their configuration to work. Goes a bit against the spirit of Ubuntu, though.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in sssd (Ubuntu):
status: New → Confirmed
phre (phre) wrote :

I can confirm this on 14.04 and I also get the message regardless if it's a local or network user who runs sudo.

Timo Aaltonen (tjaalton) wrote :

Sudo in 14.04 is based on 1.8.9p5, which already has that patch from RHBZ..

Timo Aaltonen (tjaalton) wrote :

And what do you mean sudo didn't change since raring? It's true that saucy has same 1.8.6p3 as raring, but 14.04 has a newer version..

Oliver Brakmann (obrakmann) wrote :

Hi Timo,

please notice the timestamp of the comment in which I said that sudo didn't change. I didn't run Trusty back then. It was just to point out that the error did not occur in Raring, but sudo hadn't changed, so it could not have introduced the error.

But I can also confirm that the error still occurs with 14.04:

antares : May 3 13:30:18 : oliver : problem with defaults entries ; TTY=pts/22 ; PWD=/home/oliver ;

$ apt-cache policy sudo
  Installed: 1.8.9p5-1ubuntu1

That version indeed has the fix from RH BZ.

But I've only now seen the patch that was attached to the bug. If you look at my debug trace above, it says that sss_error is 32570 (which probably isn't the error code for ENOENT). Then take a look at the diff from RH BZ again. In the last line, they didn't change the -1 to 0 as they did a few lines above that, so if sss_error is neither ENOENT nor 0, they return -1, which sudo doesn't understand.

Oliver Brakmann (obrakmann) wrote :

nope, spoke to soon. I just tested a build with the second "debug_return_int(-1)" changed to "debug_return_int(0)" and the error still occurs.

No idea then, sorry :/

Timo Aaltonen (tjaalton) wrote :

oh right, this was opened last year..

I have the same problem with trusty 14.04

apt-cache policy sudo
  Installed: 1.8.9p5-1ubuntu1
  Candidate: 1.8.9p5-1ubuntu1
  Version table:
 *** 1.8.9p5-1ubuntu1 0
        500 trusty/main amd64 Packages
        100 /var/lib/dpkg/status

Maxime Besson (mabes) wrote :

As a workaround that doesn't require changing /etc/nsswitch.conf, you can also explicitely disable sudo support for your sssd domain :

services = nss, pam, sudo

sudo_provider = none

Timo Aaltonen (tjaalton) wrote :

lowering importance, you can remove the package if sudo integration isn't used

Changed in sssd (Ubuntu):
importance: Undecided → Low
pdf (pdffs) on 2015-02-24
Changed in sudo (Ubuntu):
status: New → Fix Released
pdf (pdffs) wrote :

Well, darn, I seem to have screwed up the status for the sudo package, and now Launchpad won't let me change it back.

pdf (pdffs) on 2015-02-24
no longer affects: sudo (Ubuntu)
pdf (pdffs) wrote :

Sorry for the noise.

Working through this, it's probably a config issue. On joining a host via freeipa-client-install, nsswitch.conf is updated to add sss to sudoers, however sssd.conf is *not* created with "services = sudo", so every sudo call gets a hard error trying to look up the defaults entry. As soon as sudo is added to the sssd services list, the spurious emails go away, even if there's no cn=defaults in the IPA directory.

Timo Aaltonen (tjaalton) wrote :

you need freeipa-client 4.x for proper sudo integration, vivid has that

pdf (pdffs) wrote :

So, the ipa-client-install script is fixed in 4.x so that it either doesn't add sudoers to nsswitch.conf, or does enable sudo in sssd.conf?

I did indeed have problems finding rules using sssd-1.11.5-1ubuntu3 against FreeIPA server 4.1.2, I'm testing now using your sssd-1.11.7-1~trusty1 packages from ppa:sssd/updates and things seem a lot happier. Is it just a matter of mis-matched LDAP queries that I could track down and override in sssd.conf, or are there more substantial problems your're aware of with the sssd version in Trusty? I'm spinning all this up as a test for a potentially larger migration, and would prefer to stick with LTS packages if possible.

Timo Aaltonen (tjaalton) wrote :

enables sudo in sssd.conf

sssd has MRE, so maybe it's time to push 1.11.7 to -updates..

pdf (pdffs) wrote :

My testing so far hasn't turned up any issues with 1.11.7, I'd be quite pleased to see it land in -updates if you're happy with that.

Alexander Fieroch (fieroch) wrote :

My workaround is to replace
   sudoers: files sss
   sudoers: files
in /etc/nsswitch.conf because I do not use the SSS configuration for sudo, just for AD.

Adam Thompson (athompso) wrote :

Confirming that this problem still affects 16.04 LTS.

pdf (pdffs) wrote :

@athompso, seems to work fine here on 16.04.

ananke (ananke) wrote :

16.04, vanilla install with sssd pointing at LDAP, the issue is still here.

Changed in sudo (Debian):
status: Unknown → New
Tilman Schmidt (tgsbn) wrote :

Worse, even if I remove the `sss` entry on the `sudoers` line as suggested, every update of the `sssd` package adds it back again.

My preferred solution by far is solution 3) from comment #2 on 2013-11-12. At the very least, updating a package should not kill a manual configuration change.

Re comments #14, #15, and #16, this is not a problem of freeipa. It occurs with plain sssd, too.

4tro (finke-lamein) wrote :

Imho, the correct fix here would be to just not fail on not getting sudoers rights from the LDAP. (correctly detecting this specific issue of course)

This leaves sudo through sssd enabled for that "minority" of users (the minority probably being companies)

Also, when enabling it again, people would still be faced with that error until they add rules on LDAP

Tilman Schmidt (tgsbn) wrote :

IMHO we have two separate issues here, both of which need to be addressed:

First, and most important, installing an update for the sssd package MUST NOT revert an intentional local configuration change. If you insist in adding `sss` to the `sudoers` line in nsswitch.conf on initial installation, you'll need to do it in such a way that it *only* happens on initial installation, and not on every update.

Second, sssd should handle that configuration more gracefully, as proposed by 4tro in comment #24.

But the first issue is the much more urgent one. In a company environment you must be able to rely on updates not to destroy your local configuration.

Changed in sudo (Fedora):
importance: Unknown → Undecided
status: Unknown → Fix Released
Murz (murznn) wrote :

Confirm, that solution from #19 works on Ubuntu 16.04 only until next update, after each update I need to change file manually again! Please provide solution for remove this option permanently!

Robie Basak (racb) wrote :

Tilman Schmidt, thank you for identifying the two separate issues. Your assessment seems reasonable.

Let's use this bug to track the original issue.

For the separate matter of local changes to /etc/nsswitch.conf being clobbered on package upgrade, I've filed bug 1781991 and a corresponding bug in Debian. Hopefully as soon as that bug is fixed, the workaround for this bug will continue to work following package upgrades.

Max (maxter) wrote :

i solved following the last answer in this post:

adding ssh and sudo to the services option in the sssd section of sssd.conf worked for me:

### sssd.conf
services = nss, sudo, pam, ssh

i'm not using freeipa so i don't know if the freeipa-clients install problem reported in the cited post still persist.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.