Bug 429857 - Root inode of ext4dev root filesystem does not get selinux label
Root inode of ext4dev root filesystem does not get selinux label
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-23 09:45 EST by Eric Sandeen
Modified: 2008-07-25 10:54 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-30 10:03:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eric Sandeen 2008-01-23 09:45:27 EST
I'm not sure this is an anaconda bug, but need to file it somewhere so it
doesn't get lost, feel free to move as appropriate.

When installing rawhide onto ext4dev, the root inode does not get an selinux
security context label.  This ultimately causes the system boot to fail
post-installation.  Simply running restorecon on / fixes it up.

I haven't yet sorted out *what* should be labeling / during install; perhaps the
recent "fixfiles" fix will fix it.  I'll test that today.
Comment 1 Daniel Walsh 2008-01-23 16:43:34 EST
Yes I think the fixed fixfiles should fix this problem
Comment 2 Chris Lumens 2008-01-28 15:31:00 EST
Putting in MODIFIED on the basis of comment #1.
Comment 3 Eric Sandeen 2008-01-28 17:29:42 EST
Something else is still wrong... at the end of the install, ls -Zd /mnt/sysimage
shows root_t... but after the box reboots, it's file_t again.  It appears it's
not getting flushed.

ls -Zd /mnt/sysimage/boot (separate filesystem...) shows boot_t before & after.

I notice that at the end of the install, /mnt/sysimage is still held busy via
files in /mnt/sysimage/var/lib/rpm... perhaps it's not getting unmounted
cleanly?  This may be a kernel problem unique to ext4 I suppose; maybe
journaling and/or flushing problems....
Comment 4 Eric Sandeen 2008-01-29 00:29:38 EST
Funky, the root attr is there but it's not reported/returned:

[root@magnesium tmp]# mount | grep sda9
/dev/sda9 on /mnt type ext4dev (rw)
[root@magnesium tmp]# ls -Zd /mnt
drwxr-xr-x  root root system_u:object_r:file_t:s0      /mnt (unlabeled)
[root@magnesium tmp]# getfattr -d -m "^security\\." /mnt
[root@magnesium tmp]# <nada>
[root@magnesium tmp]# debugfs /dev/sda9
debugfs 1.40.4 (31-Dec-2007)
debugfs:  stat .
Inode: 2   Type: directory    Mode:  0755   Flags: 0x0   Generation: 0
User:     0   Group:     0   Size: 4096
File ACL: 0    Directory ACL: 0
Links: 23   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x479ea01f -- Mon Jan 28 21:40:15 2008
atime: 0x479ea020 -- Mon Jan 28 21:40:16 2008
mtime: 0x479ea01f -- Mon Jan 28 21:40:15 2008
Size of extra inode fields: 28
Extended attributes stored in inode body: 
  selinux = "73 79 73 74 65 6d 5f 75 3a 6f 62 6a 65 63 74 5f 72 3a 72 6f 6f 74
5f 74 3a 73 30 00 " (28)
BLOCKS:
(0):816
TOTAL: 1

(that nice hex string should be printed (that's another bug...) - it's
"system_u:object_r:root_t:s0" so looks like the attr is there, but we're not
fetching/reporting it.  Grr.  Well, will fix this up tomorrow I hope.
Comment 5 Eric Sandeen 2008-01-29 14:36:20 EST
Found it.

Can fix it a couple ways; will go to the ext4 list & see which people like best.

-Eric
Comment 6 Eric Sandeen 2008-01-30 10:03:12 EST
Patch is in the upstream ext4 git tree; will be heading to linus shortly.
Applied to rawhide kernel.

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