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