Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
Bastian Blank writes (Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices): 4) the two attached patches: - devmapper: export functions to set permissions - lvm2: add a config entry to overwrite the permissions for new devices I just try to get it acked by upstream and search for some other people to test them, if this solution is acceptable. Thanks for your patches. I don't have time right know to look at the technicalities in detail. Do we have all of the relevant Debian LVM and devmapper reading this thread ? If not we should make sure that they look at it. I'm also encouraged by the fact that you've written patches at all; this suggests that you do seem to be taking the matter seriously, although your comments don't always give that impression. If you're finding it difficult to write long and coherent explanations in English please feel free to write in German. My German is probably good enough to understand your points if you spell them out clearly (and at length!) and I would be happy to try to act as an intermediary. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
On Tue, Jan 03, 2006 at 03:26:30PM +, Ian Jackson wrote: Thanks for your patches. I don't have time right know to look at the technicalities in detail. I did not get any response about the patches from upstream yet. Do we have all of the relevant Debian LVM and devmapper reading this thread ? If not we should make sure that they look at it. There are 5 reverse dependencies to devmapper: lvm2, lilo, multipath-tools, dmraid, cryptsetup. I can speak for lvm2 and multipath-tools. lilo is not affected by this problem, as it only uses them to find block numbers. The remaining packages are dmraid and cryptsetup. I don't think they got knowledge about that thread. Can you post a pointer? I'm also encouraged by the fact that you've written patches at all; this suggests that you do seem to be taking the matter seriously, I developed the idea for this fix some months ago, but never found the time to implement it. So I should have refrained from tagging the bugs wontfix. The lvm2 patch lacks one additional functionality where I don't know if it is possible to implement: I want to make the permissions dependent on the metadata tags or just record them in the metadata. although your comments don't always give that impression. This may be a sign for beeing overloaded. I just try to finish my prediploma and the mathematics course needs a lot of work. If you're finding it difficult to write long and coherent explanations in English please feel free to write in German. My German is probably good enough to understand your points if you spell them out clearly (and at length!) and I would be happy to try to act as an intermediary. Thank you for the offer. Bastian -- No one may kill a man. Not for any purpose. It cannot be condoned. -- Kirk, Spock's Brain, stardate 5431.6 signature.asc Description: Digital signature
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
On 12/23/05, Bastian Blank [EMAIL PROTECTED] wrote: Anyway, what are the problems with a default of 666? It fixes any of the problems. Is this a serious question? Access to group disk can be easily controlled by the system administrator. On some systems, only root has this access, on other systems other ids also have this access. It's possible that all accounts will have this access, but that's extremely rare. That's not true for other -- everyone has access read and write access to things with 666 permissions. Do you need this explained further? -- Raul
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
On Sat, Dec 17, 2005 at 03:09:37PM +, Roger Leigh wrote: Bastian Blank [EMAIL PROTECTED] writes: On Sat, Dec 17, 2005 at 12:41:17PM +, 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. a new LV, the permissions will be wrong. If I run vgchange, the permissions will be wrong. This is not a solution. And I don't speak about libdevmapper managed device. Please could you clarify? What *are* you speaking about. I'm referring to the fact that when I create or change an LVM LV, I have to manually correct the permissions (on both static and udev managed systems). Lets quote myself: | means in my context: chmod of static devices or a MODE setting in the | udev config) This does not qualify dm devices. 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. 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. Anyway, what are the problems with a default of 666? It fixes any of the problems. Bastian -- The heart is not a logical organ. -- Dr. Janet Wallace, The Deadly Years, stardate 3479.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
On Tue, Dec 20, 2005 at 12:35:00AM -0500, Raul Miller wrote: I'm trying to ask why you are unwilling to have devmapper disks provide a default of root.disk 660? Why can't you allow that to be the default? You can always make permissions less strict, you can't make them more strict, as the checks are only done on open. Is there some reason you can't have implement your personally preferred policy of root.root 600 on just your own system? Is there some reason for projecting your personal policies incompletely onto an arbitrary subset of debian's users? Hu? 10 people are an arbitrary subset? Is there something about this question I'm asking which doesn't make sense to you? Yes, there seems to be one tool (named amanda) which uses the devices directly without the posix compilant capability CAP_DAC_READ which is there for backup reasons. You seem to be asserting: a malicious person who handles backups could use the disk group to obtain root access, so you should force backup programs to run as root. But that does not seem to be a reasonable position: I never said, that they should run as root. (1) There are risks other than a malicious people -- by ensuring backup programs don't have to run as root, we minimize the risks that such programs will do something they weren't designed to do. Many tools have additional checks to never do anything as root. Now you have just another user with the same rights. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bastian Blank [EMAIL PROTECTED] writes: On Sat, Dec 17, 2005 at 03:09:37PM +, Roger Leigh wrote: Bastian Blank [EMAIL PROTECTED] writes: On Sat, Dec 17, 2005 at 12:41:17PM +, 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: [EMAIL PROTECTED]:~$ 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: [EMAIL PROTECTED]:~$ sudo lvchange -a n /dev/hda_vg/swap2 [EMAIL PROTECTED]:~$ 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: [EMAIL PROTECTED]:~$ sudo lvchange -a y /dev/hda_vg/swap2 [EMAIL PROTECTED]:~$ 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/Linuxhttp://www.debian.org/ GPG Public Key:
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bastian Blank [EMAIL PROTECTED] writes: On Tue, Dec 20, 2005 at 12:35:00AM -0500, Raul Miller wrote: Is there some reason you can't have implement your personally preferred policy of root.root 600 on just your own system? Is there some reason for projecting your personal policies incompletely onto an arbitrary subset of debian's users? Hu? 10 people are an arbitrary subset? All LVM2 users are forced to use your incompatible defaults. Is there something about this question I'm asking which doesn't make sense to you? Yes, there seems to be one tool (named amanda) which uses the devices directly without the posix compilant capability CAP_DAC_READ which is there for backup reasons. Amanda is just one example. The fact that there are other users of the disk group and alternative ways of granting permissions are not really relevent. The fact that it is an incompatibility with the rest of the Debian system *is* relevant. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://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/ iD8DBQFDrGnqVcFcaSW/uEgRAts2AJ4tdJfFeetxNwyMwqw4YLeLs1XP7wCbBuQA YaPcnfO9gTf0glMrpa01bnk= =8LR6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
* Bastian Blank ([EMAIL PROTECTED]) wrote: Is there some reason you can't have implement your personally preferred policy of root.root 600 on just your own system? Is there some reason for projecting your personal policies incompletely onto an arbitrary subset of debian's users? Hu? 10 people are an arbitrary subset? I expect it's more than 10. I know that I'm one of the folks following along here and trying to understand why you can't manage to do what every other block-device-creating maintainer does. I never said, that they should run as root. [...] Many tools have additional checks to never do anything as root. Now you have just another user with the same rights. You're contradicting yourself here. Disk block devices have a specific, standard permission setup in Debian. Packages which create disk block devices need to follow this standard. There really isn't anything else to discuss. I don't particularly care that you don't like amanda, you're wrong to think that making it be 600 is any more secure by default, no one seems to be jumping to bolster your claims, and depending on a check to make sure one isn't running as root to enforce security sounds like a rather serious problem to begin with. Consider that there are *many* other users whom it would be bad to run as mistakenly (someone in the shadow group? Or the Postgres group on your primary database server?). Thanks, Stephen signature.asc Description: Digital signature
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
On Sun, Dec 11, 2005 at 04:47:26PM -0500, Raul Miller wrote:
Here's what I currently see suggested:
1) change devmapper defaults -- patch rejected, no reason given
2) explicitly use udev -- problem, this doesn't work for 2.4 kernels
(2.4 used devfs)
3) avoid using devmapper (but this is not a solution)
4) the two attached patches:
- devmapper: export functions to set permissions
- lvm2: add a config entry to overwrite the permissions for new
devices
I just try to get it acked by upstream and search for some other people
to test them, if this solution is acceptable.
Bastian
--
A Vulcan can no sooner be disloyal than he can exist without breathing.
-- Kirk, The Menagerie, stardate 3012.4
=== debian/changelog
==
--- debian/changelog(revision 206)
+++ debian/changelog(local)
@@ -1,3 +1,9 @@
+devmapper (2:1.02.02-1.0permission.1) UNRELEASED; urgency=low
+
+ * Make device mode modificable.
+
+ -- Bastian Blank [EMAIL PROTECTED] Fri, 23 Dec 2005 20:03:04 +0100
+
devmapper (2:1.02.02-1) unstable; urgency=low
* New upstram version.
=== debian/rules
==
--- debian/rules(revision 206)
+++ debian/rules(local)
@@ -117,7 +117,7 @@
dh_link -a
dh_compress -a
dh_fixperms -a
- dh_makeshlibs -a
+ dh_makeshlibs -a -V 'libdevmapper1.02 (= 2:1.02.02-1.0permission.1)'
dh_installdeb -a
dh_shlibdeps -a
dh_gencontrol -a
=== dmsetup/dmsetup.c
==
--- dmsetup/dmsetup.c (revision 206)
+++ dmsetup/dmsetup.c (local)
@@ -88,6 +88,9 @@
EXEC_ARG,
MAJOR_ARG,
MINOR_ARG,
+ UID_ARG,
+ GID_ARG,
+ MODE_ARG,
NOHEADINGS_ARG,
NOLOCKFS_ARG,
NOOPENCOUNT_ARG,
@@ -390,6 +393,15 @@
if (_switches[MINOR_ARG] !dm_task_set_minor(dmt, _values[MINOR_ARG]))
goto out;
+ if (_switches[UID_ARG] !_dm_task_set_uid(dmt, _values[UID_ARG]))
+ goto out;
+
+ if (_switches[GID_ARG] !_dm_task_set_gid(dmt, _values[GID_ARG]))
+ goto out;
+
+ if (_switches[MODE_ARG] !_dm_task_set_mode(dmt, _values[MODE_ARG]))
+ goto out;
+
if (_switches[NOOPENCOUNT_ARG] !dm_task_no_open_count(dmt))
goto out;
@@ -1292,7 +1304,8 @@
static struct command _commands[] = {
{create, dev_name [-j|--major major -m|--minor minor]\n
- \t [-u|uuid uuid] [--notable] [table_file],
+ \t [-u|uuid uuid] [-U|--uid uid] [-G|--gid
gid]\n
+ \t [-M|--mode mode] [--notable] [table_file],
1, 2, _create},
{remove, device, 0, 1, _remove},
{remove_all, , 0, 0, _remove_all},
@@ -1420,6 +1433,9 @@
{exec, 1, ind, EXEC_ARG},
{major, 1, ind, MAJOR_ARG},
{minor, 1, ind, MINOR_ARG},
+ {uid, 1, ind, UID_ARG},
+ {gid, 1, ind, GID_ARG},
+ {mode, 1, ind, MODE_ARG},
{noheadings, 0, ind, NOHEADINGS_ARG},
{nolockfs, 0, ind, NOLOCKFS_ARG},
{noopencount, 0, ind, NOOPENCOUNT_ARG},
@@ -1478,10 +1494,14 @@
optarg = 0;
optind = OPTIND_INIT;
- while ((ind = -1, c = GETOPTLONG_FN(*argc, *argv, cCj:m:no:ru:v,
+ while ((ind = -1, c = GETOPTLONG_FN(*argc, *argv, cCj:G:m:M:no:ru:U:v,
long_options, NULL)) != -1) {
if (c == 'c' || c == 'C' || ind == COLS_ARG)
_switches[COLS_ARG]++;
+ if (c == 'G' || ind == GID_ARG) {
+ _switches[GID_ARG]++;
+ _values[GID_ARG] = strtol(optarg, NULL, 10);
+ }
if (c == 'r' || ind == READ_ONLY)
_switches[READ_ONLY]++;
if (c == 'j' || ind == MAJOR_ARG) {
@@ -1492,6 +1512,10 @@
_switches[MINOR_ARG]++;
_values[MINOR_ARG] = atoi(optarg);
}
+ if (c == 'M' || ind == MODE_ARG) {
+ _switches[MODE_ARG]++;
+ _values[MODE_ARG] = strtol(optarg, NULL, 8);
+ }
if (c == 'n' || ind == NOTABLE_ARG)
_switches[NOTABLE_ARG]++;
if (c == 'o' || ind == OPTIONS_ARG) {
@@ -1504,6 +1528,10 @@
_switches[UUID_ARG]++;
_uuid = optarg;
}
+ if (c == 'U' || ind == UID_ARG) {
+ _switches[UID_ARG]++;
+ _values[UID_ARG] = strtol(optarg, NULL, 10);
+ }
if ((ind == EXEC_ARG)) {
_switches[EXEC_ARG]++;
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
On 12/17/05, Bastian Blank [EMAIL PROTECTED] wrote: On Fri, Dec 16, 2005 at 02:43:29PM -0500, Raul Miller wrote: On 12/16/05, Bastian Blank [EMAIL PROTECTED] wrote: On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote: Are you saying that the current default permissions on (eg) /dev/hda* are insecure and therefore wrong ? Yes, I overwrite them on my machines. And what is your reason for being unwilling to use the same procedure on devmapper disks? 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) I'm trying to ask why you are unwilling to have devmapper disks provide a default of root.disk 660? Why can't you allow that to be the default? Is there some reason you can't have implement your personally preferred policy of root.root 600 on just your own system? Is there some reason for projecting your personal policies incompletely onto an arbitrary subset of debian's users? Is there something about this question I'm asking which doesn't make sense to you? Personally, I'm using a system where the only way to obtain root access is to log in as root -- there's no privileges gained through suid binaries. Err? Write access to the device of a mounted filesystem is a way to gain root if you don't disable several options. Quite a bit of stuff doesn't work the way you might normally expect, on that particular system. Anyways, good security means that the system works the way the person responsible for the system think it's supposed to be working. What you've done here introduces surprises and thus would tend to degrade the security of debian users's systems (not directly but by requiring that some people introduce ad-hoc and perhaps ill-considered workarounds). You seem to be asserting: a malicious person who handles backups could use the disk group to obtain root access, so you should force backup programs to run as root. But that does not seem to be a reasonable position: (1) There are risks other than a malicious people -- by ensuring backup programs don't have to run as root, we minimize the risks that such programs will do something they weren't designed to do. (2) A malicious person with physical access to the system can compromise it in a variety of ways (boot with init=/bin/sh, replace the OS, add monitoring hardware to the keyboard or the display, put a logic sniffer on the bus, etc. etc.) As things currently stand: (A) The risk you're protecting against is not defeated by the measures you propose. (B) The measures you propose have not been accepted (or even discussed) in the debian community at large. (C) You've defeated some measures which make debian systems more robust. (D) You've clearly stated that you do not require that devmapper use these defaults to implement your security policy. I don't have any right to object to how you maintain your own personal systems, but what you're inflicting on debian as a whole does not seem to make much sense. -- Raul
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
On Fri, Dec 16, 2005 at 02:43:29PM -0500, Raul Miller wrote: On 12/16/05, Bastian Blank [EMAIL PROTECTED] wrote: On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote: Are you saying that the current default permissions on (eg) /dev/hda* are insecure and therefore wrong ? Yes, I overwrite them on my machines. And what is your reason for being unwilling to use the same procedure on devmapper disks? 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) Personally, I'm using a system where the only way to obtain root access is to log in as root -- there's no privileges gained through suid binaries. Err? Write access to the device of a mounted filesystem is a way to gain root if you don't disable several options. Bastian -- Beauty is transitory. Beauty survives. -- Spock and Kirk, That Which Survives, stardate unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bastian Blank [EMAIL PROTECTED] writes: On Fri, Dec 16, 2005 at 02:43:29PM -0500, Raul Miller wrote: On 12/16/05, Bastian Blank [EMAIL PROTECTED] wrote: On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote: Are you saying that the current default permissions on (eg) /dev/hda* are insecure and therefore wrong ? Yes, I overwrite them on my machines. And what is your reason for being unwilling to use the same procedure on devmapper disks? 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. If I create a new LV, the permissions will be wrong. If I run vgchange, the permissions will be wrong. This is not a solution. What if the user isn't using udev? Do you have any example udev rules to do what you suggest? Since udev, by default, does not get involved with creation of any device mapper device other than /dev/mapper/control, the default ownership and permissions come directly from the devmapper configure. This is what needs fixing first. I would, however, like to see udev become involved to allow this sort of customisation, but you will need to work out the details with Marco d'Itri, the udev maintainer. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://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/ iD8DBQFDpAdrVcFcaSW/uEgRAmksAJ4zlh9pY1EPkdvty/vkzMq9fAt5IACfY8Eh djQzEmpgIZWnluOxmlVHT5c= =xkhb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bastian Blank [EMAIL PROTECTED] writes:
On Tue, Dec 13, 2005 at 03:55:01PM +, Ian Jackson wrote:
1) change devmapper defaults -- patch rejected, no reason given
Certainly I agree that the defaults should be changed.
At least in my point of view, a default is something which can be
changed easily, maybe in a config file. In this case, it is no default,
it is the value which anything gets.
No. A default is what happens in the *absence* of any configuration,
i.e. what is compiled into the devmapper packages.
$ dict default
- From WordNet (r) 2.0 (August 2003) [wn]:
default
4: an option that is selected automatically unless an
alternative is specified [syn: {default option}]
I've also seen the suggestion that we should have a explicit
technical policy that block devices should default to having 660
permissions with owner root and group disk. I don't have any
objections to such a policy, but I don't see that solving this
problem should wait on the adoption of this policy.
Quite so. (Modulo my comments about the exact mode, above.)
This breaks anything which wants to use group cdrom for cdrom access
without manual intervention.
No one suggested that this would apply to CD-ROM devices. They aren't
disk block devices.
Finally, I don't see any reasoning given for things being the way they are
currently. There might be some such reason, but I'm a bit dubious --
if there was a good reason, why wasn't it spelled out months ago?
Secure by default is no reason? You can always overwrite it on
runtime.
By default, no user belongs to group disk, so it is secure. The
system administrator has to take special steps to make it insecure.
The amanda-common postinst adds the backup user to the disk and tape
groups, for example. The backup *system* user exists solely for the
purpose of creating and restoring backups, and is equivalent to user
nobody but with disk and tape access. You could consider it
equivalent to root, since it does have full system access, but it's
only ever used from e.g. /etc/cron.d.
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://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/
iD8DBQFDpAm8VcFcaSW/uEgRAgrRAKDmkLBpHXBH9GNL3CCktgz2q3xUAACcDS7W
KmL48TPLrrqzDBBQ3Pv+Wak=
=Cjae
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
On Sat, Dec 17, 2005 at 12:41:17PM +, 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? If I create a new LV, the permissions will be wrong. If I run vgchange, the permissions will be wrong. This is not a solution. And I don't speak about libdevmapper managed device. What if the user isn't using udev? There are only 2 versions, static dev or udev, so which one is missing? Do you have any example udev rules to do what you suggest? SUBSYSTEM==block, MODE=0600 Bastian -- Witch! Witch! They'll burn ya! -- Hag, Tomorrow is Yesterday, stardate unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bastian Blank [EMAIL PROTECTED] writes: On Sat, Dec 17, 2005 at 12:41:17PM +, 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. a new LV, the permissions will be wrong. If I run vgchange, the permissions will be wrong. This is not a solution. And I don't speak about libdevmapper managed device. Please could you clarify? What *are* you speaking about. I'm referring to the fact that when I create or change an LVM LV, I have to manually correct the permissions (on both static and udev managed systems). It would make this problem a whole lot easier if you could explain in some detail about your reasoning and thoughts, so that we don't have to guess. What if the user isn't using udev? There are only 2 versions, static dev or udev, so which one is missing? Let's examine the two cases, using the default setup Debian provides after installation: Static device nodes - --- * /dev is static, with devices created by MAKEDEV. * /dev/mapper, and related symlinks are still not static, they are created and removed by devmapper (vgscan, vgchange, lvchange etc.), with the default ownership and permissions of root:root 0600. If you don't like those permissions, you have to change them manually. udev - * /dev is managed by udev, using udev rules * /dev/mapper and related symlinks are ignored by udev (there are no rules), and it is still managed by devmapper (see below). Do you have any example udev rules to do what you suggest? 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: Take a look at the default udev behaviour in /etc/udev/udev.rules: # device mapper creates its own device nodes, so ignore these KERNEL==dm-[0-9]*,NAME= KERNEL==device-mapper,NAME=mapper/control Unless you have some udev rules that solve the problem, udev is not the solution because it delegates all responsibility to devmapper. Also, you have not addressed the case where udev is not in use: the ownership and permissions are still wrong. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://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/ iD8DBQFDpCosVcFcaSW/uEgRAjmwAJ49d+EnOywJpIRnGEENJ8h5W6BciwCgvcck 7vEzOSgyOVh7b027LImQUzg= =CO41 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
Hi all: El Sábado, 17 de Diciembre de 2005 16:09, Roger Leigh escribió: Bastian Blank [EMAIL PROTECTED] writes: On Sat, Dec 17, 2005 at 12:41:17PM +, Roger Leigh wrote: [...] Please could you clarify? What *are* you speaking about. I'm referring to the fact that when I create or change an LVM LV, I have to manually correct the permissions (on both static and udev managed systems). It's even worse. There is, of course a problem in the fact that all disk devices are created root:disk 0660 *except* those managed through LVM. I migth accept someone having concerns with these default perms/ownership (while it has been already stated that nobody will belong to group disk by default), but I can't accept the vast majority of the (related) packages accepting this (maybe unwritten) policy except one. The less surprising path should rule here. I'd say that if Bastian has concerns with this he should try to change the defaults (talking to other related package owners) for _all_ concerned packages (so, for instance, all devices would be created root:root 0600, the disk group deleted and all packages which will break changed accordingly) *or* accept the voice of the majority (and change their packages so they default to device creation root:disk 0660, or any other default that would arise) *or* (this would the the worst option by far) resign as maintainer for those packages, since (as is a Debian package maintainer must) he can't/won't manage for his packages to smoothly integrate within the distribution. But I said it is worse than that. It is worse because you have an /etc/default/lvm-common file where it is explictly stated that you can change device perms/ownership to whatever you need while you can't (and you won't be able to use underscores on the device names, but that's another story). Hence a given expectation is created that it won't be supported. What if the user isn't using udev? For the most part, it is not a what if situation. Sarge doesn't use udev by default but static /dev/ so most users will by using /dev. And Sarge uses static /dev for a reason. It is terribly unwise asking for using udev in Sarge just for being able to cleanly integrate LVM on a system that neither expects udev nor tells the sysadmin it should use it (I don't remember udev being mentioned neither as a dependency nor as a suggestion on LVM packages). What I *do* remember is that lvm2 package explicitly states that ...LVM2 is backwards-compatible with LVM1 (lvm10), and requires Linux kernel 2.4 or later. Of course LVM2 is *not* backwards compatible in Sarge since an upgrade from LVM1 to LVM2 will break things on Sarge due to its incompatible volume ownership/perms.
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote: Bastian Blank writes (Re: Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices): On Tue, Dec 13, 2005 at 03:55:01PM +, Ian Jackson wrote: [Raul Miller:] 1) change devmapper defaults -- patch rejected, no reason given Certainly I agree that the defaults should be changed. At least in my point of view, a default is something which can be changed easily, maybe in a config file. In this case, it is no default, it is the value which anything gets. You seem to be saying that there is no way to override the setting. Which proposed setting are you talking about here - the change in the call to configure, or some other change ? The first. How do you think this problem should be solved ? Add an interface to change the setting on device creation and delegate the problem to the tools. I've also seen the suggestion that we should have a explicit technical policy that block devices should default to having 660 permissions with owner root and group disk. [...] This breaks anything which wants to use group cdrom for cdrom access without manual intervention. Obviously the policy language would have to be carefully worded to ensure that it applied to disks and not (eg) to cdrom devices. devmapper don't provide disks. It provides a view (in the SQL meaning) of block devices. Are you saying that the current default permissions on (eg) /dev/hda* are insecure and therefore wrong ? Yes, I overwrite them on my machines. If they are, what significant good does it do to make the lvm devices inaccessible to group disk (since it is possible to avoid going through LVM to access the disks directly). deviver-mapper uses major and minor for the communication, only the userspace tools uses the devices to read data or just map them to the device number. Is the problem with your participation in this discussion that English isn't your native language ? Yes, it is one. Bastian -- Even historians fail to learn from history -- they repeat the same mistakes. -- John Gill, Patterns of Force, stardate 2534.7
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
On 12/16/05, Bastian Blank [EMAIL PROTECTED] wrote: On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote: Are you saying that the current default permissions on (eg) /dev/hda* are insecure and therefore wrong ? Yes, I overwrite them on my machines. And what is your reason for being unwilling to use the same procedure on devmapper disks? Do you believe that debian should deliver a patchwork collection of administrative decisions, such that every time a new package is installed a new set of administrative policies must be learned and new procedures must be adopted by the users? Personally, I'm using a system where the only way to obtain root access is to log in as root -- there's no privileges gained through suid binaries. Perhaps you'd like to use some significant packages configured this way since it fixes something I consider to be a security problem? Note also that your inconsistency is an inconsistency. You've not fixed the problem in all packages, only one package. You've not proposed anything to the community in general which addresses this issue. Instead, you've created problems for people without really improving the security of debian systems in general. This is a good idea? Why? What good thing have you accomplished? Thanks, -- Raul
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
On Tue, Dec 13, 2005 at 03:55:01PM +, Ian Jackson wrote: 1) change devmapper defaults -- patch rejected, no reason given Certainly I agree that the defaults should be changed. At least in my point of view, a default is something which can be changed easily, maybe in a config file. In this case, it is no default, it is the value which anything gets. I've also seen the suggestion that we should have a explicit technical policy that block devices should default to having 660 permissions with owner root and group disk. I don't have any objections to such a policy, but I don't see that solving this problem should wait on the adoption of this policy. Quite so. (Modulo my comments about the exact mode, above.) This breaks anything which wants to use group cdrom for cdrom access without manual intervention. Finally, I don't see any reasoning given for things being the way they are currently. There might be some such reason, but I'm a bit dubious -- if there was a good reason, why wasn't it spelled out months ago? Secure by default is no reason? You can always overwrite it on runtime. I agree, if we can settle my quibble about group-write. If the upper don't apply, 666 is also a valid setting. Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, The Paradise Syndrome, stardate 4842.6
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
Bastian Blank writes (Re: Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices): On Tue, Dec 13, 2005 at 03:55:01PM +, Ian Jackson wrote: [Raul Miller:] 1) change devmapper defaults -- patch rejected, no reason given Certainly I agree that the defaults should be changed. At least in my point of view, a default is something which can be changed easily, maybe in a config file. In this case, it is no default, it is the value which anything gets. You seem to be saying that there is no way to override the setting. Which proposed setting are you talking about here - the change in the call to configure, or some other change ? How do you think this problem should be solved ? I've also seen the suggestion that we should have a explicit technical policy that block devices should default to having 660 permissions with owner root and group disk. [...] This breaks anything which wants to use group cdrom for cdrom access without manual intervention. Obviously the policy language would have to be carefully worded to ensure that it applied to disks and not (eg) to cdrom devices. Finally, I don't see any reasoning given for things being the way they are currently. There might be some such reason, but I'm a bit dubious -- if there was a good reason, why wasn't it spelled out months ago? Secure by default is no reason? You can always overwrite it on runtime. Are you saying that the current default permissions on (eg) /dev/hda* are insecure and therefore wrong ? If they are, what significant good does it do to make the lvm devices inaccessible to group disk (since it is possible to avoid going through LVM to access the disks directly). I agree, if we can settle my quibble about group-write. If the upper don't apply, 666 is also a valid setting. This is some kind of straw man. Is the problem with your participation in this discussion that English isn't your native language ? If not, please let us know and perhaps we can get someone to help translate. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
Raul Miller writes (Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices): I've been looking at these bugs, and I can see no good reason for the 600 permissions, nor the reason to avoid using the disk group. I basically agree, but I'm going to try to play devil's advocate at least a little bit (because I don't like decisions made in a vacuum). In the bug report the only thing resembling a technical objecting to the 660 root.disk mode is the complaint that this makes the disk group equivalent to root. This seems to be me to be largely true. For this very reason, on my own systems I generally have disk devices 640 root.disk. Do we know whether Amanda would work with 640 root.disk ? There also seems to be some huge confusion about where responsibility for setting permissions and group should be handled. Here's what I currently see suggested: 1) change devmapper defaults -- patch rejected, no reason given Certainly I agree that the defaults should be changed. I've also seen the suggestion that we should have a explicit technical policy that block devices should default to having 660 permissions with owner root and group disk. I don't have any objections to such a policy, but I don't see that solving this problem should wait on the adoption of this policy. Quite so. (Modulo my comments about the exact mode, above.) Finally, I don't see any reasoning given for things being the way they are currently. There might be some such reason, but I'm a bit dubious -- if there was a good reason, why wasn't it spelled out months ago? Indeed. I think the committee's ruling should explicitly castigate the devmapper maintainer for failing to engage constructively with any of the submitters. This is outside our primary scope of course but we are entitled by our remit to make formal position statements about any matter, and it seems legitimate for us to criticise the way someone has handled a disagreement. Based on what I've seen so far, I'd recommend that the defaults for devmapper be changed using Roger Leigh's 7 Dec patch from the 329409 bug report be adopted, that Bdale Garbee's 19 Nov patch from the same bug report be adopted, and that policy be changed to specify the default group and permissions for disk devices. I agree, if we can settle my quibble about group-write. We should also explicitly suggest that an NMU would be appropriate if the maintainer chooses not to get around to applying the patches. I'm hoping someone can tell me what I've overlooked -- what is so important here that's prevented this issue from being resolved? I can't see it and the responsible package maintainer doesn't seem to be telling us. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Jackson [EMAIL PROTECTED] writes: Raul Miller writes (Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices): I've been looking at these bugs, and I can see no good reason for the 600 permissions, nor the reason to avoid using the disk group. I basically agree, but I'm going to try to play devil's advocate at least a little bit (because I don't like decisions made in a vacuum). In the bug report the only thing resembling a technical objecting to the 660 root.disk mode is the complaint that this makes the disk group equivalent to root. This seems to be me to be largely true. For this very reason, on my own systems I generally have disk devices 640 root.disk. Do we know whether Amanda would work with 640 root.disk ? I've just tested this on a company machine. /usr/sbin/amcheck appears to work correctly, but I can't risk leaving the perms changed for the real backup run tonight. Since I'm using tar (as opposed to dump or restore), I'm not certain the permissions actually have any effect in this case (because the filesystem is already mounted, tar can just use that; it doesn't even have to mount it). If you were using dump and restore, you would presumably need read and read+write permissions respectively, so IMO 0660 is the correct default in this situation, especially if you account for folks who do backups without amanda, but still make use of the disk group. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://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/ iD8DBQFDnwObVcFcaSW/uEgRAm79AKCuqkXZDiSux7Ntoa9GwXd4SoYHQACfevdr j6PLegyQSvwmMTJW+vXlnyk= =5/8t -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
I agree with your technical assessment, Ian. On 12/13/05, Ian Jackson [EMAIL PROTECTED] wrote: I think the committee's ruling should explicitly castigate the devmapper maintainer for failing to engage constructively with any of the submitters. But I disagree with this. I think such a statement would be patronizing and unhelpful. Guy
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
Guy Maor writes (Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices): I agree with your technical assessment, Ian. Do you have an opinion about 660 vs 640 ? And the question of equivalence to root ? On 12/13/05, Ian Jackson [EMAIL PROTECTED] wrote: I think the committee's ruling should explicitly castigate the devmapper maintainer for failing to engage constructively with any of the submitters. But I disagree with this. I think such a statement would be patronizing and unhelpful. I don't see why it would be patronising for us to officially criticise someone for their behaviour. In this case it has been outrageously obstructive. In particular, I think that telling someone off for being unconstructive might help clarify what is and isn't sensible behaviour by a maintainer. Something like: N. The Technical Committee is disappointed by the approach taken by the relevant package maintainer, who has demonstrated an unhelpful and obstructive attitude. Lack of effort to fix a problem is acceptable; disagreement about the proper behaviour is acceptable; even insistence by the maintainer on the correctness of their approach is acceptable. Failure to even acknowledge the matter coupled with bare refusals of assistance (in the form of NMUs, in this case) is not acceptable. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
I've been looking at these bugs, and I can see no good reason for the 600 permissions, nor the reason to avoid using the disk group. There also seems to be some huge confusion about where responsibility for setting permissions and group should be handled. Here's what I currently see suggested: 1) change devmapper defaults -- patch rejected, no reason given 2) explicitly use udev -- problem, this doesn't work for 2.4 kernels (2.4 used devfs) 3) avoid using devmapper (but this is not a solution) I've also seen the suggestion that we should have a explicit technical policy that block devices should default to having 660 permissions with owner root and group disk. I don't have any objections to such a policy, but I don't see that solving this problem should wait on the adoption of this policy. Finally, I don't see any reasoning given for things being the way they are currently. There might be some such reason, but I'm a bit dubious -- if there was a good reason, why wasn't it spelled out months ago? Based on what I've seen so far, I'd recommend that the defaults for devmapper be changed using Roger Leigh's 7 Dec patch from the 329409 bug report be adopted, that Bdale Garbee's 19 Nov patch from the same bug report be adopted, and that policy be changed to specify the default group and permissions for disk devices. And, yes, that's overkill and in that sense inelegant. But system stability and predictability is a higher priority than do it once and only once. With differing kernel and package versions, we have to allow at least for transition times when the same issues are dealt with in different packages. (And, yes, all of this should be spelled out in detail in some package -- preferably the package where the final responsibility resides). I'm hoping someone can tell me what I've overlooked -- what is so important here that's prevented this issue from being resolved? Thanks, -- Raul
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices
On Wed, Dec 07, 2005 at 05:29:08PM +, Roger Leigh wrote: #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. A small correction: I meant /dev/mapper/control, rather than /dev/mapper. Thanks, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. signature.asc Description: Digital signature
