Bug 1159554

Summary: is there no better way to deal with user sudo runtime files?
Product: [Fedora] Fedora Reporter: dac.override
Component: sudoAssignee: Daniel Kopeček <dkopecek>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: dkopecek, kzak, rsroka
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: sudo-1.8.14p1-1.fc22 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-07-30 00:40:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description dac.override 2014-11-01 11:31:21 UTC
Description of problem:

Sudo maintains directories and files in /run (/run/sudo)

These directories (/run/sudo and /run/sudo/ts atleast) get created by sudo the first time sudo is run.

This is a problem in some instances since, sudo is a user application, and it runs with atleast one MAC-security identifier that is associated with the user running sudo, subsequently the /run/sudo and /run/sudo/ts directories are created with that MAC-security identifier associated.

Since /run/sudo is shared between all users, this limits our ability to enforce MAC policy using the aforementioned MAC-security identifier.

For example:user joe is associated with the joe_u MAC-security user identifier, joe runs sudo, and sudo inherits the joe_u identifier, sudo creates /run/sudo for the first time and /run/sudo ends up associated with the joe_u identifier. 

If this identifier is used to enforce MAC-security policy then this could prevent users running sudo with other MAC-security user identifiers access
to /run/sudo, and as a result sudo will fail.

Is it not possible for sudo to maintain these user specific sudo files in /run/user/$UID/sudo instead. These directories are "per user" and so this problem would not exist if this alternative was used instead.

Comment 1 dac.override 2014-11-01 11:40:22 UTC
Another possible alternative would be t use systemd-tmpfiles to create /run/sudo and /run/sudo/ts directories instead

Comment 2 Jaroslav Reznik 2015-03-03 16:27:42 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 3 Radovan Sroka 2015-07-13 10:53:45 UTC
This bug will be fixed in Fedora 22 as a rebase sudo to 1.8.14 when upstream release this version.

http://www.sudo.ws/repos/sudo/file/c0fd3b0fb9c3/init.d/sudo.conf.in

Comment 4 Fedora Update System 2015-07-21 11:37:28 UTC
sudo-1.8.14p1-1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/sudo-1.8.14p1-1.fc22

Comment 5 Fedora Update System 2015-07-23 08:54:10 UTC
Package sudo-1.8.14p1-1.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sudo-1.8.14p1-1.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-11942/sudo-1.8.14p1-1.fc22
then log in and leave karma (feedback).

Comment 6 Fedora Update System 2015-07-30 00:40:51 UTC
sudo-1.8.14p1-1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.