| Summary: | app-emulation/wine only looks for cdroms via /dev/sg* | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alexander E. Patrakov <patrakov> |
| Component: | Current packages | Assignee: | Wine Maintainers <wine> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | galtgendo |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Alexander E. Patrakov
2010-05-22 09:32:10 UTC
moving to wine maintainers: "This happens because wine uses the obsolete /dev/sg* method" ... original reporter: please try with wine 1.3.x series from ~arch. note that 1.1.x series is no longer in portage. The bug is still there, in both its parts. 1) Discrepancy of permissions of /dev/sr0 and (obsolete) /dev/sg1. Both have the "cdrom" group, but only /dev/sr0 has ACLs. 2) Wine still uses /dev/sg1 when an application inside it uses ASPI to send raw commands to the CD-ROM. i dont think you mean ACLs, but rather simple ownership/permission of the devices. i also dont think these devices nodes are "obsolete" in any way. /dev/sg* cannot all be granted directly to the cdrom group because sg (scsi generic) device nodes are created for all scsi devices. /dev/sr* however are scsi recorders which means a cdrom group assumption is pretty safe. the udev guys would have to comment as to the feasibility of granting cdrom ownership to /dev/sg* devices which correspond only to scsi recording devices. as for getting wine changed, we dont do development on wine here. feature enhancements should go to http://bugs.winehq.org/ the latest code base looks only for devices that start with "sg" in /dev: dlls/wnaspi32/aspi.c:SCSI_Linux_CheckDevices() ... devdir = opendir("/dev"); for (dent=readdir(devdir);dent;dent=readdir(devdir)) { if (!(strncmp(dent->d_name, "sg", 2))) break; } closedir(devdir); ... I do mean ACLs. The traditional unix-style permissions are already applied automatically to /dev/sg* nodes corresponding to cdroms. See here: aep@home ~ $ ls -l /dev/sr* /dev/sg* crw-rw---- 1 root disk 21, 0 Дек 20 10:24 /dev/sg0 crw-rw---- 1 root cdrom 21, 1 Дек 20 10:24 /dev/sg1 crw-rw---- 1 root disk 21, 2 Дек 20 10:24 /dev/sg2 crw-rw---- 1 root disk 21, 3 Дек 20 10:24 /dev/sg3 crw-rw---- 1 root disk 21, 4 Дек 20 10:24 /dev/sg4 crw-rw---- 1 root disk 21, 5 Дек 20 10:24 /dev/sg5 brw-rw----+ 1 root cdrom 11, 0 Дек 20 10:24 /dev/sr0 aep@home ~ $ getfacl /dev/sr0 /dev/sg1 getfacl: Removing leading '/' from absolute path names # file: dev/sr0 # owner: root # group: cdrom user::rw- user:aep:rw- group::rw- mask::rw- other::--- # file: dev/sg1 # owner: root # group: cdrom user::rw- group::rw- other::--- The ACL part of this bug is actually about the interaction with ConsoleKit. See the plus near /dev/sr0 above? It means that there are ACLs not representable with UNIX permissions. They are dumped with getfacl below. Note that there is no such ACL near /dev/sg1, although the "cdrom" group is applied to /dev/sg1. Consolekit is the program that automatically creates such ACLs for logged-in users. It is supposed to make the cdrom group unneeded. I fixed this bug myself, by adding this line to /lib/udev/rules.d/70-acl.rules:
SUBSYSTEM=="scsi_generic", ENV{ID_CDROM}=="1", TAG+="udev-acl"
I know that it will be overwritten on udev upgrade if you don't take it into the package :)
Oops, I pasted the wrong rule. Here is the correct one:
SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="4|5", TAG+="udev-acl"
The ACLs on /dev/sg* are correct now, so the permissions-related part of this bug no longer exists. Wine still uses the obsolete /dev/sg* devices, though - it is an upstream bug. 50-udev-default.rules from udev-210:
SUBSYSTEM=="block", KERNEL=="sr[0-9]*", GROUP="cdrom"
SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="4|5", GROUP="cdrom"
70-udev-acl.rules from consolekit-0.4.6:
SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="4|5", TAG+="udev-acl"
so I don't think there is anything left to be done for udev-bugs@, rather this is app-emulation/wine problem for using old interfaces like Comment #8 already said
(In reply to Samuli Suominen from comment #9) > 50-udev-default.rules from udev-210: > > SUBSYSTEM=="block", KERNEL=="sr[0-9]*", GROUP="cdrom" > SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="4|5", > GROUP="cdrom" > > 70-udev-acl.rules from consolekit-0.4.6: > > SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="4|5", > TAG+="udev-acl" Result of above setup: $ ls -ld /dev/{sg*,sr*} crw-rw---- 1 root disk 21, 0 Feb 21 16:27 /dev/sg0 crw-rw----+ 1 root cdrom 21, 1 Feb 21 16:27 /dev/sg1 crw-rw---- 1 root disk 21, 2 Feb 23 10:16 /dev/sg2 crw-rw----+ 1 root cdrom 21, 3 Feb 23 10:16 /dev/sg3 brw-rw----+ 1 root cdrom 11, 0 Feb 21 16:27 /dev/sr0 brw-rw----+ 1 root cdrom 11, 1 Feb 23 10:16 /dev/sr1 Looks okay to me, group is coming from udev, ACL + is coming from ConsoleKit (or alternatively, systemd's uaccess (logind)) As comment 4 says, > we dont do development on wine here |
