Bug 504266

Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

1) Could we get also /var/log/audit/audit.log attached to this issue (please, check "Private attachment" when attaching it)?
2) what is the security context of /dev/mem on your computer? I.e., could we get output of command

ls -lZ /dev/mem
3) /var/log/messages and /var/log/dmesg could be also relevant. Please attach them as well.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Created attachment 346688 [details]
dmesg

Created attachment 346689 [details]
messages

$ ls -lZ /dev/mem
crw-r-----. root kmem system_u:object_r:memory_device_t:s0 /dev/mem

I haven't attached the audit log, because I can't find any private attachment option when adding an attachment.

(In reply to comment #4)
> $ ls -lZ /dev/mem
> crw-r-----. root kmem system_u:object_r:memory_device_t:s0 /dev/mem

This is correct.

> I haven't attached the audit log, because I can't find any private attachment
> option when adding an attachment.  

In the page where you add attachment is (below the comment box) checkbox "Private".

Created attachment 346710 [details]
Screenshot of adding an attachment

There's no private option here.

(In reply to comment #6)
> Created an attachment (id=346710) [details]
> Screenshot of adding an attachment
> 
> There's no private option here.  

Sorry, then send it to me (my email is mcepl at redhat domain). Thanks.

(once more, just that you can read it)

Actually this doesn't look like a SELinux problem:

bradford:~$ grep denied audit.log 
type=AVC msg=audit(1244157410.916:33926): avc:  denied  { write } for  pid=5709
comm="crontab" path="/root/crontab.save" dev=dm-0 ino=275402
scontext=unconfined_u:unconfined_r:admin_crontab_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
type=AVC msg=audit(1244157477.249:33930): avc:  denied  { write } for  pid=8350
comm="crontab" path="/root/crontab.save" dev=dm-0 ino=275402
scontext=unconfined_u:unconfined_r:admin_crontab_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
bradford:~$ 

And I don't think cron has anything to do with starting Xorg.

Dan, what do you think?

Those denied messages are from trying to issue:

crontab -l > crontab.save

not from starting X.  I resolved that particular issue by doing: 

crontab -l | cat > crontab.save

This looks like you have some kind of labeling problem.

fixfiles restore 

Should cleanup the labeling

Readahead in your log files was complaining about gdm and /usr/bin/Xorg being unlabled_t which means the policy does not understand the labels on these files.

Was this an upgraded system?

Created attachment 346758 [details]
/var/log/messages

It was a clean install with the F11 Preview. I restored some files, and then ran restorecon on them.  Everything was running fine, with periodic reboots for new kernels until I applied the updates testing maintenance yesterday.

I ran fixfiles restore and re-enabled enforcing mode.  It's working now, so there was a labeling problem.  I'm just concerned about the origin of that problem.

I've attached a new /var/log/messages.  At 'Jun  6 13:33:52' you can see the relabeling that occurred. I rebooted afterwards with selinux in enforcing.  The tty sessions failed to start, which is new, but I have yet to look into that.

Not an X bug, by the sound of it.

Looks fine now,  Might have just been a bug in one of the beta selinux-policy packages.  Sorry about that.  If it happens in the released version please reopen this bugzilla.