[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

tech-ctte: Ownership and permissions of device mapper block devices

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.


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 ---
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.


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

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

Reply to: