Bug 166168 - /.autorelabel and autorelabel parameter require a reboot after relabeled
/.autorelabel and autorelabel parameter require a reboot after relabeled
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On:
Blocks: fedora-ia64
  Show dependency treegraph
 
Reported: 2005-08-17 14:39 EDT by Erik Jacobson
Modified: 2014-03-16 22:55 EDT (History)
3 users (show)

See Also:
Fixed In Version: 8.16-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-27 16:37:28 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)
/var/log/messages from problem root (32.56 KB, text/plain)
2005-08-23 16:12 EDT, Erik Jacobson
no flags Details
/var/log/audit/audit.log from problem root (3.90 KB, text/plain)
2005-08-23 16:17 EDT, Erik Jacobson
no flags Details

  None (edit)
Description Erik Jacobson 2005-08-17 14:39:36 EDT
This was observed in the ia64 development tree.  Some RPM versions:

[root@minime1 ~]# rpm -qa | grep selinux
selinux-policy-targeted-1.25.4-2
libselinux-devel-1.25.2-1
libselinux-1.25.2-1
[root@minime1 ~]# rpm -q kernel initscripts
kernel-2.6.12-1.1485_FC5
initscripts-8.11.1-1

As far as I could tell from reading and documentation, if you boot with
"autorelabel" or touch "/.autorelabel"... the next boot of the system should
relabel.  This works fine.

However, after the system is re-labeled, it continues with the boot up process.
When I get the login prompt, I'm unable to log in (shell permission denied).  If
I reset the machine, the _next_ boot works fine.

In other words, it seems like the relabeling doesn't fix things until yet
another reboot is done.

Here is how I produced this:
 - I installed a ia64 development system
 - I augmented the install with system-config-packages (because only 
   minimal installs can happen at the moment)
 - I use a custom system imager setup (mainly rsync under the covers) to
   create a duplicate of the root drive and populate a new system with it.
 - At that point, you have to re-label the files on the new target system.
 - Notice that even if you boot with autorelabel or /.autorelabel, you still
   can't log in until you reboot one more time.

Please help this bug find the right group; I wasn't sure.  Also, I set it as
ia64 specific but I haven't tested the development tree for x86.  I'd be 
happy to do some new tests.
Comment 1 Rahul Sundaram 2005-08-17 14:51:15 EDT
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
Comment 2 Erik Jacobson 2005-08-17 15:37:28 EDT
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.
Comment 3 Daniel Walsh 2005-08-17 15:45:01 EDT
Yes, I would like to see the AVC message you get when you can not login.
Comment 4 Erik Jacobson 2005-08-17 18:23:20 EDT
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.
Comment 5 Erik Jacobson 2005-08-17 19:17:45 EDT
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
Comment 6 Daniel Walsh 2005-08-19 14:02:51 EDT
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  
Comment 7 Erik Jacobson 2005-08-19 14:12:53 EDT
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 :)
Comment 8 Daniel Walsh 2005-08-22 09:14:34 EDT
I never noticed that, thanks.  Yes I could use the AVC messages from both those
files or just attach them if they are small.
Comment 9 Erik Jacobson 2005-08-23 16:12:57 EDT
Created attachment 118020 [details]
/var/log/messages from problem root

/var/log/messages from problem root, one more attachment to go.
Comment 10 Erik Jacobson 2005-08-23 16:17:17 EDT
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.
Comment 11 Daniel Walsh 2005-08-25 09:02:30 EDT
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.
Comment 12 Erik Jacobson 2005-08-25 15:37:29 EDT
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
Comment 13 Daniel Walsh 2005-09-21 14:52:00 EDT
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
Comment 14 Daniel Walsh 2005-09-27 15:49:59 EDT
We are making this change in the next version of initscripts.
Comment 15 Bill Nottingham 2005-09-27 16:37:28 EDT
This should already be fixed in 8.16-1.

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