Bug 1573403

I suppose this is because you do not have installed libsss_sudo, is that correct? Also can I see yours /etc/sudo.conf and /etc/sudoers? Thank you.

Yes, I have libsss_sudo installed. It got installed by default, luckily, since I had never heard of it.

libsss_sudo-1.16.1-3.fc28.x86_64

/etc/sudo.conf is non-existent. If you mean /etc/sudoers, it is stock, unchanged. I created a file in /etc/sudoers.d called 10-peter. Its contents are:

peter ALL=(ALL) NOPASSWD:ALL

I have been using this file without issue for years. I am the only user on this computer, that is my laptop.

Strange. Line "sudoers: files sss" in /etc/nsswitch.conf means, first lookup rules in /etc/sudoers then use sssd to lookup sudo rules. This is perfectly fine and since there is even libsss_sudo installed there should be no problem (there should be no problem even if it is not). (Note: it is not standard nsswitch interface, but sudo use this file and parse it itself for the same purpose as other maps.)

Please, enable debugging [1] in sudo and attach sudo log.

> There is considerable discussion in cyberspace about this and it is considered to be the problem.

Can you point me to the discussion?

[1] https://pagure.io/SSSD/docs/blob/master/f/users/sudo_troubleshooting.rst

(In reply to Pavel Březina from comment #3)
> Can you point me to the discussion?

Here's just one among many (all you need to is a search on sss and nsswitch.conf and receiving lots of emails in esmtp.

I am just perusing the article you linked to about setting debugging.

There was no file /etc/sudo.conf, so I created one with the contents as described in the article you linked to. I will sudo a few times and then submit the log. I just verified that my .esmtp_queue directory now contains nearly 100 entries, even though cron only runs once a day and that is normally the only time I ever receive system mail. These mails occur, as I initially stated, every time I run sudo, which is an indication that something is not working correctly.

Let us hope we find it quickly.

Yup, I ran sudo twice and, after deleting everything in esmtp_queue, there are now 2 folders with 2 files each. The first file, called cmd, always contains only -t ; the second file has some output (unfortunately, the plasma clipboard does not work under wayland, but I will try):

To: root
From: peter
Auto-Submitted: auto-generated
Subject: *** SECURITY information for localhost.localdomain ***

localhost.localdomain : May  4 08:45:13 : peter : problem with defaults entries ; TTY=pts/2 ; PWD=/home/peter ; USER=root ;

At least copy/paste still work.

OK. I am going to have a look in /var. Back in a second.

By the way, note that these mails are sent to root from me, peter, but they appear in my (peter) .esmtp_queue. If they were security alerts, should they not be sent to root? This is very odd, but I am the system administrator, so perhaps...?

But, still, it is incorrect that sudo is generating all of these mails, since there is nothting wrong with user peter running sudo, since I am administrator and am correctly configured to run sudo.

Created attachment 1431439 [details]
sudo debug

var/log/sudo_debug

You wanted me to point you to the online discussion regarding (variants of?) this problem. Here's one:

https://superuser.com/questions/1086152/sudo-sending-annoying-alerts-issue-with-defaults-entries

Hope this helps.

I see, thank you.

Log says:
May  4 08:44:33 sudo[9450] handle->fn_send_recv_defaults: != 0, sss_error=0

I believe I can reproduce it. Just to check: I suppose sssd and/or sssd-sudo process in not running and its systemd socket is disabled?

$ ps aux | grep sssd
$ ps aux | grep sssd-sudo
$ systemctl status sssd-sudo.socket

(In reply to Pavel Březina from comment #10)
> $ ps aux | grep sssd
peter     7158  0.0  0.0 213792  1016 pts/2    S+   12:20   0:00 grep --color=auto sssd

> $ ps aux | grep sssd-sudo
peter     7166  0.0  0.0 213792  1012 pts/2    S+   12:21   0:00 grep --color=auto sssd-sudo

> $ systemctl status sssd-sudo.socket
● sssd-sudo.socket - SSSD Sudo Service responder socket
   Loaded: loaded (/usr/lib/systemd/system/sssd-sudo.socket; disabled; vendor preset: >
   Active: inactive (dead)
     Docs: man:sssd.conf(5)
   Listen: /var/lib/sss/pipes/sudo (Stream)

Nothing happened and the program hung, displaying something about page 5 of 5, so I typed return and then this appeared:

...skipping...
● sssd-sudo.socket - SSSD Sudo Service responder socket
   Loaded: loaded (/usr/lib/systemd/system/sssd-sudo.socket; disabled; vendor preset: >
   Active: inactive (dead)
     Docs: man:sssd.conf(5)
   Listen: /var/lib/sss/pipes/sudo (Stream)

I was forced to break it off with ctrl-c.

From this I conclude that you are correct: neither sssd and/or sssd-sudo are running nor is the latter's systemd socket enabled.

Or, now that I think about the results of the above, doesn't it mean that both sssd and sssd-auto ARE running, BUT the sssd-sudo socket is disabled?

authselect-0.4-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-55452b8373

I pushed update to F28, please test it.

It will automatically override existing configuration (disabling sss in sudoers in nsswitch.conf). I believe this change is ok, since not many users use sudo with sssd on Fedora. It can be reenabled by running "authselect select sssd with-sudo".

I could not get it with dnf, even after numerous tries, so I pulled it off koji.

It solved the problem here: no more messages in esmtp_queue. I don't even know what sssd is and I have been on Fedora since it was called RedHat 5.0, back in about 1998-9. I have never used sssd knowingly

Thanks for solving this!

authselect-0.4-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-55452b8373

authselect-0.4-3.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.