Bug 159669 - lvcreate applies the wrong file context to newly-created logical volumes
lvcreate applies the wrong file context to newly-created logical volumes
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: device-mapper-obsolete (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alasdair Kergon
:
: 156956 (view as bug list)
Depends On:
Blocks: 158692
  Show dependency treegraph
 
Reported: 2005-06-06 15:26 EDT by Nalin Dahyabhai
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-15 15:48:19 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)
patch to change the argument to set_selinux_context() (358 bytes, patch)
2005-06-06 15:26 EDT, Nalin Dahyabhai
no flags Details | Diff

  None (edit)
Description Nalin Dahyabhai 2005-06-06 15:26:27 EDT
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):
2.01.08-2.1

How reproducible:
Always

Steps to Reproduce:
1. Create a volume in an existing volume group (in my test, I'm using targeted
policy):
   # 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
(succeeds)

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 15:26:27 EDT
Created attachment 115172 [details]
patch to change the argument to set_selinux_context()
Comment 2 Nalin Dahyabhai 2005-06-06 15:27:23 EDT
Oh, one more thing: I'm using selinux-policy-targeted-1.23.16-6.
Comment 3 Daniel Walsh 2005-06-08 11:04:30 EDT
Should I apply this patch?  And get it into Rawhide?


Dan
Comment 4 Alasdair Kergon 2005-06-08 11:27:21 EDT
No.   /dev/mapper is managed by libdevmapper not by lvm2.
Comment 5 Alasdair Kergon 2005-06-08 11:32:30 EDT
Is this yet another duplicate of 156862 ?
Comment 6 Nalin Dahyabhai 2005-06-08 14:25:19 EDT
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 14:42:44 EDT
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 14:56:37 EDT
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 15:18:14 EDT
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:
  system_u:object_r:fixed_disk_device_t
'matchpathcon /dev/VolGroup00/LogVol00' suggests:
  system_u:object_r:device_t

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
succeeds.
Comment 10 Daniel Walsh 2005-06-08 15:52:08 EDT
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.

Dan
Comment 11 Alasdair Kergon 2005-06-08 15:53:27 EDT
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 15:58:13 EDT
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 17:50:04 EDT
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-10 23:29:52 EDT
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 09:28:20 EDT
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 11:41:07 EDT
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-
       tion.
Comment 25 Alasdair Kergon 2005-06-13 12:22:15 EDT
Good.  That's a newer version of the man page than I have.
Comment 26 Alasdair Kergon 2006-03-08 10:37:43 EST
*** 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.