Bug 166168
Summary: | /.autorelabel and autorelabel parameter require a reboot after relabeled | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | erikj | ||||||
Component: | initscripts | Assignee: | Bill Nottingham <notting> | ||||||
Status: | CLOSED RAWHIDE | QA Contact: | Brock Organ <borgan> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | rawhide | CC: | prarit, rvokal, sundaram | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | 8.16-1 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2005-09-27 20:37:28 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 163350 | ||||||||
Attachments: |
|
Description
erikj
2005-08-17 18:39:36 UTC
Thank you for the report. I saw users mentioning this on IRC but none seems to have reported this. Changing component to selinux-policy-targeted as that seemed more appropriate. Changing status to assigned Might useful to check if its reproducible on other arch's I could try to re-produce this on an x86 system tonight. My imaging system here isn't implemented for x86 but my idea is to install FC development on to the an x86 system and dump/restore it to another partition on the same machine. I'd then assume that booting the "copied" new partition should result in similar issues that I saw on ia64. If that sounds like a good approach, I'll look in to doing it tonight. Yes, I would like to see the AVC message you get when you can not login. My first experiment with x86 didn't duplicate the problem. I installed, then dumped the root to a backup root. I booted with the backup root... I didn't have to re-label anything in this case. I'm going to try a couple more things before I give up here. Ok, I duplicated this for x86. dump must be "too good" for duplicating this problem. However, many sites use System Imager which makes use of rsync. In my second test, I replicated the root device using rsync to to the backup root filesystem. I fixed the fstab up, then booted from it. The rsync command I think I used (from memory) was: rsync -avHvxz / /root2 The first boot on the backup root after this rsync command showed I could not log in. I booted from the backup root again, this time with the "autorelabel" option. It generated new labels and eventually the login prompt was back. I was still unable to log in to the console (vc1) just like I had trouble on ia64. Here is an attempt with ssh (matching what I saw on ia64): root@bammbamm's password: Last login: Wed Aug 17 18:03:20 2005 /bin/bash: Permission denied Connection to bammbamm closed. Just as in the ia64 case, after I rebooted a second time, everything was fine on the backup root. I went back in to the messages file and found these entries that seem to be of interest: Aug 17 18:03:18 bammbamm login(pam_unix)[2012]: session opened for user root by (uid=0) Aug 17 18:03:18 bammbamm login[2012]: Warning! Could not relabel /dev/tty1 with root:object_r:tty_device_t, not relabeling.Permission denied Aug 17 18:03:18 bammbamm -- root[2012]: ROOT LOGIN ON tty1 Aug 17 18:03:18 bammbamm login(pam_unix)[2012]: session closed for user root Aug 17 18:03:20 bammbamm login(pam_unix)[2263]: session opened for user root by (uid=0) Aug 17 18:03:20 bammbamm login[2263]: Warning! Could not relabel /dev/tty1 with root:object_r:tty_device_t, not relabeling.Permission denied Aug 17 18:03:20 bammbamm -- root[2263]: ROOT LOGIN ON tty1 Aug 17 18:03:20 bammbamm login(pam_unix)[2263]: session closed for user root Aug 17 18:09:45 bammbamm sshd(pam_unix)[2320]: session opened for user root by root(uid=0) Aug 17 18:10:57 bammbamm login(pam_unix)[2265]: session opened for user root by (uid=0) Aug 17 18:10:57 bammbamm login[2265]: Warning! Could not relabel /dev/tty1 with root:object_r:tty_device_t, not relabeling.Permission denied I don't know what you mean by the autorelabel option. There is no autorelabel option to the kernel that I am aware of. Creating a /root2/.autorelabel and booting with that root should cause the relabel to happen successfully. Are you seeing any AVC messages in /var/log/messages or /var/log/audit/audit.log? Dan Regarding autorelabel - you can pass it as a kernel option and it has the same affect as creating the file. From /etc/rc.d/rc.sysinit ($cmdline is set to /proc/cmdline earlier in the script): # Check to see if a full relabel is needed if [ -n "$SELINUX" ]; then if [ -f /.autorelabel ] || strstr "$cmdline" autorelabel ; then relabel_selinux fi Regarding the messages - I included the messages I thought were interesting. I can repeat the test and just save the full /var/log/messages and audit.log if you like. I think they're long gone now on that machine :) I never noticed that, thanks. Yes I could use the AVC messages from both those files or just attach them if they are small. Created attachment 118020 [details]
/var/log/messages from problem root
/var/log/messages from problem root, one more attachment to go.
Created attachment 118021 [details]
/var/log/audit/audit.log from problem root
Here is the audit.log from the problem root.
Please note: I didn't change the OS level, I just re-ran the test I had set up
before.
- I booted the primary root
- I rsycned it to /root2
- I fixed up /root2/etc/fstab to indicate it's proper location
- I copied /dev/null to /root2/var/log/messages and
/root2/var/log/audit/audit.log so they are zero length
- I touched /root2/.autorelabel
- I booted the root2 environment. It re-labeled.
- I was then unable to log in as I described in this bug.
- I booted the primary root again, and copied over the messages and audit.log
to attach to this bug.
So audit.log and messages represent a single boot of the rsynced root
environment. During that boot, the relabel would have happened, startup
occurred, then I was unable to log in as root due to permission denied on my
shell. Same with ssh.
I hope this has the information you need. Thank you.
Looks like login/init/initrc_exec_t are not labeled correctly. login is running as kernel_t, which means a transition never happened. When kernel_t runs /sbin/init (init_exec_t) it should transition to init_t, which eventually runs getty and login and should run those transitions. I Believe you still have a labeling problem. Is there some other information you need from me? I'd be happy to try a new test with a newer version of the development distro. I really only did the base install for this test. So the state of the system is the state the installer left it in. I'm no expert on this stuff though. Just let me know if you'd like me to do a new test. -Erik So this looks like autorelabel is happening after the login process is already started??? Maybe we should check the file context on the /sbin/init If it is wrong before the relabel, then we need to reboot after relabeling. Dan We are making this change in the next version of initscripts. This should already be fixed in 8.16-1. |