Hide Forgot
libreport version: 2.0.8 executable: /usr/bin/python hashmarkername: setroubleshoot kernel: 3.3.0-1.fc17.x86_64 reason: SELinux is preventing /usr/sbin/lxdm-binary from 'unlink' accesses on the file /var/log/lxdm.log.old. time: Wed 21 Mar 2012 03:47:54 PM CET description: :SELinux is preventing /usr/sbin/lxdm-binary from 'unlink' accesses on the file /var/log/lxdm.log.old. : :***** Plugin catchall (100. confidence) suggests *************************** : :If you believe that lxdm-binary should be allowed unlink access on the lxdm.log.old file 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 lxdm-binary /var/log/audit/audit.log | audit2allow -M mypol :# semodule -i mypol.pp : :Additional Information: :Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023 :Target Context unconfined_u:object_r:var_log_t:s0 :Target Objects /var/log/lxdm.log.old [ file ] :Source lxdm-binary :Source Path /usr/sbin/lxdm-binary :Port <Unknown> :Host (removed) :Source RPM Packages lxdm-0.4.1-1.fc17.x86_64 :Target RPM Packages :Policy RPM selinux-policy-3.10.0-104.fc17.noarch :Selinux Enabled True :Policy Type targeted :Enforcing Mode Enforcing :Host Name (removed) :Platform Linux (removed) 3.3.0-1.fc17.x86_64 #1 SMP : Mon Mar 19 03:03:39 UTC 2012 x86_64 x86_64 :Alert Count 2 :First Seen Wed 21 Mar 2012 10:06:09 AM CET :Last Seen Wed 21 Mar 2012 03:16:31 PM CET :Local ID b03e56eb-1ba9-46e7-8be9-ded6f08f80c1 : :Raw Audit Messages :type=AVC msg=audit(1332339391.457:231): avc: denied { unlink } for pid=3285 comm="lxdm-binary" name="lxdm.log.old" dev="sda2" ino=397302 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file : : :type=SYSCALL msg=audit(1332339391.457:231): arch=x86_64 syscall=unlink success=no exit=EACCES a0=409666 a1=7fffe6d857f8 a2=3 a3=7fffe6d853b0 items=0 ppid=1 pid=3285 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=lxdm-binary exe=/usr/sbin/lxdm-binary subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) : :Hash: lxdm-binary,xdm_t,var_log_t,file,unlink : :audit2allowunable to open /sys/fs/selinux/policy: Permission denied : : :audit2allow -Runable to open /sys/fs/selinux/policy: Permission denied : :
restorecon -R -v /var/log/lxdm.log* Not sure how this got mislabled.
I got this selinux warning as well. Running restorecon -R -v /var/log/lxdm.log* exits without any changes. # ls -Z /var/log/lxdm.log* -rw-r-----. root root system_u:object_r:xserver_log_t:s0 /var/log/lxdm.log -rw-r-----. root root system_u:object_r:var_log_t:s0 /var/log/lxdm.log.old I removed lxdm.log.old manually, and will check what happens next.
Fixed in selinux-policy-3.10.0-133.fc17 .old is mislabeled in policy.
selinux-policy-3.10.0-134.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-134.fc17
Package selinux-policy-3.10.0-134.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 selinux-policy-3.10.0-134.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-10008/selinux-policy-3.10.0-134.fc17 then log in and leave karma (feedback).
Thanks. The policy now has them both as system_u:object_r:xserver_log_t:s0, which works. I'd like to note though that lxdm.log context is originally system_u:object_r:xdm_log_t:s0 when created. So that's what they'll both be a couple of boots after the policy update.
selinux-policy-3.10.0-134.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
So are you saying you see lxdm.log labeled as xdm_log_t?
Yes, I'm sorry if that was unclear. Apparently xdm_t can remove xserver_log_t, so without restorecon running the context reverts to xdm_log_t. This bug only appeared after file context was changed (by restorecon) from xdm_log_t to xserver_log_t and var_log_t respectively. I guess that happened after a policy update.
You should not see var_log_t anymore.
That's right, I don't. I was referring to the original bug. It was technically fixed, but wouldn't it be best if the policy reflected reality? That would mean updating policy for /var/log/lxdm.log and /var/log/lxdm.log.old from xserver_log_t to xdm_log_t. Current situation: $ ls -Z /var/log/lxdm* -rw-r-----. root root system_u:object_r:xdm_log_t:s0 /var/log/lxdm.log -rw-r-----. root root system_u:object_r:xdm_log_t:s0 /var/log/lxdm.log.old $ restorecon -nv /var/log/lxdm* restorecon reset /var/log/lxdm.log context system_u:object_r:xdm_log_t:s0->system_u:object_r:xserver_log_t:s0 restorecon reset /var/log/lxdm.log.old context system_u:object_r:xdm_log_t:s0->system_u:object_r:xserver_log_t:s0
Yes, this is a bug. We allow xdm_t to manage both types so it will work.