Arch Linux

Only a comment, idea...
Here it works. Is sg0 realy a cd/dvd or scanning device?
/dev/sg0 here have same permissions as you reported as an error, but:
sginfo /dev/sg0 shows me that this this is the generic scsi device of my harddisk.
My optical devices and scsi scanner (sg1, sg2) have the right groups optical and scanner.

Thanks for the hint about sginfo and here is the result of it:
INQUIRY response (cmd: 0x12)
----------------------------
Device Type 0
Vendor: ATA
Product: SAMSUNG SP2504C
Revision level: VT10

It seems that my SATA Hard Drive get this device. A "lsmod | grep sg" shows this:
sg 30224 0
scsi_mod 132012 3 sg,sd_mod,libata

Strange because a "ls -l /dev/sda" shows this: brw-rw---- 1 root disk 8, 0 2. Apr 19:40 /dev/sda

Instead i'm a little bit confused about this all -), i think there should be a udev rule for such a case be included. Does you know if the above value from "Device Type" in the output of sginfo is to be used for ATTRS{type}? Okay i give this rule a try: SUBSYSTEMS=="scsi", KERNEL=="sg[0-9]*", ATTRS{type}=="0", GROUP="disk"

The permissions looks now good with this rule but perhaps anyone can say if this is necessary or not.

In my opinion the irritation between sd* devs(root:disk) and sg*(root:root) for harddisks is not major. I know only very few enviroments where other users except root are member of disk group. One could do very bad things having write access on the device. Same with only read access. So IMHO the udev construct for disks is not mandantory, if now disk or root group.
Same with the sg tools, there are many: try sg<TAB-TAB> an have a look ;-) and you could do very "bad things" with.

You could wait what one of the devs say about, but if your other sg devices for cd/dvs and/or scanner are handled correctly by udev, then i think the harddisks should have strong permissions (either group disk or root)
(Sorry, my english is not so good, i hope you know what i mean)

You be right that it is not a bad thing and can be handled by myself. In my case a second option is to blacklist sg in rc.conf to prevent it get loaded at bootup because a /dev/sg0 is not necessary for my sata hard disk.

But how longer i think about it i mean that after this lines for two ATTRS{type} a default rule for the other types with the group disk would be the best. And yes, i think too that the permissions of a device should be safe.

Off Topic: Your english is better than mine and we have the case that we 2 germans speaks in another language.-)

Would adding the udev rule above

SUBSYSTEMS=="scsi", KERNEL=="sg[0-9]*", GROUP="optical"

to the arch rules solve this?

@Aaron From my side this default rule is nice.

Could it be that sg devices with ATTRS{type}=="0" be even a hard drive? If yes, than perhaps we can blacklist them because at the first moment i don't see a reason for what i need a sg device for a hard drive. But this is not realy necessary.

Realy, i don't see any problem with the current udev behavior here.
All my installations have: group disk on sg devices which are harddisks, optical/scanner on devices which are CD/DVD or scanners.
So i think udev does a nice job.

SUBSYSTEMS=="scsi", KERNEL=="sg[0-9]*", GROUP="optical"
Don't think that this is good as a default. I don't want to have users in optical to have access on my sg0(=harddisk).
And i don't see any raeson for "blacklisting" hard drives for scsi generic access: there are many sg_* tools which are useful for hard drives.

So: if Attila has no further problems with current udev AND his cd/dvd, scanners i think closing this report is ok.

@GerBra I have no problem because i found a working solution for myself and because i have no tools which needs generic access to my hard drive i blacklist sg.

If you think that there are useful tools for such a case without that it can be used from members of optical and scanner than this could be a nice idea for 51-arch.rules:

# permissions for scsi generic access to hard drives
SUBSYSTEMS=="scsi", KERNEL=="sg[0-9]*", ATTRS{type}=="0", GROUP="disk"

But still again from my side there is no problem to close this bug and let it be as it is now because this could be handled perfectly from the user in his own *.rules or in my case in the rc.conf.