Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1159554 - is there no better way to deal with user sudo runtime files?
Summary: is there no better way to deal with user sudo runtime files?
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sudo
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Daniel Kopeček
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-11-01 11:31 UTC by dac.override
Modified: 2015-07-30 00:40 UTC (History)
3 users (show)

Fixed In Version: sudo-1.8.14p1-1.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-30 00:40:51 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


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