Description of problem: type=1400 audit(1225324588.070:4): avc: denied { write } for pid=1990 comm="gdm-binary" name="gdm" dev=dm-0 ino=69980 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_spool_t:s0 tclass=dir Version-Release number of selected component (if applicable): selinux-policy-targeted-3.5.13-8.fc10.noarch selinux-policy-3.5.13-8.fc10.noarch gdm-2.24.0-11.fc10.i386 How reproducible: Always Steps to Reproduce: 1. Spin a fresh rawhide livecd. boot.
I'm assuming that this occurred when gdm tried to write /var/spool/gdm/force-display-on-active-vt
does restorecon on /var/spool/gdm fix it?
Yes, running restorecon changes the context from var_spool_t to xdm_spool_t and seems to resolve the issue.
I just noticed this message when running the livecd-creator... /sbin/restorecon reset /var/spool/gdm context system_u:object_r:var_spool_t:s0->system_u:object_r:xdm_spool_t:s0 /sbin/restorecon set context /var/spool/gdm->system_u:object_r:xdm_spool_t:s0 failed:'Invalid argument' Read error on pipe.
There was already about this that got closed, but let's just use this one rather than reopening that one. what system did you run livecd-creator on?
I ran the livecd-creator on a F9 machine with livecd-tools-019-1.fc9.x86_64 (with SELinux in permissive mode, fwiw)
Some how this directory is getting destroyed and recreated with the wrong context. selinux-policy-3.5.13-11.fc10.noarch has the correct code, so that if gdm tries to create /var/spool/gdm it will create it with the right context. But I do not know how or why this is being created with the wrong context. Suspicion would be rpm post install script or init script.
is that the type of thing that might get logged by auditd?
Not likely.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping