Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 159669 - lvcreate applies the wrong file context to newly-created logical volumes
Summary: lvcreate applies the wrong file context to newly-created logical volumes
Alias: None
Product: Fedora
Classification: Fedora
Component: device-mapper-obsolete
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Alasdair Kergon
QA Contact:
: 156956 (view as bug list)
Depends On:
Blocks: 158692
TreeView+ depends on / blocked
Reported: 2005-06-06 19:26 UTC by Nalin Dahyabhai
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-06-15 19:48:19 UTC

Attachments (Terms of Use)
patch to change the argument to set_selinux_context() (deleted)
2005-06-06 19:26 UTC, Nalin Dahyabhai
no flags Details | Diff

Description Nalin Dahyabhai 2005-06-06 19:26:27 UTC
Description of problem:
When I create a new logical volume, the tool applies the wrong SELinux file
context to the newly-created device node.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create a volume in an existing volume group (in my test, I'm using targeted
   # lvcreate -L2G -nLogVol20 VolGroup00
2. Observe the file context applied to /dev/mapper/VolGroup00-LogVol20 and its
symlink in /dev/VolGroup00:
   # ls -lZ /dev/mapper/VolGroup00-LogVol20 /dev/VolGroup00/LogVol20
3. Attempt to create an ext3 filesystem on the device:
   # mkfs.ext3 /dev/mapper/VolGroup00-LogVol20
Actual results:
# mkfs.ext3 /dev/mapper/VolGroup00-LogVol20
Could not stat /dev/mapper/VolGroup00-LogVol20 --- Permission denied
# restorecon /dev/mapper/VolGroup00-LogVol20
# mkfs.ext3 /dev/mapper/VolGroup00-LogVol20

Expected results:
mkfs should succeed without resetting the device's file context

Additional info:
The call to set_selinux_context() in lib/activate/fs.c seems to use the path of
the symlink to the device (which makes the volume group name a directory name),
and not the actual path to the device (which is under /dev/mapper).  Switching
this solves it, and avoids any need to guess at what the possible names for
volume groups might be to get the policy to include the right paths.

Comment 1 Nalin Dahyabhai 2005-06-06 19:26:27 UTC
Created attachment 115172 [details]
patch to change the argument to set_selinux_context()

Comment 2 Nalin Dahyabhai 2005-06-06 19:27:23 UTC
Oh, one more thing: I'm using selinux-policy-targeted-1.23.16-6.

Comment 3 Daniel Walsh 2005-06-08 15:04:30 UTC
Should I apply this patch?  And get it into Rawhide?


Comment 4 Alasdair Kergon 2005-06-08 15:27:21 UTC
No.   /dev/mapper is managed by libdevmapper not by lvm2.

Comment 5 Alasdair Kergon 2005-06-08 15:32:30 UTC
Is this yet another duplicate of 156862 ?

Comment 6 Nalin Dahyabhai 2005-06-08 18:25:19 UTC
It doesn't look like it bug #156862 looks like a boot-time bug which occurs when
the device nodes are created, and this is manifesting when the volume itself is
created, after the system has already been booted.

Comment 7 Alasdair Kergon 2005-06-08 18:42:44 UTC
Boot-time bug which affects everything in /dev afterwards.

Please upgrade the relevant packages and I expect the problem will go away.

Comment 8 Alasdair Kergon 2005-06-08 18:56:37 UTC
If it doesn't, then please supply details of what's going wrong with the
security contexts i.e. ls -Z; try restorecon etc. etc. and we can work out where
to transfer this bug.

Comment 9 Nalin Dahyabhai 2005-06-08 19:18:14 UTC
Contexts immediately after manual run of 'lvcreate':
  /dev/mapper/VolGroup00-LogVol00     root:object_r:device_t
  /dev/VolGroup00/LogVol00 (symlink)  root:object_r:device_t
'matchpathcon /dev/mapper/VolGroup00-LogVol00' suggests:
'matchpathcon /dev/VolGroup00/LogVol00' suggests:

Running mkfs.ext3 transitions to a domain which cannot access device_t (which is
why it fails), but which can access fixed_disk_device_t.  After using
'restorecon' to fix the label on /dev/mapper/VolGroup00-LogVol00, mkfs.ext3

Comment 10 Daniel Walsh 2005-06-08 19:52:08 UTC
This is clearly a bug in the matchpathcon call,  You are handing it the symbolic
link and asking for its context (device_t), then you are using this context to
create the block device.  If you just use the patch and hand matchpathcon the
context path of the block device, it will work correctly.


Comment 11 Alasdair Kergon 2005-06-08 19:53:27 UTC
libdevmapper runs both matchpathcon and lsetfilecon when the devices are created
so you need to work out why they aren't taking effect.

(1) confirm you're using libdevmapper 1.01.02
(2) turn on full debugging: add -vvvv to your lvcreate command line *and* set
'activation = 1' inside the 'log' section of lvm.conf

Look the lines of output where the device gets created and post them here.
You should see 4 lines like the following:

#mm/memlock.c:119       Unlocking memory
#mm/memlock.c:138         memlock_count dec to 0
#activate/fs.c:48       Creating directory /dev/vge1
#activate/fs.c:176       Linking /dev/vge1/lvol5 -> /dev/mapper/vge1-lvol5

together with a line saying:  
  "Setting SELinux context for /dev/mapper/vge1-lvol5"

Comment 12 Alasdair Kergon 2005-06-08 19:58:13 UTC
Re: comment 10 - that's a different matchpathcon.
Or has the behaviour of matchpathcon/lsetfilecon been changed recently?

lvm2 code has no right to touch anything in /dev/mapper - that's the job of the
device-mapper package.

Comment 21 Alasdair Kergon 2005-06-10 21:50:04 UTC
Well AJ has kindly generated a debug log for me instead, which shows immediately
that the selinux code is no longer getting compiled into libdevmapper:-(

This seems to be due to a bug introduced 2nd July last year while reorganising
the configuration script - its inclusion depends on a variable that never gets
set.  This would have appeared in device-mapper packages version 1.00.19 onwards.

Comment 22 Daniel Walsh 2005-06-11 03:29:52 UTC
You calls to matchpathcon are also wrong.  They should include the mode bits. 
So set_selinux_context should take a second parameter, mode.  This should then
be past to matchpathcon.

Comment 23 Alasdair Kergon 2005-06-13 13:28:20 UTC
The man page ought to describe what that parameter is for:-)
I had to look at the source code to understand how file permissions could
possibly affect the matching - and to find that they are reassuringly ignored
and that it's actually only the file type the function wants to know.

Fixes now in CVS for lvm2 and dm and will get included in next releases.

Comment 24 Daniel Walsh 2005-06-13 15:41:07 UTC
Man page does describe it


matchpathcon  matches  the specified pathname and mode against the file contexts
configuration and sets
       the security context con to refer to the resulting context. The caller
must free the returned  security
       context  con  using freecon when finished using it.  mode can be 0 to
disable mode matching, but should
       be provided whenever possible, as it may affect the matching.  Only the
file format bits (i.e. the file
       type)  of the mode are used.  If matchpathcon_init has not already been
called, then this function will
       call it upon its first invocation with a NULL path, defaulting to the
active file  contexts  configura-

Comment 25 Alasdair Kergon 2005-06-13 16:22:15 UTC
Good.  That's a newer version of the man page than I have.

Comment 26 Alasdair Kergon 2006-03-08 15:37:43 UTC
*** Bug 156956 has been marked as a duplicate of this bug. ***

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