When I filed bug #342455, it didn't get copied to the list due to my not being subscribed, so I've forwarded it to you. 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 Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: tech-ctte: Ownership and permissions of device mapper block devices
- From: Roger Leigh <rleigh@debian.org>
- Date: Wed, 07 Dec 2005 17:29:08 +0000
- Message-id: <20051207172908.17712.84704.reportbug@hardknott.home.whinlatter.ukfsn.org>
Package: tech-ctte Severity: important Dear Technical Committee, Ownership and permissions of device mapper block devices -------------------------------------------------------- This concerns Debian bugs #329409, #316883 and #341901: #329409: group and perms wrong in /dev/mapper #316883: lvm2: creates device nodes as root:root 600, breaking amanda #341901: udev: Ownership and permissions incorrect for device-mapper devices and directories The package maintainer (Bastian Blank) does not agree with the bug submitters that this is a bug, and has tagged the bugs +wontfix. He has also rejected the patches I (and others) submitted to fix this. He has agreed to my submitting this to the Technical Committee. Summary ------- Disk block devices on the Debian system have historically been owned by root:disk with 0660 permissions (user and group readable and writable). This was also the case with LVM1, and also LVM2/device-mapper until earlier this year. The change was in the default device ownership and permissions of logical volume devices created under /dev/mapper by libdevmapper (in the devmapper package). This change made the LV devices different than all the other disk block devices on the Debian system. The effect of this is to break the use of the "disk" group. For example, the "backup" user is a member of the disk group, and uses the ability to read and write disk block devices in order to backup and restore backups, for example using dump/restore, tar, or a backup system such as amanda. It is not currently possible to back up or restore backups using e.g. amanda without 1) manually fixing up the ownership and permissions. This is fragile in the face of device name changes or device creation, and the changes are not preserved over a reboot, so a power cut breaks everything. I'm currently using a hacked-up init script to work around this, but it's far from perfect, and certainly not something our users should be forced to do. 2) using special udev rules, but I have yet to see any such rules in existence. The defaults are hard-coded in the devmapper package, and there is nothing the end user can do short of rebuilding the package by hand. This is simple stuff, and there is no reason it shouldn't just work if the defaults were changed back to root:disk, 0660. The discussion in #329409 and #316883 shows exactly what breaks, and both provide the same solution to the problem, which is even suggested by LVM upstream. Neither have any rationale given for the change by the maintainer. I have attached proposed patches to both bugs. #341901 is a duplicate I filed before finding the other two. Note that the udev package does not create any LVM device other than /dev/mapper; the other device creation is done purely by devmapper, and its behaviour is not configurable by an end-user. Note that this issue also affects the current stable release, sarge, so stable users cannot back up their systems. I regard this as a serious defect in the stable release, having production servers which can't be backed up without stupid hacks. If possible, I would like to get this fixed in time for the next sarge point release. Many thanks, Roger Leigh
--- End Message ---
Attachment:
signature.asc
Description: Digital signature