Description of problem: SELinux is preventing nm-system-setti (NetworkManager_t) "read" to /etc/dbus-1/system.d (dbusd_etc_t). Version-Release number of selected component (if applicable): selinux-policy-2.4.6-162.el5 NetworkManager-0.7.0-0.11.svn4133.el5 How reproducible: Not really clear; there was both wireless and wired network use... Steps to Reproduce: 1. Not sure what I did to cause this, sorry --- I believe selinux messages are always blockers, thus blocker flag.
I see this on i386 and x86_64 arches of the 20081006.0 build of RHEL5.2 on multiple machines. The error appears after login and nothing needs to be done to cause it (simply install the OS and it will appear).
Dan: TBH I have no idea why nm-system-settings would need to read this directory since dbus itself is the process that reads files out of that directory. Is there a good way to get a stacktrace from the process when an SELinux error is triggered? I'm really curious to figure out what is trying to do this operation.
I get the same avc denial but on wpa_supplicant. It's easy to reproduce: stop NM, restart dbus, start NM. type=AVC msg=audit(1223993506.115:6438): avc: denied { read } for pid=6926 comm="wpa_supplicant" path="/etc/dbus-1/system.d" dev=dm-0 ino=65939 scontext=root:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:dbusd_etc_t:s0 tclass=dir type=AVC msg=audit(1223993506.115:6438): avc: denied { read write } for pid=6926 comm="wpa_supplicant" path="socket:[37853]" dev=sockfs ino=37853 scontext=root:system_r:NetworkManager_t:s0 tcontext=root:system_r:system_dbusd_t:s0 tclass=netlink_selinux_socket
These are leaked file descriptors from dbus. DBUS should close these file descriptors on exec. fcntl(fd, F_SETFD, FD_CLOEXEC)
Moving to 5.4 per comment #8.
Just pops up out of the blue. Tired correcting with the suggested restorecon -v '/var/log/gdm/:0-greeter.log' seems to not come up again, until my next session. I do not leave my computer running all the time, so when I boot to use, it pops up after the computer has been running roughly 6 to 8 hours. I don't know if this helps you out.
Just pops up out of the blue. Tired correcting with the suggested restorecon -v '/var/log/gdm/:0-greeter.log' seems to not come up again, until my next session. I do not leave my computer running all the time, so when I boot to use, it pops up after roughly 4 to 8 hours the computer has been running. I don't know if this helps you out... Source Context: system_u:system_r:polkit_auth_t:s0-s0:c0.c1023 Target Context: system_u:object_r:xserver_log_t:s0 Target Objects: /var/log/gdm/:0-greeter.log [ file ] Source: polkit-read-aut Source Path: /usr/libexec/polkit-read-auth-helper Port: <Unknown> Host: scoobshost.scoobsdomain Source RPM Packages: PolicyKit-0.9-4.fc10 Target RPM Packages: Policy RPM: selinux-policy-3.5.13-41.fc10 Selinux Enabled:True Policy Type: targeted MLS Enabled: True Enforcing Mode: Enforcing Plugin Name: catchall_file Host Name: scoobshost.scoobsdomain Platform: Linux scoobshost.scoobsdomain 2.6.27.12-170.2.5.fc10.x86_64 #1 SMP Wed Jan 21 01:33:24 EST 2009 x86_64 x86_64 Alert Count: 178 First Seen: Sat 31 Jan 2009 12:43:40 PM EST Last Seen: Mon 09 Feb 2009 05:45:55 PM EST Local ID: 063f32aa-5f76-40d6-9dee-8f82fdda12bc Line Numbers: Raw Audit Messages : node=scoobshost.scoobsdomain type=AVC msg=audit(1234219555.327:11): avc: denied { write } for pid=2678 comm="polkit-read-aut" path="/var/log/gdm/:0-greeter.log" dev=dm-0 ino=4210804 scontext=system_u:system_r:polkit_auth_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xserver_log_t:s0 tclass=file node=scoobshost.scoobsdomain type=SYSCALL msg=audit(1234219555.327:11): arch=c000003e syscall=59 success=yes exit=0 a0=3b06814c08 a1=7fff5a5bc380 a2=7fff5a5bd218 a3=8 items=0 ppid=2658 pid=2678 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=87 sgid=87 fsgid=87 tty=(none) ses=4294967295 comm="polkit-read-aut" exe="/usr/libexec/polkit-read-auth helper"subj=system_u:system_r:polkit_auth_t:s0-s0:c0.c1023 key=(null)
This is an F10 bug you are adding to a RHEL5 bugzilla. The gdm problem is fixed in the policy in fedora-testing.
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".