Bug 738803

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

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.

I was the other reporter that Tim mentioned. 

Smolt profile http://www.smolts.org/client/show/pub_fbff261f-569f-41dd-9b65-54a968adce2d

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.

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.

before X restarts, it's on tty2, and tty1 is showing that 'ugly grey square' screen. seems like plymouth-to-X handoff is screwed.

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

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.

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

(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

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

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.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.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.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.

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.)

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.

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.org

So ~liveuser/.local directory is created by livesys and this causes mislabeling.

The "rtc" issue should be fixed in libselinux-2.1.5-4.fc16.

Which version of libselinux is used?

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]#

Robert, 
what does

# rpm -q libselinux selinux-policy

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.

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.

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.

Well selinux-policy-3.10.0-28.fc16 would be fine.

As well as libselinux-2.1.5-4.fc16.x86_64

mgrepl: so, I just noticed something else. That stanza:

# add installer to user menu
  mkdir -p ~liveuser/.local/share/gnome-shell/extensions/Installer.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.

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.

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.

(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]#

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.

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.

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.

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...

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

(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?

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.

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.

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....

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.

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....

(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.

Does it work with selinux-policy-3.10.0-29.1.fc16?

I have just built

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

which should contain a fix. 

Just doing my own LiveCD.

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.

-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.

Could you send me your *.ks files which you use to build it.

From my point of view, the problem is still with the labeling of ~/.local directory.

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.

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.

i thought an issue with the policy.

Dan, Eric,
any idea?

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

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.

Fixed in checkpolicy-2.1.3-1.1.fc16

Need to rebuild policy using this package.

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

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

I built a livecd with the new checkpolicy and I can get into gnome-shell with SELinux in enforcing mode.

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

Please update karma on checkpolicy and the selinux-policy.

The problem is I can not build a new policy package which requires a new checkpolicy.

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 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....

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 #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?

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 ...)

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.

selinux-policy-3.10.0-31.fc16 doesn't work for me every time - see Bug 740057.

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.

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.

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.

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).

(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?

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.

Tested that a new user creation and a live image with the new selinux both work well. Setting VERIFIED.

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.

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.

*** Bug 739328 has been marked as a duplicate of this bug. ***