udev sets permissions for partitions to root:root which is ok, but it sets permissions for disks to root:disk. That means every ordinary user with group disk can run commands like this: cat /dev/hda /home/foobar/out.txt dd if=/dev/zero of=/dev/hda That should not be possible. If a program has a security hole and runs one of this commands, it can damage the whole system without root permissions. Problem is already discussed here: http://forums.gentoo.org/viewtopic-p-2597592.html#2597592 Reproducible: Always Steps to Reproduce: Attention! Do not perform the following actions, just read it ! 1. Login with a user in group disk 2. Run dd if=/dev/zero of=/dev/hda 3. Reinstall gentoo *g*
base-system please advise.
*** Bug 100116 has been marked as a duplicate of this bug. ***
uhh, how is this a bug ? dont add your users to the disk group, simple as that
Just read the following thread and you will understand why we filled that bug: http://forums.gentoo.org/viewtopic-t-355069-postdays-0-postorder-asc-start-75.html
all i see there is discussion of whether using a disk group makes sense that doesnt change the fact that if a misguided user added someone to the disk group that's their own damned fault and really isnt a security issue
also, it's not like udev is doing anything new if you review MAKEDEV you'll see that it uses root:disk 660 permissions too ... that means this permissions setup has been this way for quite a long time (pre-devfs and pre-udev)
but why? that's the question and why not apply it for all the partitions also (as ubuntu does it)? and why one more group? what's the sense?
i think the fact that hda[0-9]* is not set to the disk group is a bug in udev the rule that executes the devfs script doesnt seem to communicate properly thus the group is set to the default root ...
Ok this makes more sense, I agree, that if the devs decide to use some scheme, it should be supported. The problem was only the inconsistency of it, and probably the missing documentation about it.
Ok, if there will be only one sheme for disks and partitions, thats fine for me. But also an update to the documentations (manuals) with a warning about that group should not be forgotten. A warning in the next udev ebuild would be fine too.
add a warning about something that has always been this way ? if you go back to even the Gentoo 1.2 release you'll see that the device nodes have always been like this i dont see the point in trying to 'protect' a user who screws around with system groups and has no idea what they're doing ... plus i doubt they'd even see said warning
I thought more of a document like this one http://modular.fas.harvard.edu/docs/debian-packages/base-passwd/users-and-groups.html I think it is not up-to-date or complete, but sth like this would be a nice thing to have, with an explanation, when these groups are needed.
(In reply to comment #11) > i dont see the point in trying to 'protect' a user who screws around with system > groups and has no idea what they're doing ... plus i doubt they'd even see said > warning Sorry, but you sound like a MS official, if you don't press this button, you are secure ... Playing around with the system is the way most of us used to learn, beside there are good documentations and howtos and if there is somewhere a warning about that, they don't have to learn that through a damaged system (Although, most will not realise that the failure was a action they have taken maybe months ago when they installed their system and added their users to the group disk).
(In reply to comment #13) > Sorry, but you sound like a MS official, if you don't press this button, you > are secure ... was there any real point to this comment ? i didnt think so if you want documentation on the different system groups, then file a new bug to create one as part of the Gentoo doc project which covers *all* the groups ... have assing it by putting in a warning about 1 group because some users did something dumb like giving out group access to people they shouldnt have doesnt make sense ... you can cause problems by giving out access with other groups, not just disk the only point of this bug now is to fix the devfs script so that all block nodes are given disk group permissions
This is a copy&paste from the forum thread, maybe it's not that simple: ------------------------------------------ drphibes wrote: bit of a flame war going on in that bug report ... so let's reason this out. i have no problem removing disk from ordinary users' group lists. but, i need to give them rw access to my usb writer /dev/dvd -> /dev/sr0 which udev currently creates as root/disk w/perms 660. i note there is no dvd group in /etc/group, but there is cdrom and cdrw. i suppose i could change the gid on sr0 to cdrw, or add a 'dvd' group and use that gid, then grant dvd or cdrw membership to ordinary users an be done with group disk as far as they are concerned. btw why isn't there a 'dvd' group? also i do think that the partition devices (e.g. hda[1-9]) and whole disk device (e.g. hda) should be in the same group, WHATEVER that ends up being, i.e. disk or root. it makes little sense to have them in different groups. ------------------------------------------
there is no dvd group because cdrw covers that the fact that your scsi burner is setup as disk group instead of cdrw / cdrom could just be another limitation in the devfs script / udev rules
hm... udev will not honor my local rule's GROUP="cdrw" specifier: ---10-local-udev.rules---- BUS=="scsi", KERNEL="sr[0-9]*", PROGRAM="/etc/udev/scripts/cdsymlinks.sh %k", SYMLINK+="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}", NAME="%k", GROUP="cdrw" it still creates the node under group disk. my cdsymlinks.sh sr0 returns: cdrom1 cdrw dvd dvdrw and those symlinks are created and pointing correctly to sr0. Phil (drphibes)
forgot to mention i am using udev-063. (i notice 064 is out of the oven)
greg, what's the word on comment #17? should i file a separate bug for that, or is there a way to accomplish it already? i want to put sr0 into group cdrw while keeping the convenient symlinks produced by cdsymlinks.sh.
separate bug please.
bug# 100610 filed.
marking invalid, as this is the way things always have been. if someone comes up with a solution, please feel free to reopen this.
gregkh: this bug is kind of a mess, but what it ended up being is this: udev doesnt properly set disk group permissions on partitions ... so /dev/hda is root:disk but /dev/hda1 and /dev/hda2 are root:root when they should be root:disk it looks like a failing of the devfs script and/or what the udev rule expects it to echo back to it
Ah, thanks for the summary. Ok, found it. I'll be slowly changing the udev rules file to be much quicker and make udev take up less memory in the tmpfs partition. Also, we will get persistant device names for a lot of different subsystems, as was agreed apon at OLS this year. I'll fix this up when I get to the block devices, just want to take it slow for now, so I don't break peoples boxes. If you want, you can try adding the line: SUBSYSTEM="block", GROUP="disk", MODE="0640" which should solve this (I'll leave it to the reader to determine the best place for this line...)
the way i 'fixed' it was updating the devfs script to echo ${MEDIA} twice ... seemed to work well enough for me
For Phil: I think your rule should work if it comes *after* the main rules are applied. This behavior has changed once or twice in the life of udev, but now I have my custom rules invoked last, and it seems to work...
steve, that's interesteing. so you're suggesting a rules.d directory which might include files named like this: 10-local-udev.rules <- stuff that can or must fire before the 50 file 50-udev.rules 99-local-udev.rules <- stuff that can or must fire after the 50 file
(In reply to comment #27) > steve, that's interesteing. so you're suggesting a rules.d directory which > might include files named like this: > > 10-local-udev.rules <- stuff that can or must fire before the 50 file > 50-udev.rules > 99-local-udev.rules <- stuff that can or must fire after the 50 file No, if you read the manpage, you will see that only the first rule that sets NAME gets used, but all others that do not touch NAME should (not sure from the docs) stack I guess ... so if your rule sets NAME, it should go before, if not, it should go after. Greg, ps, this sorda might be confusing ... does the last MODE rule that apply for some device apply, or the first? And if the first sets both NAME and MODE, does the second that sets both NAME and MODE get totally ignored, or just the NAME bit ?? It might have been easier if the last MODE/NAME/GROUP/whatever would apply for all cases, but I guess you guys know best :)
Last MODE and GROUP applies. I'm closing this as it isn't really a bug anywhere...
