libreport version: 2.0.8 executable: /usr/bin/python hashmarkername: setroubleshoot kernel: 3.3.0-0.rc3.git6.2.fc17.i686 reason: SELinux is preventing systemctl from 'read' accesses on the directory journal. time: Fri 17 Feb 2012 15:20:42 GMT description: :SELinux is preventing systemctl from 'read' accesses on the directory journal. : :***** Plugin catchall (100. confidence) suggests *************************** : :If you believe that systemctl should be allowed read access on the journal 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: :# grep systemctl /var/log/audit/audit.log | audit2allow -M mypol :# semodule -i mypol.pp : :Additional Information: :Source Context system_u:system_r:dhcpc_t:s0 :Target Context system_u:object_r:syslogd_var_run_t:s0 :Target Objects journal [ dir ] :Source systemctl :Source Path systemctl :Port <Unknown> :Host (removed) :Source RPM Packages :Target RPM Packages :Policy RPM selinux-policy-3.10.0-88.fc17.noarch :Selinux Enabled True :Policy Type targeted :Enforcing Mode Permissive :Host Name (removed) :Platform Linux (removed) : 3.3.0-0.rc3.git6.2.fc17.i686 #1 SMP Thu Feb 16 : 00:40:03 UTC 2012 i686 i686 :Alert Count 1 :First Seen Fri 17 Feb 2012 14:51:07 GMT :Last Seen Fri 17 Feb 2012 14:51:07 GMT :Local ID 62fa524e-b252-4822-b4f1-947a004c72d2 : :Raw Audit Messages :type=AVC msg=audit(1329490267.44:19): avc: denied { read } for pid=591 comm="systemctl" name="journal" dev="tmpfs" ino=6736 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:syslogd_var_run_t:s0 tclass=dir : : :Hash: systemctl,dhcpc_t,syslogd_var_run_t,dir,read : :audit2allow : :#============= dhcpc_t ============== :allow dhcpc_t syslogd_var_run_t:dir read; : :audit2allow -R : :#============= dhcpc_t ============== :allow dhcpc_t syslogd_var_run_t:dir read; :
Why does executing systemctl list this contents of the journal directory?
(In reply to comment #1) > Why does executing systemctl list this contents of the journal directory? because it displays the last messages of the service # systemctl status dbus.service dbus.service - D-Bus System Message Bus Loaded: loaded (/usr/lib/systemd/system/dbus.service; static) Active: active (running) since Tue, 21 Feb 2012 08:31:15 +0100; 3h 2min ago Main PID: 682 (dbus-daemon) CGroup: name=systemd:/system/dbus.service ├ 682 /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation... ├ 789 /usr/libexec/polkit-1/polkitd --no-debug ├ 991 /usr/libexec/upowerd └ 1328 /usr/sbin/modem-manager Feb 21 10:19:58 lenovo dbus-daemon[682]: modem-manager[1328]: <info> (tty/ttyACM3): released by modem /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.6/1-1.5.6.1/1-1.5.6.1.4 Feb 21 10:19:58 lenovo modem-manager[1328]: <info> (tty/ttyACM3): released by modem /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.6/1-1.5.6.1/1-1.5.6.1.4 Feb 21 10:36:21 lenovo dbus-daemon[682]: dbus[682]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) Feb 21 10:36:21 lenovo dbus[682]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) Feb 21 10:36:21 lenovo dbus-daemon[682]: dbus[682]: [system] Successfully activated service 'org.freedesktop.PackageKit' Feb 21 10:36:21 lenovo dbus[682]: [system] Successfully activated service 'org.freedesktop.PackageKit' Feb 21 11:06:17 lenovo dbus[682]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper) Feb 21 11:06:17 lenovo dbus-daemon[682]: dbus[682]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper) Feb 21 11:06:17 lenovo dbus-daemon[682]: dbus[682]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Feb 21 11:06:17 lenovo dbus[682]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
(In reply to comment #2) > (In reply to comment #1) > > Why does executing systemctl list this contents of the journal directory? > > because it displays the last messages of the service True, but I don't think dhcpc_t cares about the messages. Anyone know what exact command line dhcpc_t uses when it calls systemctl and why? Where does the call come from? Is it something called from /etc/dhcp/dhclient.d? Frank, what files do you have in that directory?
Is it something called from /etc/dhcp/dhclient.d? > Frank, what files do you have in that directory? # echo /etc/dhcp/dhclient.d/* /etc/dhcp/dhclient.d/chrony.sh /etc/dhcp/dhclient.d/nis.sh
Yes we are currently allow dhclient to interact with the following sh-4.2# sesearch -A -s dhcpc_t -c service Found 4 semantic av rules: allow dhcpc_t ypbind_unit_file_t : service { start stop status reload kill } ; allow dhcpc_t chronyd_unit_file_t : service { start stop status reload kill } ; allow dhcpc_t nscd_unit_file_t : service { start stop status reload kill } ; allow dhcpc_t ntpd_unit_file_t : service { start stop status reload kill } ;
FYI, due to this, network failed to come up on my just-installed F17-beta desktop (from live-CD). I worked around it by manually running this: setenforce 0; dhclient em1
(In reply to comment #6) > FYI, due to this, network failed to come up on my just-installed F17-beta > desktop (from live-CD). That's odd. The failure to read the journal in "systemctl status ..." is not considered an error. The command should still give the right results. I don't see how it can break anything. Did you get any other AVC denials?
This is from /usr/libexec/chrony-helper: is_running() { systemctl status $service_name &> /dev/null } It could use this instead: is_running() { systemctl is-active -q $service_name } "is-active" is a cheaper operation than "status" and will not attempt to read the journal needlessly.
(In reply to comment #7) > (In reply to comment #6) > > FYI, due to this, network failed to come up on my just-installed F17-beta > > desktop (from live-CD). > > That's odd. The failure to read the journal in "systemctl status ..." is not > considered an error. The command should still give the right results. I don't > see how it can break anything. > Did you get any other AVC denials? I went back to the list and see that there was another: (nmcli needing setsched access to dhcpc_t processes) https://bugzilla.redhat.com/show_bug.cgi?id=806195
*** Bug 806954 has been marked as a duplicate of this bug. ***
comment #8 fixes the problem for me.
chrony-1.27-0.2.pre1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/chrony-1.27-0.2.pre1.fc17
Package chrony-1.27-0.2.pre1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing chrony-1.27-0.2.pre1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-5481/chrony-1.27-0.2.pre1.fc17 then log in and leave karma (feedback).
chrony-1.27-0.2.pre1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.