Bug 1573403 - authselect sudoers problem suspected
Summary: authselect sudoers problem suspected
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: authselect
Version: 28
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Pavel Březina
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-01 05:24 UTC by Peter Gückel
Modified: 2018-05-11 21:14 UTC (History)
3 users (show)

Fixed In Version: authselect-0.4-3.fc28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-11 21:14:20 UTC
Type: Bug


Attachments (Terms of Use)
sudo debug (2.33 MB, text/plain)
2018-05-04 14:59 UTC, Peter Gückel
no flags Details

Description Peter Gückel 2018-05-01 05:24:53 UTC
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:

Comment 1 Pavel Březina 2018-05-03 08:46:31 UTC
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.

Comment 2 Peter Gückel 2018-05-03 16:17:38 UTC
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.

Comment 3 Pavel Březina 2018-05-04 08:03:54 UTC
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

Comment 4 Peter Gückel 2018-05-04 14:35:14 UTC
(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.

Comment 5 Peter Gückel 2018-05-04 14:44:02 UTC
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.

Comment 6 Peter Gückel 2018-05-04 14:49:11 UTC
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.

Comment 7 Peter Gückel 2018-05-04 14:52:23 UTC
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.

Comment 8 Peter Gückel 2018-05-04 14:59:41 UTC
Created attachment 1431439 [details]
sudo debug

var/log/sudo_debug

Comment 9 Peter Gückel 2018-05-05 04:41:31 UTC
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.

Comment 10 Pavel Březina 2018-05-05 17:18:42 UTC
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

Comment 11 Peter Gückel 2018-05-05 18:28:32 UTC
(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.

Comment 12 Peter Gückel 2018-05-05 18:32:19 UTC
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?

Comment 13 Fedora Update System 2018-05-09 13:14:29 UTC
authselect-0.4-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-55452b8373

Comment 14 Pavel Březina 2018-05-09 13:16:20 UTC
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".

Comment 15 Peter Gückel 2018-05-09 17:34:41 UTC
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!

Comment 16 Fedora Update System 2018-05-10 01:31:25 UTC
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

Comment 17 Fedora Update System 2018-05-11 21:14:20 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.