Created attachment 706958 [details] console screenshot Description of problem: Not sure if this is a systemd issue but I see messages from systemd-logind when I login as root to a minimal rawhide install. Version-Release number of selected component (if applicable): systemd-197-2.fc19 Steps to Reproduce: 1. minimal rawhide install 2. login as root on console Actual results: 2. see screenshot Expected results: no messages
Does it happen with SELinux in permissive mode?
(In reply to comment #1) > Does it happen with SELinux in permissive mode? No, it doesn't. That seems to be a workaround.
In that case please paste/attach any logged AVC denial messages. They may be in dmesg or in /var/log/audit/audit.log.
Created attachment 709904 [details] parts of dmesg output right after root login with enforcing Tried to include only relevant parts of dmesg but I can attach it all if it helps. This is dmesg with enforcing enabled - currently I need to use permissive to do anything useful with rawhide: I am not sure yet if it is systemd's fault...
It appears you have a mislabeled /var/run symlink. Yours has context var_t, while it should be var_run_t: $ matchpathcon /var/run /var/run system_u:object_r:var_run_t:s0 Fix it with "restorecon -v /var/run", or do a full relabel in case there are more mislabelled files.
Well this is with a fresh minimal rawhide install. :) Anyway thank you - let me move it over to selinux-policy then.
I don't think the bug is in selinux-policy. The policy correctly says the type should be var_run_t. It must be a problem in how the symlink is created. /var/run belongs to the filesystem package. The package creates it in its %post scriptlet: %post -p <lua> posix.symlink("../run", "/var/run") posix.symlink("../run/lock", "/var/lock") So perhaps the scriptlet needs to explicitly fix the labels of the symlinks, or the package should switch to shipping the symlinks as is usual instead of creating them from a scriptlet. (/var/run and /var/lock have been symlinks since F15 I believe.)
I can't have any dependency in filesystem package thus I can't run restorecon on them in post. So the only option seems to be to switch to symlinks shipping or some trigger. I'm not sure if the symlink change will resolve the issue - it may be because of the dependency timing - at the time when the symlinks are created there may be no policy which will set them the correct context or something like that.
I think anaconda used to fix these. Can't these symlinks be shipped as part of the payload of rpm?
They could, we'll see if this will solve the issue.
So move to rpm?
(Moving to F19)
Is this a change between F18 and F19 anaconda - "I think anaconda used to fix these." ? Because I've done an install of F19 with F18's anaconda, and I've done an F18 minimal install and upgraded to F19, and have not had a problem booting with enforcing enabled in either case.
(In reply to comment #13) > Is this a change between F18 and F19 anaconda - "I think anaconda used to > fix these." ? Well I am also installing with f18 netinst.iso too. (I think that may be the only available way currently? :) Anyway dwalsh's suggestion to move the symlinks into rpm seems attractive. > Because I've done an install of F19 with F18's anaconda, and > I've done an F18 minimal install and upgraded to F19, and have not had a > problem booting with enforcing enabled in either case. And you don't see any avc's while booting? When did you last do an install?
Didn't notice any, no. On Saturday.
Interesting - I think Tagoh doesn't seem them either but I see them every time I install. Perhaps there is some other additional condition involved though can't think what it could be.
(Though I think maybe Tagoh was doing an upgrade - not sure - anyway I don't think it happens for upgrades.)
Reason for the symlink %post lua scriptlet solution and ghost symlinks as part of filesystem rpm filelist is simple - to handle old style of common directories correctly. With moving them to payload, it will cause the conflicts in the updates (and although there is the policy about 2 Fedoras update compatibility, it still may break the distro for guys who update their in every Fedora release). If anaconda/whatever did the relabel after installation, question is why it stopped to do so. I'll change the post scriptlet symlink solution and ghosted files, but I don't know if we want that for F19.
Well it is not anaconda that changed - this is happening with F18 netinst.iso. So maybe something else changed?
fyi, Rawhide/f20 buildroot fails now, DEBUG util.py:264: Error unpacking rpm package filesystem-3.2-8.fc20.x86_64 DEBUG util.py:264: error: unpacking of archive failed on file /var/lock: cpio: rename failed - Is a directory
Thanks for untagging that... reverting for the moment... so the question is - what changed? Why it works for someone and not for the others? It may be related to the https://bugzilla.redhat.com/show_bug.cgi?id=825466 ... Maybe the best way would be to run restorecon on these two as part of firstboot?
(In reply to comment #20) > DEBUG util.py:264: Error unpacking rpm package filesystem-3.2-8.fc20.x86_64 > DEBUG util.py:264: error: unpacking of archive failed on file /var/lock: > cpio: rename failed - Is a directory How come it was a directory? I can see that in filesystem-3.2-8 in the spec there was: %dir %attr(755,root,root) /var/lock ... %attr(755,root,root) /var/run "%dir" does not make sense to me when we want to package a symlink. Could this be what caused the buildroot breakage? Setting the mode of a symlink is pointless. (In reply to comment #21) > It may be related to the https://bugzilla.redhat.com/show_bug.cgi?id=825466 By the way, in that bug I said: "Every F17 system is supposed to have /var/run as a symlink, not as a bind mount point." Just pointing this out as it's relevant for the 2-Fedora-releases-back upgrade support rule.
you are right, this was the remnant from the days it was there because of the ghosted /var/lock/subsys - so %dir can be dropped, let's try if this will work correctly in buildroot - I'm prepared for untag :).
latest is bad too: DEBUG util.py:264: Error unpacking rpm package filesystem-3.2-10.fc20.i686 DEBUG util.py:264: error: unpacking of archive failed on file /var/lock: cpio: rename failed - Is a directory
If you haven't figured it out yet, replacing a dir with a symlink in rpm packaging is fraught with peril. there be dragons.
If any other package gets installed before filesystem.rpm, the directory will be created by that package, not filesystem.rpm. Here is how the stuff works in pretrans for the other links: http://pkgs.fedoraproject.org/cgit/filesystem.git/tree/filesystem.spec#n120
Yes, I know, it is pretty dangerous play... Still - the question is why the symlinks created in %post had wrong context. I'll move that to the pretrans section, it seems to be the safest way. Thanks for suggestion, Kay.
comment #21: if 'firstboot' is the answer, you are asking the wrong question.
(In reply to comment #28) > comment #21: if 'firstboot' is the answer, you are asking the wrong question. Right that doesn't work for minimal installs anyway either.
I am a bit naive about ordering of rpm install and script transactions under yum/anaconda. Would all %post scripts not be run after all packages have been installed? If so then couldn't "restorecon" be run in filesystem's %post if available without explicit requires(post)? I could be completely wrong here, but thought this might help?
No. %post scripts run as soon as that particular package's install transaction is done. https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Scriptlet_Ordering I'm not sure if %posttrans is what you're looking for, or if even that ultimately still only runs after one package is installed and before the next.
Requires(post) will not work here, it will make the dependency loop with uncertain behaviour. I'll try the %pretrans approach suggested by Kay - another option might be %triggerin on policycoreutils, so everytime policoreutils is installed/updated, restorecon on these two would be called.
I've done a bunch of F19 installs and live image composes in the last few days, and have not seen this problem (though I've seen plenty of others). I am not confident we should be rushing to 'fix' it.
Discussed at 2013-03-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-03-20/f19alpha-blocker-review-2.2013-03-20-16.00.log.txt . We agreed to delay any decision on this until more F19 testing is going on; as stated above I have not seen this, other testers so far have either been disabling selinux or not getting far enough to see this.
I still see this today doing a fresh F19 minimal netinst (from F18 netinst.iso: wish I had a working F19 netinst.iso). Symptoms: - console login is slow. - eth0 is down - some boot failure messages from systemd - /var/run has context var_t Can anyone else reproduce this? Should be easily reproducible: This is how I install: 0. Create guest in virt-manager (running on F18 x86_64 host) 1. select F18 netinst iso as boot iso 2. 5GB HD, 1GB RAM 3. Boot with repo=http://download.fedoraproject.org/pub/fedora/linux/development/19/x86_64/os/ (you may prefer to specific the mirror explicitly) 4. Select Minimal install, autopartitioning, etc 5. start install (set root passwd) 6. reboot into new minimal guest 7. run "ausearch -m avc -ts today" to see avc's
+ Also my install is in en_US.utf8 and Tokyo timezone. I just did another install to recheck: # ls -lZd /run /var/run drwxr-xr-x. root root system_u:object_r:var_run_t:s0 /run lrwxrwxrwx. root root system_u:object_r:var_t:s0 /var/run -> ../run but note that: # ls -lZd /run /var/run/ drwxr-xr-x. root root system_u:object_r:var_run_t:s0 /run/ drwxr-xr-x. root root system_u:object_r:var_run_t:s0 /run/run/ so please be careful when checking the context of the symlink.
Created attachment 715856 [details] "ausearch -m avc" right after booting into new install (console login takes about 20s)
selinux-policy package also has a restorecon /var/run in it.
(In reply to comment #38) > selinux-policy package also has a restorecon /var/run in it. But neither selinux-policy-3.12.1-23.fc19.noarch nor selinux-policy-targeted-3.12.1-23.fc19 do. Perhaps one of them should?
(In reply to comment #39) > But neither selinux-policy-3.12.1-23.fc19.noarch nor > selinux-policy-targeted-3.12.1-23.fc19 do. > Perhaps one of them should? Sorry seems I can't grep, I take that back: selinux-policy-targeted.noarch has /sbin/restorecon -e /run/media -R /root /var/log /var/run /etc/passwd* /etc/group* /etc/*shadow* 2> /dev/null;
Anyway for minimal install, filesystem is package 3 out of 238 and selinux-policy-targeted is 228 out of 238 installed. This is all very mysterious... I looked at the packages installed after selinux-policy-targeted but none of their scripts seem to touch /var/run AFAICT.
Indeed if I "yum reinstall selinux-policy-targeted" the context of /var/run changes to var_run_t.
(In reply to comment #42) > Indeed if I "yum reinstall selinux-policy-targeted" the context > of /var/run changes to var_run_t. which also fixes the long (20s+) login delay, brings up eth0, and allows login to run on other kernel vconsoles.
Is noone else really seeing this??
No I have seen others report this also. But the selinux-policy package usually clears it up.
Since there is no real security difference between reading var_run_t symlinks and var_t symlinks, I have changed the policy to allow domains that need to use /run content to read either. 7ce7dc0be7cb4f7b63cc2c9d8957b79eee0b7bb7 in git fixes this.
*** Bug 926909 has been marked as a duplicate of this bug. ***
(In reply to comment #46) > Since there is no real security difference between reading var_run_t > symlinks and var_t symlinks, I have changed the policy to allow domains that > need to use /run content to read either. Thanks - sounds good Actually I was wondering when it makes sense to differentiate the security context of a dir symlink and its target like this? (eg /path/to/symlink and /path/to/symlink/).
As far as I can tell selinux-policy-targeted %post is failing to set var_run_t for /var/run when installing so I am reassigning to selinux-policy. (At least for F18 selinux-policy-targeted %post did set the context correctly AFAICT.) Here is a diff of the relevant changes between the f18 and f19 %post scripts: --- selinux-policy-targeted-3.11.1-86.fc18.noarch.post 2013-03-27 11:23:31.309925412 +0900 +++ selinux-policy-targeted-3.12.1-23.fc19.noarch.post 2013-03-27 11:23:01.408948985 +0900 @@ -20,8 +20,8 @@ @@ -28,6 +28,6 @@ [ "${SELINUXTYPE}" == "targeted" ] && selinuxenabled && load_policy; if [ $1 -eq 1 ]; then - /sbin/restorecon -R /root /var/log /var/run 2> /dev/null; + /sbin/restorecon -R /root /var/log /run 2> /dev/null; else . /etc/selinux/config; @@ -35,7 +35,7 @@ /usr/sbin/selinuxenabled; if [ $? = 0 -a "${SELINUXTYPE}" = targeted -a -f ${FILE_CONTEXT}.pre ]; then /sbin/fixfiles -C ${FILE_CONTEXT}.pre restore 2> /dev/null; - /sbin/restorecon -e /run/media -R /root /var/log /var/run /etc/passwd* /etc/group* 2> /dev/null; rm -f ${FILE_CONTEXT}.pre; - restorecon -R /home/*/.cache /home/*/.config 2> /dev/null; -fi;fi;exit 0 +fi; +/sbin/restorecon -e /run/media -R /root /var/log /var/run /etc/passwd* /etc/group* /etc/*shadow* 2> /dev/null; +/sbin/restorecon -R /home/*/.cache /home/*/.config 2> /dev/null;fi;exit 0 So from my reading of selinux-policy-targeted-3.12.1-23.fc19.noarch.post it only does restorecon on /run when newly installing itself and does restorecon on /var/run updating.
Fixed in -24.fc19
Discussed at 2013-03-27 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-03-27/f19alpha-blocker-review-3.2013-03-27-16.01.log.txt . Many people do seem to be hitting this, so we're going to agree that I'm on crack, and accept this as a blocker per criterion "A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation. The firstboot utility must be able to create a working user account."
-24 should be in the repos now, setting to ON_QA. could people please re-test with -24 if plausible for your reproducer? I'll try and ensure -24 is in TC3 for reproducers relying on TC images.
Yes -24 fixes the problem for me - I meant to post that yesterday. I am keen also to retest installing with -25 which may have additional changes for this.
Also F19 Alpha TC3 minimal netinstall looks good. (/var/run is still var_t but that no longer invokes avc's - I still hope that -25 will have var_run_t though I don't claim to understand fully the underlying subtleties there.)
I think you can ignore my comments about -25. I am pretty sure the AVC's are fixed now. Moving to VERIFIED. It still seems to me though it would be more consistent to use only var_run_t security context for the /var/run symlink.
If it's fixed in -25, we can close it.