Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bastian Blank <waldi@debian.org> writes:
> On Sat, Dec 17, 2005 at 03:09:37PM +0000, Roger Leigh wrote:
>> Bastian Blank <waldi@debian.org> writes:
>>
>> > On Sat, Dec 17, 2005 at 12:41:17PM +0000, Roger Leigh wrote:
>> >> > Which procedure? You seem to know something I don't know. ("Overwrite"
>> >> > means in my context: chmod of static devices or a MODE setting in the
>> >> > udev config)
>> >> A chown/chmod of the device is not scalable or practical.
>> >
>> > You recreate the complete /dev?
>>
>> lvcreate/vgchange and related commands will create the devices with
>> the default ownership, and hence require *manual* correction after
>> their creation. Thus chown/chmod are not practical for anything but
>> tiny and unchanging installations.
>
> Hu? lvcreate don't create static devices.
It causes a device node to be created. So does vgchange, and a number
of other commands. As an example:
rleigh@hardknott:~$ ls -l /dev/mapper/hda_vg-swap*
brw-rw---- 1 root disk 254, 0 2005-12-23 12:18 /dev/mapper/hda_vg-swap0
brw-rw---- 1 root disk 254, 1 2005-12-23 12:18 /dev/mapper/hda_vg-swap1
brw-rw---- 1 root disk 254, 2 2005-12-23 20:52 /dev/mapper/hda_vg-swap2
We will now deactivate an LV:
rleigh@hardknott:~$ sudo lvchange -a n /dev/hda_vg/swap2
rleigh@hardknott:~$ ls -l /dev/mapper/hda_vg-swap*
brw-rw---- 1 root disk 254, 0 2005-12-23 12:18 /dev/mapper/hda_vg-swap0
brw-rw---- 1 root disk 254, 1 2005-12-23 12:18 /dev/mapper/hda_vg-swap1
Notice the device node was deleted. Now, we will reactivate the LV:
rleigh@hardknott:~$ sudo lvchange -a y /dev/hda_vg/swap2
rleigh@hardknott:~$ ls -l /dev/mapper/hda_vg-swap*
brw-rw---- 1 root disk 254, 0 2005-12-23 12:18 /dev/mapper/hda_vg-swap0
brw-rw---- 1 root disk 254, 1 2005-12-23 12:18 /dev/mapper/hda_vg-swap1
brw-rw---- 1 root disk 254, 2 2005-12-23 20:53 /dev/mapper/hda_vg-swap2
Notice the LV has been recreated. Also notice the permissions and
ownership. They are root:disk, 0660. That's because I rebuilt the
devmapper package using my/Bdale's patch.
Without the patch, whenever a device node is created, the ownership
and permissions are root:root, 0600, which is incorrect.
>> > SUBSYSTEM=="block", MODE="0600"
>>
>> That changes the default permissions for block devices, but this is
>> not what I meant.
>>
>> How do I get device-mapper devices to be created by udev, along with
>> the related symlinks? The rule you suggest above does not in any way
>> affect the *device-mapper* device permissions or ownership, which is
>> the problem at hand:
>
> KERNEL=="dm-[0-9]*", ACTION=="add", PROGRAM="/sbin/dmsetup info -c --noopencount --noheadings -o name -j %M -m %m", SYMLINK="disk/by-name/%c"
>
> as shipped by suse.
Currently, Debian does not supply those rules anywhere. I would like
it to do something like this, however. If you could work with the
udev maintainer to implement this, taking devmapper completely out of
the loop for device creation, I would be very grateful. However, even
this is implemented, the devmapper permissions still need fixing for
people who do not use udev.
>> Also, you have not addressed the case where udev is not in use: the
>> ownership and permissions are still wrong.
>
> The settings are a secure default.
That is not at issue--I agree it's secure. What is at issue is that
it's completely different to what every other disk block device uses.
The decision about the ownership and permissions is not yours (or
mine) to make: it is a distribution-wide default. If you want it
changed, take it up on debian-policy or with the makedev maintainer.
The whole reason people use distributions such as Debian is that the
packages are supposedly well-integrated with each other, and work with
minimal extra configuration because the maintainers have gone to the
effort to make sure they work well together. You have broken that
integration, and worse, it's not possible to fix properly unless one
rebuilds the the packages or introduces crude, fragile and insecure
hacks.
I expect a Debian developer to uphold high standards, both in making
sure their packages are technically excellent, and in making sure they
integrate with the rest of the system. You have failed on the second
count, and I am sorely disappointed with your attitude to this
problem, particularly in failing to appreciate why it is a serious
problem and why a consistent and integrated system are important to
Debian. I do expect a higher standard from a package maintainer.
> Anyway, what are the problems with a default of 666? It fixes any of the
> problems.
*Please* take the issue seriously. Just what does a stupid comment
like that achieve. There are many production systems completely
dependent upon devmapper for their functioning, and this needs fixing.
It's even broken in stable, and I am *not* happy.
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>
iD8DBQFDrGkGVcFcaSW/uEgRAgnhAJ4p7fhZp+V05iQTNgSCoHqhKVHsrQCdHRAa
ENU9vli9VG0sb0/CKx/yMzk=
=66Mo
-----END PGP SIGNATURE-----
Reply to: