Description of problem: Whenever I use sudo, I get a mail in esmtp_queue. I checked nsswitch.conf and there is a line about sudoers with the parameters files sss. There is considerable discussion in cyberspace about this and it is considered to be the problem. Apparently, the line should read files, but without sss. Apparently, this is the cause of the persistent warning emails. Version-Release number of selected component (if applicable): authselect-0.4-2.fc28.x86_64 How reproducible: su or sudo anything and a warning email will appear. The cmd file just says -t and the mail file says: Subject: security information for localhost.localdomain and the body has: problem with defaults entries ; TTY=pts/1 ; PWD = /home/peter [my home dir] ; USER = root Steps to Reproduce: 1. 2. 3. Actual results: Expected results: none of these persistent emails. Additional info:
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.