Bug 738803 - SELinux denial(s) prevent(s) gnome-shell from starting on F16 Beta RC1
SELinux denial(s) prevent(s) gnome-shell from starting on F16 Beta RC1
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: checkpolicy (Show other bugs)
16
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
AcceptedBlocker
:
: 739328 (view as bug list)
Depends On:
Blocks: F16Beta/F16BetaBlocker
  Show dependency treegraph
 
Reported: 2011-09-15 16:41 EDT by Tim Flink
Modified: 2011-10-03 11:47 EDT (History)
18 users (show)

See Also:
Fixed In Version: selinux-policy-3.10.0-32.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-09-23 00:01:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
restorecon -nvr output from creating a new user on an installed f16 system (11.80 KB, text/plain)
2011-09-16 17:17 EDT, Adam Williamson
no flags Details
restorecon output from a fresh f15 install (8.00 KB, text/plain)
2011-09-16 19:27 EDT, Adam Williamson
no flags Details
backtrace from g-s-d (13.43 KB, text/plain)
2011-09-17 03:29 EDT, Adam Williamson
no flags Details

  None (edit)
Description Tim Flink 2011-09-15 16:41:24 EDT
Description of problem:

When I boot with the beta RC1 x86_64 live image, gnome-shell starts with the "oh no! Something has gone wrong" error. If I reboot with enforcing=0, gnome-shell starts without issue.

I am running on a laptop with GMA4500MHD graphics, there was another report of the same issue using i915.

The avc denied message is:

type=1400 audit(1316105089.599:4): avc:  denied  { associate } for  pid=686 comm="udevd" name="rtc" dev=devtmpfs ino=8321 scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem


Version-Release number of selected component (if applicable):
selinux-policy-3.10.0-28.fc16

How reproducible:
Every time

Steps to Reproduce:
1. boot live image
2. 
  
Actual results:

gnome-shell shows errors, cannot start

Expected results:
start up gnome-shell

Additional info:

The avc denial is not detected by sealert for some reason.
Comment 1 Tim Flink 2011-09-15 16:43:22 EDT
Proposing as Fedora 16 beta blocker as it violates the following Fedora 16 alpha release criterion [1]:

The installer must boot (if appropriate) and run on all primary architectures from default live image, DVD, and boot.iso install media 

[1] http://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria
Comment 2 Eric Blake 2011-09-15 17:01:06 EDT
I hit this on both the rc1 beta live image, and on the user that got created from the fresh install I did from the live image.  However, in my installation, I used a shared /home with other OS on my multi-boot machine, and was able to successfully log in to a pre-existing user.  So it looks like something is wrong with the permissions being given to files during the creation of new users.
Comment 3 Dan Scott 2011-09-15 17:04:51 EDT
I was the other reporter that Tim mentioned. 

Smolt profile http://www.smolts.org/client/show/pub_fbff261f-569f-41dd-9b65-54a968adce2d
Comment 4 Adam Williamson 2011-09-15 18:59:07 EDT
I look to be hitting this on nouveau, so it's not graphics chipset-specific. I see rather more than just one denial. Will attach in a second. +1 blocker.
Comment 5 Adam Williamson 2011-09-15 19:00:08 EDT
i also noticed ttys seem to be screwed: after one restart of X, X was on tty3, and ttys 1 and 2 seemed not to be there. the first usable console was on tty4.
Comment 6 Adam Williamson 2011-09-15 19:01:43 EDT
before X restarts, it's on tty2, and tty1 is showing that 'ugly grey square' screen. seems like plymouth-to-X handoff is screwed.
Comment 7 Adam Williamson 2011-09-15 19:24:13 EDT
The AVCs I get are:

[root@localhost ~]# grep avc /var/log/messages 
Sep 15 19:03:21 localhost kernel: [    7.499077] type=1400 audit(1316127796.127:3): avc:  denied  { associate } for  pid=625 comm="udevd" name="rtc" dev=devtmpfs ino=10045 scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 15 19:03:21 localhost kernel: [    8.036705] type=1400 audit(1316127796.665:4): avc:  denied  { associate } for  pid=575 comm="udevd" name="live" dev=devtmpfs ino=1387 scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 15 19:03:35 localhost kernel: [   26.361109] type=1400 audit(1316127815.022:5): avc:  denied  { read } for  pid=1215 comm="dbus-daemon" path="/home/liveuser/.local/share/icc/edid-4bf83e5ef91578d4e2c60d8daa55c8c6.icc" dev=dm-0 ino=147580 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:data_home_t:s0 tclass=file
Sep 15 19:03:35 localhost kernel: [   26.361721] type=1400 audit(1316127815.023:6): avc:  denied  { read } for  pid=1698 comm="colord" path="/home/liveuser/.local/share/icc/edid-4bf83e5ef91578d4e2c60d8daa55c8c6.icc" dev=dm-0 ino=147580 scontext=system_u:system_r:colord_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:data_home_t:s0 tclass=file
Sep 15 19:03:35 localhost kernel: [   26.381241] type=1400 audit(1316127815.043:7): avc:  denied  { getattr } for  pid=1688 comm="colord" path="/home/liveuser/.local/share/icc/edid-4bf83e5ef91578d4e2c60d8daa55c8c6.icc" dev=dm-0 ino=147580 scontext=system_u:system_r:colord_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:data_home_t:s0 tclass=file
Comment 8 Adam Williamson 2011-09-15 19:25:26 EDT
I am somewhat worried about them not appearing in sealert. Could that be caused by #737060 (auditd not enabled by default)? I thought the only consequence of that would be the avcs got logged in /var/log/messages rather than /var/log/audit/audit.log , but if it prevents them showing up in sealert, that's more significant.
Comment 9 satellitgo 2011-09-15 19:59:52 EDT
New Install
use whole disk (not LVM)

http://alt.fedoraproject.org/pub/alt/stage/16-Beta.RC1/Fedora/i386/iso/Fedora-16-Beta-i386-DVD.iso

Installs correctly ;firstboot works as required. Smolt has a profile.
Gdm login takes new assigned user and password
Then get repeated Oh-n0! -unable to log in messages which repeat.

alt f4 repeats gdm and Something has gone wrong error.

If I reboot with enforcing=0,
gnome-shell starts without issue.' (similar behavior as first described in
first entry of this bug)

Boots fine with enforcing=0

3.1.0-0.rc6.git0.0.fc16.i686 PAE kernel
Gnome 3.1.91
Intel Atom CPU N450
Intel IGD graphics
Comment 10 satellitgo 2011-09-15 22:16:59 EDT
(In reply to comment #9)
> New Install
> use whole disk (not LVM)
> 
> http://alt.fedoraproject.org/pub/alt/stage/16-Beta.RC1/Fedora/i386/iso/Fedora-16-Beta-i386-DVD.iso
> 
> Installs correctly ;firstboot works as required. Smolt has a profile.
> Gdm login takes new assigned user and password
> Then get repeated Oh-n0! -unable to log in messages which repeat.
> 
> alt f4 repeats gdm and Something has gone wrong error.
> 
> If I reboot with enforcing=0,
> gnome-shell starts without issue.' (similar behavior as first described in
> first entry of this bug)
> 
> Boots fine with enforcing=0
> 
> 3.1.0-0.rc6.git0.0.fc16.i686 PAE kernel
> Gnome 3.1.91
> Intel Atom CPU N450
> Intel IGD graphics

Also Occurs with Booted CD of http://alt.fedoraproject.org/pub/alt/stage/16-Beta.RC1/Live/i686/Fedora-16-Beta-i686-Live-Desktop.iso on same Hardware
Comment 11 Adam Williamson 2011-09-16 03:54:24 EDT
Here's the results of 'restorecon -nvr /' on a live x86_64 boot:

restorecon reset /home/liveuser/.dbus/session-bus context unconfined_u:object_r:icc_data_home_t:s0->unconfined_u:object_r:user_home_t:s0
restorecon reset /home/liveuser/.dbus/session-bus/a144bbeef4c68857985ee4c900000004-0 context unconfined_u:object_r:icc_data_home_t:s0->unconfined_u:object_r:user_home_t:s0
restorecon reset /home/liveuser/.local/share/icc context unconfined_u:object_r:data_home_t:s0->unconfined_u:object_r:icc_data_home_t:s0
restorecon reset /dev/pts/ptmx context system_u:object_r:devpts_t:s0->system_u:object_r:ptmx_t:s0
restorecon reset /tmp/.ICE-unix context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:xdm_tmp_t:s0
restorecon reset /tmp/.ICE-unix/1189 context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:xdm_tmp_t:s0
restorecon reset /etc/sysconfig/firstboot context system_u:object_r:etc_runtime_t:s0->system_u:object_r:etc_t:s0
restorecon reset /root/.cache context system_u:object_r:admin_home_t:s0->system_u:object_r:cache_home_t:s0
restorecon reset /root/.cache/dconf context system_u:object_r:admin_home_t:s0->system_u:object_r:cache_home_t:s0
restorecon reset /root/.cache/dconf/user context system_u:object_r:admin_home_t:s0->system_u:object_r:cache_home_t:s0
restorecon reset /run/user/liveuser/dconf context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:config_home_t:s0
restorecon reset /run/user/liveuser/dconf/user context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:config_home_t:s0
Comment 12 Adam Williamson 2011-09-16 04:25:35 EDT
So, I have a live image I built last night, as a kinda pre-RC1 test, which does not have this bug. The *only* differences between it and RC1 in terms of the packages on it are that RC1 has ibus-gnome3 (my image doesn't) and RC1 has lldpad-0.9.43-3.fc16.x86_64 (mine has lldpad-0.9.43-2.fc16.x86_64). I'm almost sure neither of those are responsible for this.

The difference could be in spin-kickstarts, as I just realized I didn't update that before doing my spin. My spin-kickstarts checkout was at 8591f0dd2c813abac3568f42eedcede4847614b5 - Aug 17th. But the diff doesn't look hugely relevant, though it's still possible.

It could also, I suppose, depend on the selinux-policy installed on the build host somehow. I had -28.

This is the restorecon output from my image - it's different:

restorecon reset /etc/sysconfig/firstboot context system_u:object_r:etc_runtime_t:s0->system_u:object_r:etc_t:s0
restorecon reset /run/user/liveuser/dconf context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:config_home_t:s0
restorecon reset /run/user/liveuser/dconf/user context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:config_home_t:s0
restorecon reset /tmp/.ICE-unix context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:xdm_tmp_t:s0
restorecon reset /tmp/.ICE-unix/1185 context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:xdm_tmp_t:s0
restorecon reset /home/liveuser/.dbus/session-bus context unconfined_u:object_r:icc_data_home_t:s0->unconfined_u:object_r:user_home_t:s0
restorecon reset /home/liveuser/.dbus/session-bus/bf85583c2c909202d083ac1500000006-0 context unconfined_u:object_r:icc_data_home_t:s0->unconfined_u:object_r:user_home_t:s0
restorecon reset /home/liveuser/.local context system_u:object_r:user_home_dir_t:s0->unconfined_u:object_r:gconf_home_t:s0
restorecon reset /home/liveuser/.local/share context system_u:object_r:user_home_dir_t:s0->unconfined_u:object_r:data_home_t:s0
restorecon reset /home/liveuser/.local/share/gnome-shell context system_u:object_r:user_home_dir_t:s0->unconfined_u:object_r:data_home_t:s0
restorecon reset /home/liveuser/.local/share/gnome-shell/extensions context system_u:object_r:user_home_dir_t:s0->unconfined_u:object_r:data_home_t:s0
restorecon reset /home/liveuser/.local/share/gnome-shell/extensions/Installer@shell-extensions.fedoraproject.org context system_u:object_r:user_home_dir_t:s0->unconfined_u:object_r:data_home_t:s0
restorecon reset /home/liveuser/.local/share/gnome-shell/extensions/Installer@shell-extensions.fedoraproject.org/extension.js context system_u:object_r:user_home_dir_t:s0->unconfined_u:object_r:data_home_t:s0
restorecon reset /home/liveuser/.local/share/gnome-shell/extensions/Installer@shell-extensions.fedoraproject.org/metadata.json context system_u:object_r:user_home_dir_t:s0->unconfined_u:object_r:data_home_t:s0
restorecon reset /root/.cache context system_u:object_r:admin_home_t:s0->system_u:object_r:cache_home_t:s0
restorecon reset /root/.cache/dconf context system_u:object_r:admin_home_t:s0->system_u:object_r:cache_home_t:s0
restorecon reset /root/.cache/dconf/user context system_u:object_r:admin_home_t:s0->system_u:object_r:cache_home_t:s0
restorecon reset /dev/pts/ptmx context system_u:object_r:devpts_t:s0->system_u:object_r:ptmx_t:s0

AFAICS, the one that's bad in the RC1 image but not bad in mine is the ~/.local/share/icc one.

This brings to mind another bug I saw, where if colord didn't work, gnome-settings-daemon would crash; this could be the cause of the issue. Will look into the .xsession-errors when recreating the bug.
Comment 13 Adam Williamson 2011-09-16 04:38:23 EDT
yup, ten points for me: 'gnome-settings-daemon.desktop' respawning too quickly. digging deeper.

run from a console, the crash is:

g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.

So looks like we should fix whatever causes the SELinux label on the user's ~/.local/share/icc/edid-* file to be wrong, and g-s-d should also be more robust and not crash if this happens, if possible.

(I also confirmed that a single 'restorecon /home/liveuser/.local/share/icc/edid-blahblah.icc' fixes the bug: that wrong label is definitely the problem.)
Comment 14 Adam Williamson 2011-09-16 04:39:40 EDT
oh, just realized, this can't be just the live creation environment, as it also hits DVD installs. it could still be the selinux-policy on the build host, somehow, I guess.
Comment 15 Miroslav Grepl 2011-09-16 06:40:18 EDT
Ok, i have just created my own livecd image and I see the same issue. But one think which I have noticed is

/home/liveuser/.local is owned by root

so I am looking more on fedora-live-desktop.ks and I see

# add installer to user menu
  mkdir -p ~liveuser/.local/share/gnome-shell/extensions/Installer@shell-extensions.fedoraproject.org

So ~liveuser/.local directory is created by livesys and this causes mislabeling.
Comment 16 Miroslav Grepl 2011-09-16 06:48:18 EDT
The "rtc" issue should be fixed in libselinux-2.1.5-4.fc16.

Which version of libselinux is used?
Comment 17 Robert Lightfoot 2011-09-16 08:12:16 EDT
More Data from F16-Beta.RC1-i386-DVD.iso install.  Installed into a qemu-kvm VM on an F14-x86_64 host.  gnome-shell had no issue with login.  Went to fail-back mode as expected.  Did notice First-Boot gui was tty2 but after a reboot gui was tty1. No Setroubleshooter AVC Denial Warnings seen but....
OUTPUT from grep avc /var/log/messages is below:
[root@Fedora386Test log]# grep avc messages
Sep 16 05:08:18 Fedora386Test kernel: [   10.208143] type=1400 audit(1316164078.133:4): avc:  denied  { associate } for  pid=448 comm="udevd" name="rtc" dev=devtmpfs ino=8356 scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 05:08:18 Fedora386Test kernel: [   13.383743] type=1400 audit(1316164081.308:5): avc:  denied  { associate } for  pid=435 comm="udevd" name="root" dev=devtmpfs ino=8802 scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 05:08:18 Fedora386Test kernel: [   19.154395] type=1400 audit(1316164087.079:6): avc:  denied  { associate } for  pid=442 comm="udevd" name="scd0" dev=devtmpfs ino=8590 scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 05:08:18 Fedora386Test kernel: [   19.164466] type=1400 audit(1316164087.089:7): avc:  denied  { associate } for  pid=442 comm="udevd" name="cdrom" scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 05:08:18 Fedora386Test kernel: [   19.164540] type=1400 audit(1316164087.089:8): avc:  denied  { associate } for  pid=442 comm="udevd" name="cdrom.udev-tmp" scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 05:08:18 Fedora386Test kernel: [   19.164720] type=1400 audit(1316164087.089:9): avc:  denied  { associate } for  pid=442 comm="udevd" name="dvd" scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 05:08:18 Fedora386Test kernel: [   19.164790] type=1400 audit(1316164087.089:10): avc:  denied  { associate } for  pid=442 comm="udevd" name="dvd.udev-tmp" scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 05:08:19 Fedora386Test dbus-daemon[740]: dbus[740]: avc:  netlink poll: error 4
Sep 16 05:08:19 Fedora386Test dbus[740]: avc:  netlink poll: error 4
Sep 16 05:17:35 Fedora386Test kernel: [   12.461121] type=1400 audit(1316164638.219:4): avc:  denied  { associate } for  pid=461 comm="udevd" name="rtc" dev=devtmpfs ino=8352 scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 05:17:35 Fedora386Test kernel: [   13.946626] type=1400 audit(1316164639.704:5): avc:  denied  { associate } for  pid=484 comm="udevd" name="root" dev=devtmpfs ino=8800 scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 05:17:35 Fedora386Test kernel: [   13.949445] type=1400 audit(1316164639.707:6): avc:  denied  { associate } for  pid=437 comm="udevd" name="scd0" dev=devtmpfs ino=8588 scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 05:17:35 Fedora386Test kernel: [   13.960363] type=1400 audit(1316164639.718:7): avc:  denied  { associate } for  pid=437 comm="udevd" name="cdrom" scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 05:17:35 Fedora386Test kernel: [   13.960458] type=1400 audit(1316164639.718:8): avc:  denied  { associate } for  pid=437 comm="udevd" name="cdrom.udev-tmp" scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 05:17:35 Fedora386Test kernel: [   13.962684] type=1400 audit(1316164639.720:9): avc:  denied  { associate } for  pid=437 comm="udevd" name="dvd" scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 05:17:35 Fedora386Test kernel: [   13.962795] type=1400 audit(1316164639.720:10): avc:  denied  { associate } for  pid=437 comm="udevd" name="dvd.udev-tmp" scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 05:17:35 Fedora386Test dbus-daemon[689]: dbus[689]: avc:  netlink poll: error 4
Sep 16 05:17:35 Fedora386Test dbus[689]: avc:  netlink poll: error 4
Sep 16 08:00:50 Fedora386Test kernel: [   11.372507] type=1400 audit(1316174436.250:4): avc:  denied  { associate } for  pid=467 comm="udevd" name="rtc" dev=devtmpfs ino=8357 scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 08:00:50 Fedora386Test kernel: [   13.924915] type=1400 audit(1316174438.802:5): avc:  denied  { associate } for  pid=440 comm="udevd" name="scd0" dev=devtmpfs ino=8602 scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 08:00:50 Fedora386Test kernel: [   13.964852] type=1400 audit(1316174438.842:6): avc:  denied  { associate } for  pid=440 comm="udevd" name="cdrom" scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 08:00:50 Fedora386Test kernel: [   13.964950] type=1400 audit(1316174438.842:7): avc:  denied  { associate } for  pid=440 comm="udevd" name="cdrom.udev-tmp" scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 08:00:50 Fedora386Test kernel: [   13.980226] type=1400 audit(1316174438.858:8): avc:  denied  { associate } for  pid=440 comm="udevd" name="dvd" scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 08:00:50 Fedora386Test kernel: [   14.012160] type=1400 audit(1316174438.890:9): avc:  denied  { associate } for  pid=440 comm="udevd" name="dvd.udev-tmp" scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 08:00:50 Fedora386Test kernel: [   14.485219] type=1400 audit(1316174439.363:10): avc:  denied  { associate } for  pid=479 comm="udevd" name="root" dev=devtmpfs ino=8818 scontext=system_u:object_r:default_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Sep 16 08:00:51 Fedora386Test dbus-daemon[724]: dbus[724]: avc:  netlink poll: error 4
Sep 16 08:00:51 Fedora386Test dbus[724]: avc:  netlink poll: error 4
[root@Fedora386Test log]#
Comment 18 Miroslav Grepl 2011-09-16 08:40:44 EDT
Robert, 
what does

# rpm -q libselinux selinux-policy
Comment 19 Daniel Walsh 2011-09-16 11:47:27 EDT
Yes I would prefer this to go out with

libselinux-2.1.5-5.fc16.x86_64
selinux-policy-3.10.0-29.fc16 

If at all possible.

If the livecd is creating the users home dir in the post install, I am not sure it will get created with the correct label, might have to run a restorecon on it.
Comment 20 Adam Williamson 2011-09-16 13:18:09 EDT
it's certainly a good theory, the only thing that worries me is someone claimed to reproduce this on a DVD install too. I'll have to check that.

that stanza in spin-kickstarts did change between the version I used to do my personal spin and the version used to build RC1, which is a good match.
Comment 21 Adam Williamson 2011-09-16 13:19:19 EDT
dwalsh: then you'll at least need to create an update for -29, and propose some bug that it fixes as NTH, or it doesn't have a prayer. libselinux already has an update, but it needs an nth bug.

I believe the only one of the alerts that's causing a clear *problem* is the ICC one.
Comment 22 Daniel Walsh 2011-09-16 13:49:26 EDT
Well selinux-policy-3.10.0-28.fc16 would be fine.

As well as libselinux-2.1.5-4.fc16.x86_64
Comment 23 Adam Williamson 2011-09-16 14:37:12 EDT
mgrepl: so, I just noticed something else. That stanza:

# add installer to user menu
  mkdir -p ~liveuser/.local/share/gnome-shell/extensions/Installer@shell-extensions.fedoraproject.org

was actually taken *out* recently. So I think in my working image, that stanza was *in* spin-kickstarts, and now it's been taken out.

So I think the problem may be the opposite: that stanza actually caused the label to be correct, and taking it out causes it to be wrong.

I'm not quite sure how that could be the case, but I'll look into it in more detail soon.
Comment 24 Daniel Walsh 2011-09-16 14:52:07 EDT
Is the liveuser homedir created at boot time or during the install?

If the liveuser .local dir is owned by root, we have other problems besides SELinux.
Comment 25 Adam Williamson 2011-09-16 14:55:52 EDT
I think exactly when and how the homedir/.local dir gets created is the essence of this bug. I'm guessing that, when that stanza was in spin-kickstarts, it was created before some later bit of the live process ran a 'restorecon /home', and hence everything was hunky dory; now it's been taken out, the dir is being created later.

my plan is to isolate that spin-kickstarts change and verify it's what causes the bug, then look into exactly how and when the directory gets created in the two different cases.
Comment 26 Robert Lightfoot 2011-09-16 15:03:25 EDT
(In reply to comment #18)
> Robert, 
> what does
> 
> # rpm -q libselinux selinux-policy

[root@Fedora386Test bob]# rpm -q libselinux selinux-policy
libselinux-2.1.4-2.fc16.i686
selinux-policy-3.10.0-28.fc16.noarch
[root@Fedora386Test bob]#
Comment 27 Adam Williamson 2011-09-16 16:15:14 EDT
so, this kinda makes sense of it. Indeed, with the mkdir put back in the kickstart, things 'work': but only because they're more broken. =)

with that statement in the kickstart, because there's no chown or restorecon after it, /home/liveuser/.local winds up being owned by root. /home/liveuser/.local/icc and the edid-blahblah.icc file within it wind up not existing at all; whatever should create them obviously didn't have the permissions to do so. So the bug gets hidden; obviously the file not existing at all has less disastrous consequences for the colord/gnome-settings-daemon chain than the file existing but having an incorrect selinux context does.
Comment 28 Adam Williamson 2011-09-16 16:18:26 EDT
so the question now becomes, what creates the icc/edid-blahblah.icc file, and why is it doing so with the wrong context? I'm guessing this is gnome-color-manager.
Comment 29 Adam Williamson 2011-09-16 17:12:29 EDT
just creating a new user on my f16 desktop, which is an old install but has the same gnome-settings-daemon and selinux stuff as the live image, does not reproduce the bug, so there's *something* particular to live boot, or fresh install / boot in general, here. we are checking to confirm whether this affects dvd installs of rc1, or not.
Comment 30 Adam Williamson 2011-09-16 17:17:34 EDT
Created attachment 523630 [details]
restorecon -nvr output from creating a new user on an installed f16 system

Ooh, but there's still something wrong with the new user account: a whole ton of stuff in /home/test has the icc_data_home_t label. So kind of the opposite bug! attaching the 'restorecon -nvr /home/test' output, see all the stuff that has this label...
Comment 31 Adam Williamson 2011-09-16 17:24:53 EDT
Wow - the same is true of my own home dir. I hadn't noticed as I've been in Permissive mode and auditd wasn't running, but huge, huge piles of things in my home dir have type icc_data_home_t when they shouldn't, and there are some alerts related to this showing in /var/log/messages .

Something's clearly funky about gnome-settings-daemon, I think.
Comment 32 Daniel Walsh 2011-09-16 17:51:53 EDT
Eric, it seems the kernel is randomly labeling files in the homedir icc_data_home_t.

Since the only way these get created is via file_name trans rules, I was hoping you would have a clue.
Comment 33 Adam Williamson 2011-09-16 18:02:24 EDT
so our current understanding of this is that there is clearly something very wrong going on with the creation of files in users' home dirs (and possibly elsewhere), at least by gnome-settings-daemon but possibly by other things. It's not just ~/.local: the files that are mislabelled when a new user logs in include things outside of that tree (see comment #30).

we are not clear on why this *usually* results in many files getting the type 'icc_data_home_t' when they shouldn't, but when booting live it seems to result in the file that *should* get icc_data_home_t not getting it, but we suspect the whole thing is really one problem.

Dan suspects this may have to do with the kernel, which should be watching file creation and correcting the labels according to selinux-policy on the fly. So, we need kernel folks to look at it.
Comment 34 Adam Williamson 2011-09-16 19:20:57 EDT
I tried kernel rc3, kernel 3.0.1-5 and all the way back to 2.6.38.6-26.rc1.fc15 (the f15 release kernel), and they all displayed the same issue with a freshly-created new user. So I'm not entirely convinced this is *only* the kernel. I'm going to see what happens on a fresh F15 install.
Comment 35 Adam Williamson 2011-09-16 19:27:14 EDT
Created attachment 523666 [details]
restorecon output from a fresh f15 install

Here's the restorecon output from an F15 install I did yesterday: installed F15 from DVD, yum updated to current.

obviously, F15 had trouble too, but none of the label problems was bad enough to cause a bug that got any major attention.

So, it's possible the underlying problem here has been a problem for a long time, and we've never really noticed because the bad labels haven't really caused a problem until now.
Comment 36 Adam Williamson 2011-09-16 19:28:26 EDT
Dan did propose, as a short-term workaround, just allowing colord to read the .icc file; that's a definite possibility while we take a closer look at the underlying problems.
Comment 37 Tim Flink 2011-09-16 22:28:27 EDT
Discussed in the 2011-09-16 blocker review meeting. Accepted as a Fedora 16 beta blocker as it violates the following alpha release criterion [1]:

The installer must boot (if appropriate) and run on all primary architectures from default live image, DVD, and boot.iso install media 

[1] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria
Comment 38 Adam Williamson 2011-09-17 01:04:09 EDT
dwalsh has pushed an selinux build which allows colord to read the file, as a potential immediate workaround:

http://koji.fedoraproject.org/koji/buildinfo?buildID=264011

I also found something curious: I looked into fallback mode a bit more.

So in fallback mode...it actually works. Or rather, you get the 'second' case of the bug - lots of stuff in /home gets the icc_data_home_t type, when it shouldn't. But the icc directory and file are created and both get the icc_data_home_t type, and g-s-d runs without crashing.

So there's *some* difference between how GNOME starts in Shell mode and how it starts in fallback mode here, which somehow results in that directory and file getting different labels between the two.
Comment 39 Adam Williamson 2011-09-17 03:29:54 EDT
Created attachment 523685 [details]
backtrace from g-s-d

Wow, my brain is not screwed in straight at all: it just occurred to me it's really easy to get a backtrace of this for the GNOME team, just manually set the incorrect label on the file on an installed system...so, here's the BT.
Comment 40 Adam Williamson 2011-09-17 04:32:48 EDT
The selinux-policy fix isn't good enough: it grants colord access, but not dbus-daemon. I just tested a live image with the new selinux-policy and it still crashes. Seems like it's the dbus-daemon access (or both) that's key, not (just) colord.
Comment 41 satellitgo 2011-09-17 06:00:33 EDT
(In reply to comment #9)
> New Install
> use whole disk (not LVM)
> 
> http://alt.fedoraproject.org/pub/alt/stage/16-Beta.RC1/Fedora/i386/iso/Fedora-16-Beta-i386-DVD.iso
> 
> Installs correctly ;firstboot works as required. Smolt has a profile.
> Gdm login takes new assigned user and password
> Then get repeated Oh-n0! -unable to log in messages which repeat.
> 
> alt f4 repeats gdm and Something has gone wrong error.
> 
> If I reboot with enforcing=0,
> gnome-shell starts without issue.' (similar behavior as first described in
> first entry of this bug)
> 
> Boots fine with enforcing=0
> 
> 3.1.0-0.rc6.git0.0.fc16.i686 PAE kernel
> Gnome 3.1.91
> Intel Atom CPU N450
> Intel IGD graphics

I also see this on same hardware in:
http://koji.fedoraproject.org/koji/getfile?taskID=3355670&name=Fedora-16-Nightly-20110916.10-i686-Live-desktop.iso requires enforcing=0 to boot

Interesting fact:Same CD boots fine on hp Pavillion laptop with
AMD Turion64 x2 with Nivida graphics.(Gallium 0.4 on NV4E)

Both have initial ABRT error: GConf2 Process /usr/bin/gsettings-data-convert was killed by signal 11 (SIGSEGV)

how does different hardware affect this?
Comment 42 Adam Williamson 2011-09-17 13:34:50 EDT
are you entirely sure it's the same bug? please boot with beta rc1 to verify, the nighties are somewhat different from candidate builds atm.
Comment 43 Adam Williamson 2011-09-17 13:35:17 EDT
oh, and the bug is likely not to trigger on hardware where the display can't be detected by the color management stuff for whatever reason.
Comment 44 Eric Paris 2011-09-17 14:56:06 EDT
Dan, its hard to call it a kernel bug when policy contains:

type_transition unconfined_t user_home_t : dir icc_data_home_t;

Its either a policy problem or a userspace tool problem, but not a kernel problem....
Comment 45 Eric Paris 2011-09-17 15:07:30 EDT
policy/modules/system/userdomain.if::userdom_user_home_content_filetrans doesn't seem to handle the filename.  Looks like a policy bug which should be easy enough to fix.
Comment 46 satellitgo 2011-09-17 16:07:12 EDT
re comment 42: Retest with 
Fedora-16-Beta-rc1-i686-Live-Desktop.iso CD 

1-)hp Pavillion laptop with
AMD Turion64 x2 with Nivida graphics.(Gallium 0.4 on NV4E)
32 bit

Boots Fine.

2-) ACER ASPIRE ONE 
Intel Atom CPU N450
Intel IGD graphics 32 bit

Oh no!
-alt f4- crashes to gdm live user Oh no!
(log out: works then 10 sec later Oh no!?
Note Oh no! comes at various delays after achieving gnome3-shell ?

2b-) reboot with enforcing=0
Boots Fine

ABRT: GConf Process /usr/bin/gsettings-data-convert was killed by signal 11 (SIGSEGV)

Comment 43 may be true....
Comment 47 Mads Kiilerich 2011-09-17 16:20:05 EDT
(In reply to comment #41)
> Both have initial ABRT error: GConf2 Process /usr/bin/gsettings-data-convert
> was killed by signal 11 (SIGSEGV)

(In reply to comment #46)
> ABRT: GConf Process /usr/bin/gsettings-data-convert was killed by signal 11
> (SIGSEGV)

Probably not related - see for example Bug 709797 and Bug 733911 for analysis and workarounds.
Comment 48 Miroslav Grepl 2011-09-19 05:41:53 EDT
Does it work with selinux-policy-3.10.0-29.1.fc16?
Comment 49 Miroslav Grepl 2011-09-19 07:13:58 EDT
I have just built

http://koji.fedoraproject.org/koji/buildinfo?buildID=264174

which should contain a fix. 

Just doing my own LiveCD.
Comment 50 Adam Williamson 2011-09-19 13:40:27 EDT
unfortunately, -30 does not appear to work for me: I built a live image with it, and the .icc file still has the incorrect label, dbus-daemon still gets denied trying to read it, g-s-d still crashes, and gnome still pops up the fail whale.

it may fix the 'variant' we noticed - where all sorts of stuff in user home dirs is getting the icc type - but it doesn't fix the original live boot fail bug.
Comment 51 Adam Williamson 2011-09-19 14:14:16 EDT
-30 does indeed seem to fix the 'variant': I installed -30 and created a new user on my F16 desktop, then logged in as the user. Now, restorecon -nvr on the user's home dir looks much as it did in F15 - still lots of wrong labels, but now nothing has the icc_data_home_t type.

Note that the new user is subject to the initial bug here: the ~/.local/share/icc/edid-blah.icc file got the wrong type, and I got AVCs from colord and dbus-daemon. So it seems like the filetrans rule breakage isn't actually what's causing the .icc file to get the wrong label.
Comment 52 Miroslav Grepl 2011-09-19 15:46:10 EDT
Could you send me your *.ks files which you use to build it.
Comment 53 Miroslav Grepl 2011-09-19 15:51:30 EDT
From my point of view, the problem is still with the labeling of ~/.local directory.
Comment 54 Adam Williamson 2011-09-19 17:19:20 EDT
it could be that simple, yeah. I think the bug fixed in -30 was kinda masking it: now that's fixed, it looks like there's no difference between live and non-live behaviour, they both hit this bug with the .icc file label.

I use the official .ks file from spin-kickstarts:

git clone git://git.fedorahosted.org/spin-kickstarts.git
[adamw@adam live]$ cat live_bleed.ks 

%include spin-kickstarts/fedora-livecd-desktop.ks

repo --name=side --baseurl=file:///home/adamw/local/repo/$basearch
repo --name=bleed --baseurl=http://kojipkgs.fedoraproject.org/mash/bleed/$basearch

[root@adam live]# livecd-creator -c live_bleed.ks -f desktop-20110919-x86_64 -t /home/adamw/local/live/tmp/ --cache=/home/adamw/local/live/cache/ -v

is how I do it.

note that you need your spin-kickstarts checkout to be up-to-date: commit 24fea01db27ba317e5dc5d38ec09e98bb09f39ea , from Sep 8, fixed a bug which was until now 'masking' this one - before that commit, /home/liveuser/.local was owned by root, which prevented the .icc file being written at all, which meant this bug didn't happen. That's why we didn't see this bug until recently.
Comment 55 Adam Williamson 2011-09-20 03:02:46 EDT
dan: in case miroslav didn't mention it to you, he made some headway on this bug today. he figured out the filetrans stuff simply doesn't seem to be working at all: you can test it easily by moving some dir that ought to be filetransed - we tested with /root/.ssh - and then 'mkdir'ing it: it doesn't get the label it ought to.

he also found that restorecond 'masks' the bug (so we could, i suppose, install and enable it by default as a workaround?) and he started going through old selinux-policy versions to try and find the last time the filetrans stuff worked. Last message I got:

<mgrepl> adamw: file name transition works with selinux-policy-3.10.0-26.fc16, but not with -27 ...the problem is if I try to rebuild -26 by hand, it fails ... so it looks like an issue with libselinux

after that he dropped off. so, that's the latest I have on this bug.

setting back to assigned, as we clearly don't have a fix for the essential issue here. but -30 is a good fix _for the bug it fixes_, which turns out to be a separate bug which was sitting on top of this bug.
Comment 56 Miroslav Grepl 2011-09-20 04:45:11 EDT
i thought an issue with the policy.

Dan, Eric,
any idea?
Comment 57 Miroslav Grepl 2011-09-20 06:32:18 EDT
Ok, 
I have rebuilt the current -30 policy release with older version of checkpolicy (s/libselinux/checkpolicy in the comment #55) and I have file name transition working again.

I created a new test11 user and and I can log in enforcing mode again.


# rpm -q checkpolicy
checkpolicy-2.0.26-1.fc16.x86_64
Comment 58 Eric Paris 2011-09-20 09:12:41 EDT
close, so close.  We found the policy was telling the kernel to set the label on a file named \".icc\" rather than on one named .icc

we're sorting the quote kerfuffle.
Comment 59 Daniel Walsh 2011-09-20 10:20:21 EDT
Fixed in checkpolicy-2.1.3-1.1.fc16

Need to rebuild policy using this package.
Comment 60 Fedora Update System 2011-09-20 10:25:05 EDT
checkpolicy-2.1.3-1.1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/checkpolicy-2.1.3-1.1.fc16
Comment 61 satellitgo 2011-09-20 11:38:15 EDT
144 updates today
Fedora 3.1.0-0.rc6.git0.3 fc16.i686 kernel

still requires enforcing=0 to boot gnome3-shell 3.1.91

(live desktop rc1 dd usb install to Hd)
XFCE and sugar-desktop installed after dd install
Comment 62 Tim Flink 2011-09-20 13:16:45 EDT
I built a livecd with the new checkpolicy and I can get into gnome-shell with SELinux in enforcing mode.
Comment 63 Tim Flink 2011-09-20 13:36:49 EDT
If anyone else is interested in testing the live image, you can download it from:

 - http://tflink.fedorapeople.org/iso/20110920_selinuxfix_x64_live.iso
 - http://tflink.fedorapeople.org/iso/20110920_selinuxfix_x64_live.iso.sha256
Comment 64 Daniel Walsh 2011-09-20 13:43:02 EDT
Please update karma on checkpolicy and the selinux-policy.
Comment 65 Miroslav Grepl 2011-09-20 14:44:40 EDT
The problem is I can not build a new policy package which requires a new checkpolicy.
Comment 66 Fedora Update System 2011-09-20 15:04:52 EDT
Package checkpolicy-2.1.3-1.1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing checkpolicy-2.1.3-1.1.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/checkpolicy-2.1.3-1.1.fc16
then log in and leave karma (feedback).
Comment 67 Eric Paris 2011-09-20 15:11:30 EDT
Comment 66 is not quite right.  checkpolicy was fixed, but the fix for the bug is a build of selinux-policy WITH the fixed checkpolicy.  Heck a broken checkpolicy on the final installed system is fine.  It's the selinux-policy package that matters truely....
Comment 68 Tim Flink 2011-09-20 17:03:12 EDT
I'm a little confused about this. Do we need a build of selinux-policy other than the one in the update mentioned in comment 66?
Comment 69 Eric Paris 2011-09-20 17:07:26 EDT
comment #66 is talking about checkpolicy, not selinux-policy (different packages)

A fixed checkpolicy is a build requirement for a fixed selinux-policy.  A fixed checkpolicy is not a runtime requirement for a fixed box.  A fixed selinux-policy is a runtime requirement for a fixed box.

I'm not sure what the status of a fixed selinux-policy (built with the fixed checkpolicy) is.

Make sense?
Comment 70 Mads Kiilerich 2011-09-20 17:16:42 EDT
selinux-policy 3.10.0-31 has BuildRequires: checkpolicy >= 2.1.3-1.1, so it should be good.

(I am however not sure it works for me - I'm investigating ...)
Comment 71 Tim Flink 2011-09-20 17:20:36 EDT
After looking at the build logs for selinux-policy build included in that update (selinux-policy-3.10.0-31.fc16), it was built against checkpolicy-2.1.3-1.1.fc16.

So I'm changing this bug to ON_QA again.
Comment 72 Mads Kiilerich 2011-09-20 17:59:18 EDT
selinux-policy-3.10.0-31.fc16 doesn't work for me every time - see Bug 740057.
Comment 73 Daniel Walsh 2011-09-21 09:46:04 EDT
My mistake,  the checkpolicy for F16 did not have the patch.  The F17 one has it and it seems to work.  We are rebuilding now and will be testing.

checkpolicy-2.1.3-1.2.fc16 is in koji,  We are doing the selinux-policy build and test now.
Comment 74 Adam Williamson 2011-09-21 14:48:32 EDT
just tested with checkpolicy-2.1.3-1.2.fc16 and selinux-policy-targeted-3.10.0-32.fc16 and the 'create a new user' test is good - the icc files are no longer mislabelled, and gnome login works. there are still a few mislabelled files relating to PulseAudio and gstreamer.

I'll check a live compose later.
Comment 75 Daniel Walsh 2011-09-21 15:45:27 EDT
Just because restorecon says they are not the default label does not mean they are mislabeled.  Can you give me the output from restorecon so we can figure out a way to not show them as mislabeled.
Comment 76 Fedora Update System 2011-09-21 18:13:49 EDT
Package selinux-policy-3.10.0-32.fc16, checkpolicy-2.1.3-1.2.fc16:
* should fix your issue,
* was pushed to the Fedora 16 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-32.fc16 checkpolicy-2.1.3-1.2.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-32.fc16,checkpolicy-2.1.3-1.2.fc16
then log in and leave karma (feedback).
Comment 77 Mads Kiilerich 2011-09-21 19:40:10 EDT
(In reply to comment #75)
> Just because restorecon says they are not the default label does not mean they
> are mislabeled.  Can you give me the output from restorecon so we can figure
> out a way to not show them as mislabeled.

Isn't it always a bug somewhere if the system after an .autorelabel and without making any manual changes ends up in a state where restorecon -rvn reports that it would like to make further changes?
Comment 78 Adam Williamson 2011-09-21 20:29:54 EDT
There may be a bug somewhere, but it's not *this* bug, most likely, so let's not discuss it here, but in a new bug. I'll file one if I get around to it, but it's not an immediate priority right now unless it turns out to cause some other blocker issue.
Comment 79 Adam Williamson 2011-09-22 00:08:27 EDT
Tested that a new user creation and a live image with the new selinux both work well. Setting VERIFIED.
Comment 80 Daniel Walsh 2011-09-22 10:00:17 EDT
Labels disagreeing with restorecon are not always bugs, for example a tty with no one logged in is labeled tty_device_t, but when a user allocates it, it is labeled user_tty_device_t.   But I agree we should probably figure a way for restorecon to not report these as errors, and more importantly not change them to default if admin runs restorecon.

That is why I want to see what restorecon is complaining about.
Comment 81 Fedora Update System 2011-09-23 00:00:43 EDT
selinux-policy-3.10.0-32.fc16, checkpolicy-2.1.3-1.2.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 82 Göran Uddeborg 2011-09-24 16:20:08 EDT
*** Bug 739328 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.