Bug 121007 - can't set selinux attributes on device files before they exist
Summary: can't set selinux attributes on device files before they exist
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Alasdair Kergon
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-04-16 03:12 UTC by Alexandre Oliva
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-05-26 17:18:16 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
strace output for vgchange -ay ext (3.33 KB, application/octet-stream)
2004-04-20 04:05 UTC, Alexandre Oliva
no flags Details

Description Alexandre Oliva 2004-04-16 03:12:50 UTC
It seems that the device mapper clean up from bug 119264 works, but I
suspect this is what may be causing warnings at boot time, when vgscan
(?) attempts to set the selinux attributes (permissive mode) before
the devices are created in the root filesystem.  They existed in the
initrd filesystem, that brought the VGs up since the root FS was in
LVM.  I think having root on LVM is the key to duplicate this problem
too.  I still haven't been able to get my non-root LVM filesystems
mounted on boot in enforcing mode; I suspect this is the reason.

Version-Release number of selected component (if applicable):
lvm2-2.00.12-1.0 device-mapper-1.00.14-1.0

Comment 1 Alasdair Kergon 2004-04-16 19:22:59 UTC
jeremy fixed this in lvm2-2.00.12-4

Comment 2 Alexandre Oliva 2004-04-19 05:11:06 UTC
I've got 2.00.14-1.1, and it's sitll not fixed.  I get the error both
when lvm is run from initrd and when it's run after root fs pivoting.
 Worst yet: lvm claims to *fail* when run from initrd.  Hmm...  Could
it be just because I have more than one volume group?  Unfortunately,
the messages are no longer logged in /var/log/boot.log, although I
still see similar messages logged there from before the latest lvm2
update.  Maybe the patch only arranged for the messages to not be
logged to boot.log, but they still make it to the screen?

Comment 3 Alexandre Oliva 2004-04-19 05:50:50 UTC
Ah, yes, it's lvm vgchange -a y that prints the error.  It seems to
attempt to set context before creating the device.  Testcase:

lvm vgchange -a n <some unused volume group>

lvm vgchange -a y <the same volume group>

The second command will print:
/dev/VG/LV: set_selinux_context failed: No such file or directory

Oddly, strace shows it *has* created the device-mapper node, as well
as the directory and symlink to it with the name it printed.  This is
very confusing.

Comment 4 Alasdair Kergon 2004-04-19 18:32:13 UTC
With/without selinux turned on? 
 
If that's the first error message printed, then the return code 
handling from is_selinux_enabled() is suspect.  Need to locate 
documentation for these functions, but guessing that if it returns 
0, it should still try to set filesystem xattr in case it gets 
enabled later?  (And return success, not failure with errno likely 
untouched?) 
 

Comment 5 Alasdair Kergon 2004-04-19 18:52:28 UTC
I'm struggling to reproduce this the straces I get look OK - can you 
send me your strace?   [and double-check that 'lvm version' is right 
- esp. the library version] 

Comment 6 Alexandre Oliva 2004-04-19 19:15:38 UTC
It doesn't matter whether selinux is enabled (permissive) or disabled
(selinux=0).  I haven't been able to boot in enforcing mode yet, and I
doubt it matters as early as initrd, where I first get the errors.

# lvm version
  LVM version:     2.00.14 (2004-04-16)
  Library version: 1.00.14-ioctl (2004-04-06)
  Driver version:  4.1.0


Comment 7 Alexandre Oliva 2004-04-20 04:05:09 UTC
Created attachment 99544 [details]
strace output for vgchange -ay ext

Comment 8 Alexandre Oliva 2004-04-20 04:06:57 UTC
The above was with selinux=0 in the boot command line.  I get the same
warning with selinux enabled in permissive mode, but I haven't saved
the strace output, and I'd rather not have to relabel the filesystem
after today's updates in order to duplicate it again, if I can help it.

Comment 9 Alasdair Kergon 2004-05-26 17:18:16 UTC
Fixed in 2.00.15-1.1.
Same fix applied to device-mapper.


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