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

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..)

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: https://git.fedorahosted.org/cgit/sssd.git/tree/src/sss_client/sudo/sss_sudo.c#n109

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.

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

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.

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

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..

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
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.

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 :/

oh right, this was opened last year..

I have the same problem with trusty 14.04

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

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

[sssd]
services = nss, pam, sudo

[mydomain/LDAP]
sudo_provider = none

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

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

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.

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

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.

enables sudo in sssd.conf

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

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.

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

Confirming that this problem still affects 16.04 LTS.

@athompso, seems to work fine here on 16.04.

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

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.

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

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.

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!

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.

i solved following the last answer in this post:
https://superuser.com/questions/1086152/sudo-sending-annoying-alerts-issue-with-defaults-entries

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

### sssd.conf
[sssd]
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.

This bug was fixed in the package sssd - 2.3.1-3

---------------
sssd (2.3.1-3) unstable; urgency=medium

  * control: Move libsss-sudo to sssd-common Suggests. (LP: #1249777)

 -- Timo Aaltonen <email address hidden> Tue, 06 Oct 2020 15:56:19 +0300