Bug 321511

Summary:	No access to sgX device for DVD writer
Product:	[Fedora] Fedora	Reporter:	André Johansen <andrejoh>
Component:	udev	Assignee:	Harald Hoyer <harald>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	7
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-10-08 03:06:40 EDT	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Description André Johansen 2007-10-06 14:36:44 EDT

Description of problem:
My system has two SATA drives (sda and sdb) and a PATA DVD writer (scd0).
Permissions on the scd0 device are set correctly (i.e. desktop login gets 
access), but the same does not happen for the sgX device (sg2 in my case).

Version-Release number of selected component (if applicable):
udev-113-12.fc7

How reproducible:
Every time, unless running as root.

Steps to Reproduce:
1. Insert an audio CD into the optical drive.
2. $ cdparanoia -vsQ
3.
  
Actual results:
A lot of failure output, including the below, and no track listing.
Error trying to open /dev/sg2 exclusively (Permission denied). retrying in 1 
second.

Expected results:
Successful operation, including a track listing.
By default, it should be possible to rip audio CDs for a logged in desktop 
user.

Additional info:

Comment 1 Harald Hoyer 2007-10-08 03:06:40 EDT

A normal user cannot be granted write access to /dev/sg*. This would enable a
normal user to flash a new firmware and do similar bad things.

Comment 2 André Johansen 2007-10-08 03:31:20 EDT

What other solutions are there, then?  Having to login as root to rip a CD is 
no good, suid is even worse.

Searching on the net reveals that people do change permissions on the sgX 
device (not persistent with udev, but works).  Some burning programs also seem 
to have problems with this, according to the search results.

Comment 3 Harald Hoyer 2007-10-08 03:36:19 EDT

just use /dev/sr*

Comment 4 André Johansen 2007-10-09 09:31:39 EDT

On my Fedora 7/x86-64 (fresh install on new computer), there are no such 
devices.  I do get various symlinks (like /dev/dvdrw-sr0), but they all point 
to /dev/scd0.

And cdparanoia does not get anywhere further with that device:

$ cdparanoia -vQ -d /dev/dvdwriter-sr0
cdparanoia III release 9.8 (March 23, 2001)
(C) 2001 Monty <monty@xiph.org> and Xiphophorus

Report bugs to paranoia@xiph.org
http://www.xiph.org/paranoia/

Checking /dev/dvdwriter-sr0 for cdrom...
        Testing /dev/dvdwriter-sr0 for SCSI interface
Error trying to open /dev/scd0 exclusively (Device or resource busy). retrying 
in 1 second.
Error trying to open /dev/scd0 exclusively (Device or resource busy). retrying 
in 1 second.
Error trying to open /dev/scd0 exclusively (Device or resource busy). retrying 
in 1 second.
Error trying to open /dev/scd0 exclusively (Device or resource busy). retrying 
in 1 second.
Error trying to open /dev/scd0 exclusively (Device or resource busy). retrying 
in 1 second.
Error trying to open /dev/scd0 exclusively (Device or resource busy). retrying 
in 1 second.
Error trying to open /dev/scd0 exclusively (Device or resource busy). retrying 
in 1 second.
Error trying to open /dev/scd0 exclusively (Device or resource busy). retrying 
in 1 second.
Error trying to open /dev/scd0 exclusively (Device or resource busy). retrying 
in 1 second.
Error trying to open /dev/scd0 exclusively (Device or resource busy). retrying 
in 1 second.
                Could not access device /dev/scd0: Device or resource busy
        Testing /dev/dvdwriter-sr0 for cooked ioctl() interface
                /dev/scd0 is not a cooked ioctl CDROM.


Uhm, until I tried it again just now, and something obviously has made the 
device available for cdparanoia.  This is on a KDE desktop.  Any ideas of what 
might have caused the "resource busy" problem (digressing from the initial bug 
report, but this might lead to another or a bug transformation)?

(BTW, thanks for the help so far!)

Comment 5 Harald Hoyer 2007-10-09 09:36:41 EDT

yes, kde automount is polling, and only one application should read from the device.