udev [059-070] bug discussions

[DerCorny]

While waiting for an advise of the maintainer, think about: is this a bug or a feature? Ever thought about that you might not be supposed to add normal users to group "disk"?

[apache]

[Gergan Penkov]

Ok, I have this objection to the feature-idea. The disc group is thought of as a last resort to reduce the possible security implication in the need of giving somebody raw access to some disc or partition. Examples: central deployed servers with vmware(qemu) and read,write access to one partition/special disc for the user, archiving software with only partition/disc-readonly access running as a cron-job and so on. This means if someone coming from another distribution makes it the same way on gentoo, he is giving an unprivileged user all the access, which he/she is needing to ruin the system. And why giving somebody or some group a simple way for privilige-escalation, all the users in disc group could simply change /etc/passwd line for root to sth like root::... instead of root:x:... (I think this was the way, if not it is that easy) and receive passwordless access?

[EDIT] I mean it with sth like dd if=..|sed ...|dd of=..., not that I think, someone could change it with vi or gedit (the partitions have the correct permissions)) ::))
_________________
"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack

[apache]

The reason why this group exists is clear and it makes sense but as Gergan said already it can be used to alter data or just erase the disk. Although this group should be used only for administrative objectives and therefore it should be assigned to users only if really needed. But fact is, that there is no warning about that in the gentoo manual and every users can be assigned to that group without any warnings.

It's nearly the same like the cdrom and cdrw group, users select this group because they need access to their cdrom and want to brun cds and some may think: Hey, I need access to my drives, so I need to be in disk group.

[DerCorny]

Ok, I'm saying this without any specific knowledge of udev and so on - so chances are (and history shows ) that i'm completely wrong with this - so don't flame me if I'm wrong. Better wait for real comments from the udev gods.

But you said yourself: "disk" group is a dangerous group and should be considered as a very last resort. This implies that _no_ normal, untrusted and unprivileged users should be in this group. Putting all disks into the "disk" group offers the advantage that we can now allow trusted users raw disk access without putting them into the "root" group.

I can hardly protect users from doing not-so-smart things. And putting users in $DANGEROUS_GROUP is such a thing.

[Gergan Penkov]

Don't get me wrong. I also don't want to start a flame war, it probably should simply be documented (as apache said) and there must be warnings in the emerge process, because it is a major change in priviliges of a group.
I think that there must be a gentoo policy concerning and explaining the groups, which are used from various packages and the base system, because it is possible for an uninformed sys-admin to open a security hole in the system.
_________________
"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack

[apache]

[drphibes]

[apache]

[drphibes]

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.

[drphibes]

thread renamed: [59-65]

My system hangs during boot on "Setting system clock to hardware clock [Local TIme] ..." after upgrade to udev-064-r1. I had to boot from a CD and downgrade to udev-063 to straighten it out. I'll post another bug report.

I am masking off >= 064.

EDIT: bug# 101110 posted

[eltino]

udev-065 is back to taking cdrom devices out of the cdrom group... back to root:disk... Hell, such a small little package...

[zerb]

The same thing has been bugging me too. Why did they take cdrom devices out of that group in the first place?

[gimpel]

indeed 065 is fucked up again, back to 063 here.. works flawlessly

i really liked the "old" way most where one could set things in permissions.d.
for example: you want dvd drive be accessible for group cdrom, but burner only for group cdrw... how the fscking heck can that be done atm? setting up custom rules for hdc and hdd in 10-local.rules is useless, and it really should be possible to adjust that easily, shouldn't it?
_________________
http://proaudio.tuxfamily.org/wiki - pro-audio software overlay

[drphibes]

[gimpel]

humm, my current 10-local.rules is:

[drphibes]

I think the NAME key is always "terminal" as a far as the udev rule-chaining is concerned, i.e. the NAME specifier will be ignored on a rule that matches later. Other keys like GROUP, however, keep chaining along until the last match is met and then that one is used. Thus the := syntax (see man udev). I was using the old prolog term "cut" as an analogy. You'll have to experiment with the other keys to see which ones might require "cut" syntax. The == is just like c/c++, a comparison for equality, whereas = is assignment. Obviously you want to match on the BUS key, not assign it.

Anyhow, glad it works. Wish I could say the same for 065.

[RaZoR1394]

udev 065 messed up my CD/DVD devices as well. 064 and 064-r1 are the ones which works best for me as the kde system sounds finally works so I downgraded to 064-r1.

[Hobbit_HK]

Works for me on 065:

[seppelrockt]

[Hobbit_HK]

About the group thing, maybe it's because 50-udev.rules is executed after your local rules and overrides your group setting, try GROUP:= instead of GROUP= in your local rules.
_________________
- Hobbit HK

Don't use stage1\2 tarballs
Do a stage1 install from a stage3 tarball

[seppelrockt]

I already had group:= in it but it didn't work. I have tried two different versions, the first (now in cooments) is from this post and the second is the line from the original 50-udev-rules + group:= argument at the end - neither worked. Looks like 10-local-rules is not used at all?

[Hobbit_HK]

Udev is supposed to use syslog, so maybe check log/everything to something..
And try to use == and not = in your comprasions.
_________________
- Hobbit HK

Don't use stage1\2 tarballs
Do a stage1 install from a stage3 tarball

[seppelrockt]

[Hobbit_HK]

Hmm.. Maybe there was some change in versions above 058? Maybe the manual has something to say?
_________________
- Hobbit HK

Don't use stage1\2 tarballs
Do a stage1 install from a stage3 tarball