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.
Created attachment 115172 [details] patch to change the argument to set_selinux_context()
Oh, one more thing: I'm using selinux-policy-targeted-1.23.16-6.
Should I apply this patch? And get it into Rawhide? Dan
No. /dev/mapper is managed by libdevmapper not by lvm2.
Is this yet another duplicate of 156862 ?
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.
Boot-time bug which affects everything in /dev afterwards. Please upgrade the relevant packages and I expect the problem will go away.
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.
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.
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
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"
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.
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.
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.
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.
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.
Good. That's a newer version of the man page than I have.
*** Bug 156956 has been marked as a duplicate of this bug. ***