Bug 2359546 - SELinux is preventing /usr/lib/systemd/systemd-user-runtime-dir from 'write' accesses on the directory /user.
Summary: SELinux is preventing /usr/lib/systemd/systemd-user-runtime-dir from 'write' ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: rawhide
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:586d3b46355baf9a564c26077d3...
: 2359547 2359548 2360323 2360325 2360517 2360910 2360953 2360954 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-04-14 16:39 UTC by Mikhail
Modified: 2025-04-23 01:48 UTC (History)
12 users (show)

Fixed In Version: selinux-policy-41.38-1.fc42
Clone Of:
Environment:
Last Closed: 2025-04-23 01:48:21 UTC
Type: ---
Embargoed:
zpytela: mirror+


Attachments (Terms of Use)
File: description (3.59 KB, text/plain)
2025-04-14 16:39 UTC, Mikhail
no flags Details
File: os_info (795 bytes, text/plain)
2025-04-14 16:39 UTC, Mikhail
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github fedora-selinux selinux-policy pull 2641 0 None open Allow systemd-user-runtime-dir delete gnome homedir content 2025-04-14 20:59:00 UTC
Red Hat Issue Tracker FC-1597 0 None None None 2025-04-16 17:05:25 UTC

Description Mikhail 2025-04-14 16:39:01 UTC
Description of problem:
SELinux is preventing /usr/lib/systemd/systemd-user-runtime-dir from 'write' accesses on the directory /user.

*****  Plugin restorecon (99.5 confidence) suggests   ************************

If you want to fix the label. 
/user default label should be default_t.
Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly.
Do
# /sbin/restorecon -v /user

*****  Plugin catchall (1.49 confidence) suggests   **************************

If you believe that systemd-user-runtime-dir should be allowed write access on the user directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'systemd-user-ru' --raw | audit2allow -M my-systemduserru
# semodule -X 300 -i my-systemduserru.pp

Additional Information:
Source Context                system_u:system_r:systemd_user_runtimedir_t:s0
Target Context                system_u:object_r:config_home_t:s0
Target Objects                /user [ dir ]
Source                        systemd-user-ru
Source Path                   /usr/lib/systemd/systemd-user-runtime-dir
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           systemd-257.5-2.fc43.x86_64
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-41.37-1.fc43.noarch
Local Policy RPM              selinux-policy-targeted-41.37-1.fc43.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 6.14.0-01-
                              1e26c5e28ca5821a824e90dd359556f5e9e7b89f+ #6 SMP
                              PREEMPT_DYNAMIC Sat Apr 12 02:36:28 +05 2025
                              x86_64
Alert Count                   1
First Seen                    2025-04-14 19:01:51 +05
Last Seen                     2025-04-14 19:01:51 +05
Local ID                      0ee3858e-936e-4159-ad58-947e7eecefa5

Raw Audit Messages
type=AVC msg=audit(1744639311.767:222): avc:  denied  { write } for  pid=3984 comm="systemd-user-ru" name="dconf" dev="tmpfs" ino=65 scontext=system_u:system_r:systemd_user_runtimedir_t:s0 tcontext=system_u:object_r:config_home_t:s0 tclass=dir permissive=1


type=AVC msg=audit(1744639311.767:222): avc:  denied  { remove_name } for  pid=3984 comm="systemd-user-ru" name="user" dev="tmpfs" ino=66 scontext=system_u:system_r:systemd_user_runtimedir_t:s0 tcontext=system_u:object_r:config_home_t:s0 tclass=dir permissive=1


type=SYSCALL msg=audit(1744639311.767:222): arch=x86_64 syscall=unlinkat success=yes exit=0 a0=5 a1=5599d77f6543 a2=0 a3=4 items=2 ppid=1 pid=3984 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=systemd-user-ru exe=/usr/lib/systemd/systemd-user-runtime-dir subj=system_u:system_r:systemd_user_runtimedir_t:s0 key=(null)

type=CWD msg=audit(1744639311.767:222): cwd=/

type=PATH msg=audit(1744639311.767:222): item=0 name=/ inode=65 dev=00:4f mode=040700 ouid=42 ogid=42 rdev=00:00 obj=system_u:object_r:config_home_t:s0 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0

type=PATH msg=audit(1744639311.767:222): item=1 name=user inode=66 dev=00:4f mode=0100600 ouid=42 ogid=42 rdev=00:00 obj=system_u:object_r:config_home_t:s0 nametype=DELETE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0

Hash: systemd-user-ru,systemd_user_runtimedir_t,config_home_t,dir,write

Version-Release number of selected component:
selinux-policy-targeted-41.37-1.fc43.noarch

Additional info:
reporter:       libreport-2.17.15
reason:         SELinux is preventing /usr/lib/systemd/systemd-user-runtime-dir from 'write' accesses on the directory /user.
package:        selinux-policy-targeted-41.37-1.fc43.noarch
component:      selinux-policy
hashmarkername: setroubleshoot
type:           libreport
kernel:         6.14.0-01-1e26c5e28ca5821a824e90dd359556f5e9e7b89f+
component:      selinux-policy

Comment 1 Mikhail 2025-04-14 16:39:03 UTC
Created attachment 2084953 [details]
File: description

Comment 2 Mikhail 2025-04-14 16:39:05 UTC
Created attachment 2084954 [details]
File: os_info

Comment 3 Zdenek Pytela 2025-04-14 20:59:10 UTC
*** Bug 2359548 has been marked as a duplicate of this bug. ***

Comment 4 Zdenek Pytela 2025-04-14 20:59:23 UTC
*** Bug 2359547 has been marked as a duplicate of this bug. ***

Comment 5 Zdenek Pytela 2025-04-16 16:58:53 UTC
*** Bug 2360323 has been marked as a duplicate of this bug. ***

Comment 6 Zdenek Pytela 2025-04-16 17:05:14 UTC
*** Bug 2360325 has been marked as a duplicate of this bug. ***

Comment 7 Zdenek Pytela 2025-04-17 07:42:51 UTC
*** Bug 2360517 has been marked as a duplicate of this bug. ***

Comment 8 Fedora Update System 2025-04-21 08:44:13 UTC
FEDORA-2025-c6621cb65e (selinux-policy-41.38-1.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-c6621cb65e

Comment 9 Fedora Update System 2025-04-22 01:45:27 UTC
FEDORA-2025-c6621cb65e has been pushed to the Fedora 42 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-c6621cb65e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-c6621cb65e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 10 Zdenek Pytela 2025-04-22 06:12:56 UTC
*** Bug 2360953 has been marked as a duplicate of this bug. ***

Comment 11 Zdenek Pytela 2025-04-22 06:13:03 UTC
*** Bug 2360954 has been marked as a duplicate of this bug. ***

Comment 12 Zdenek Pytela 2025-04-22 06:13:21 UTC
*** Bug 2360910 has been marked as a duplicate of this bug. ***

Comment 13 Andrew Kreimer 2025-04-22 07:39:50 UTC
Thanks, there are no errors/notifications since the update.

Comment 14 Fedora Update System 2025-04-23 01:48:21 UTC
FEDORA-2025-c6621cb65e (selinux-policy-41.38-1.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, 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.