[PATCH] add ACLs to /dev/sgX nodes for CD-ROM

[PATCH] add ACLs to /dev/sgX nodes for CD-ROM

[Andrey Borzenkov]

Current wine is using /dev/sgX to access CD-ROM devices. Since
distributions switched to using ACL instead of group membership
to control device access, wine is not able to access them.

Add ACL to device nodes that already get GROUP="cdrom".

Ref: https://qa.mandriva.com/show_bug.cgi?idb114

Signed-off-by: Andrey Borzenkov <arvidjaar@mail.ru>

---
 extras/udev-acl/70-acl.rules |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/extras/udev-acl/70-acl.rules b/extras/udev-acl/70-acl.rules
index 0717d25..b0015b6 100644
--- a/extras/udev-acl/70-acl.rules
+++ b/extras/udev-acl/70-acl.rules
@@ -63,6 +63,9 @@ ENV{DDC_DEVICE}="*?", TAG+="udev-acl"
 # media player raw devices (for user-mode drivers, Android SDK, etc.)
 SUBSYSTEM="usb", ENV{ID_MEDIA_PLAYER}="?*", TAG+="udev-acl"
 
+# /dev/sgX nodes for CD-ROM drives
+SUBSYSTEM="scsi_generic", SUBSYSTEMS="scsi", ATTRS{type}="4|5", TAG+="udev-acl"
+
 # apply ACL for all locally logged in users
 LABEL="acl_apply", TAG="udev-acl", TEST="/var/run/ConsoleKit/database", \
   RUN+="udev-acl --action=$env{ACTION} --device=$env{DEVNAME}"
-- 
tg: (218e47a..) upstream/cdrom-sg-acl (depends on: master)

Re: [PATCH] add ACLs to /dev/sgX nodes for CD-ROM

[Kay Sievers]

On Sun, Mar 6, 2011 at 10:01, Andrey Borzenkov <arvidjaar@mail.ru> wrote:
> Current wine is using /dev/sgX to access CD-ROM devices. Since
> distributions switched to using ACL instead of group membership
> to control device access, wine is not able to access them.
>
> Add ACL to device nodes that already get GROUP="cdrom".

sg is kind of deprecated and should really not be used anymore by
anything. Ideally we would start no even loading the module.

Who exactly depends on it and can not be fixed? Why does Fedora and
SUSE does not seem to have any problem the last couple of years?

Kay

Re: [PATCH] add ACLs to /dev/sgX nodes for CD-ROM

[Nicolas Pomarède]

Le 06/03/2011 16:33, Kay Sievers a écrit :
> On Sun, Mar 6, 2011 at 10:01, Andrey Borzenkov<arvidjaar@mail.ru>  wrote:
>> Current wine is using /dev/sgX to access CD-ROM devices. Since
>> distributions switched to using ACL instead of group membership
>> to control device access, wine is not able to access them.
>>
>> Add ACL to device nodes that already get GROUP="cdrom".
>
> sg is kind of deprecated and should really not be used anymore by
> anything. Ideally we would start no even loading the module.
>
> Who exactly depends on it and can not be fixed? Why does Fedora and
> SUSE does not seem to have any problem the last couple of years?
>
> Kay

Other distribs are also having problem with this :

gentoo : http://bugs.gentoo.org/321007

fedora 13 : http://bugs.winehq.org/show_bug.cgi?id#313

Wine's code is using /dev/sgX, I don't know if there're some patches 
around to change this.

It seems an usual fix is to add oneself to the cdrom group, but this is 
hardly an out of the box solution for a non technical user that would 
just install his linux distro of choice.

The fact that this problem is often related to users wanting to run 
protected games under Wine is certainly another reason why it didn't get 
much attention or fixes so far (in my case I want to access low level 
scsi functions with EAC).

Using acl in udev would provide a solution that automatically enables 
access to /dev/sgX for any logged user, without having to change /etc/group.

Nicolas

Re: [PATCH] add ACLs to /dev/sgX nodes for CD-ROM

[Kay Sievers]

On Sun, Mar 6, 2011 at 10:01, Andrey Borzenkov <arvidjaar@mail.ru> wrote:
> Current wine is using /dev/sgX to access CD-ROM devices. Since
> distributions switched to using ACL instead of group membership
> to control device access, wine is not able to access them.
>
> Add ACL to device nodes that already get GROUP="cdrom".

Applied.

Thanks,
Kay

Re: [PATCH] add ACLs to /dev/sgX nodes for CD-ROM

[Harald Hoyer]

Am 07.03.2011 16:23, schrieb Kay Sievers:
> On Sun, Mar 6, 2011 at 10:01, Andrey Borzenkov <arvidjaar@mail.ru> wrote:
>> Current wine is using /dev/sgX to access CD-ROM devices. Since
>> distributions switched to using ACL instead of group membership
>> to control device access, wine is not able to access them.
>>
>> Add ACL to device nodes that already get GROUP="cdrom".
> 
> Applied.
> 
> Thanks,
> Kay

Oh! You don't want to do this... Won't this allow ordinary users to flash a new
firmware, opening some security issues here?
Wasn't this, why cdrecord needed to be suid back in those days?
Wasn't this the reason for the filter for /dev/sr* in the kernel?

Re: [PATCH] add ACLs to /dev/sgX nodes for CD-ROM

[Kay Sievers]

On Mon, Mar 14, 2011 at 17:33, Harald Hoyer <harald@redhat.com> wrote:
> Am 07.03.2011 16:23, schrieb Kay Sievers:
>> On Sun, Mar 6, 2011 at 10:01, Andrey Borzenkov <arvidjaar@mail.ru> wrote:
>>> Current wine is using /dev/sgX to access CD-ROM devices. Since
>>> distributions switched to using ACL instead of group membership
>>> to control device access, wine is not able to access them.
>>>
>>> Add ACL to device nodes that already get GROUP="cdrom".

> Oh! You don't want to do this... Won't this allow ordinary users to flash a new
> firmware, opening some security issues here?
> Wasn't this, why cdrecord needed to be suid back in those days?
> Wasn't this the reason for the filter for /dev/sr* in the kernel?

Do we really don't want that? Locally logged-in users could put glue
in the tray too. :)

Kay

Re: [PATCH] add ACLs to /dev/sgX nodes for CD-ROM

[Karl O. Pinc]

On 03/14/2011 11:41:09 AM, Kay Sievers wrote:
> On Mon, Mar 14, 2011 at 17:33, Harald Hoyer <harald@redhat.com> 
> > Oh! You don't want to do this... Won't this allow ordinary users to
> flash a new
> > firmware, opening some security issues here?

> Do we really don't want that? Locally logged-in users could put glue
> in the tray too. :)

Has this been thought through?

Glue in the tray is a simple denial of service attack,
and one that affects but a single system component.
Flashing firmware, in theory at least, opens the door to 
installing malware right into the firmware and enables
all sorts of ugly possibilities starting with malware that
runs before the boot process even gets going,
can't be detected by scanning the drive, and can't be removed by
wiping the hard drive and power cycling.   It sounds scary if
an ordinary user, especially one not sitting next to
the box, can install such malware without any other
sort of privilege escalation.


Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein