Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 116026 - app-cdr/cdrtools - cdrecord fails to work properly w/o root privs or SUID bit set
Summary: app-cdr/cdrtools - cdrecord fails to work properly w/o root privs or SUID bit...
Status: RESOLVED UPSTREAM
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: optical media herd
URL:
Whiteboard:
Keywords:
: 187056 195546 198371 204982 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-12-19 04:02 UTC by Sebastian Roeder
Modified: 2008-06-06 23:20 UTC (History)
10 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Roeder 2005-12-19 04:02:36 UTC
I never quite understood this, but I need read/write permissions to /dev/sg0 (which refers to my hard disc) as user, to burn CDs with cdrecord/k3b. 

dmesg:
-----
sd 0:0:0:0: Attached scsi disk sda
sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
sr 1:0:0:0: Attached scsi CD-ROM sr0
sd 0:0:0:0: Attached scsi generic sg0 type 0
sr 1:0:0:0: Attached scsi generic sg1 type 5

/dev looks like:
----------------

# ls -al /dev/sg*
crw-rw----  1 root root  21, 0 Dec 19  2005 /dev/sg0
crw-rw----  1 root cdrom 21, 1 Dec 19  2005 /dev/sg1
# ls -al /dev/sr*
brw-rw----  1 root cdrom 11, 0 Dec 19  2005 /dev/sr0

cdrecord error log:
------------------

scsidev: '1,0,0'
scsibus: 1 target: 0 lun: 0
/usr/bin/cdrecord: Permission denied. Cannot open '/dev/sg0'. Cannot open SCSI driver.

When I change the group of /dev/sg0 to e.g. cdrom (in which my user is included) everything works as expected. So please change the permissions to /dev/sg0 to something resonable with udev. Thanks in advance!
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2005-12-19 04:21:46 UTC
(In reply to comment #0)
> When I change the group of /dev/sg0 to e.g. cdrom (in which my user is
> included) everything works as expected. So please change the permissions to
> /dev/sg0 to something resonable with udev. Thanks in advance!

What do you mean reasonable? root:root is perfectly fine for hard drives. Either incorrect k3b setup or k3b bug, there's nothing wrong with permissions set by udev.
Comment 2 Sebastian Roeder 2005-12-19 04:39:54 UTC
(In reply to comment #1)
> What do you mean reasonable? root:root is perfectly fine for hard drives.
> Either incorrect k3b setup or k3b bug, there's nothing wrong with permissions
> set by udev.

For hard drives yes, but for the generetic device that belongs to the hard drive, too?

The "reasonable" wasn't meent to be offensive but I wanted to point out, that my approach (the cdrom group) is not a clean solution of cause and I want to leave the decision how to fix this to people how know more about the topic.

It's not a KDE problem I would say, cause it's cdrecord that complains. And yes, cdrecord often caused problems cause the kernel devels and the cdrecord devel don't like to work together I think. But how else but in changing the device permissions should we solve this problem? Remember that cdrecord doesn't work anymore with suid.

If you are on an IDE system and you are able to burn as user, you might give me some infos about your system setup. Maybe it's SATA related?

OK, I hope we can find a solution that lets non-root users burn CDs without opening huge securety issues. 

Comment 3 Jakub Moc (RETIRED) gentoo-dev 2006-01-13 18:55:50 UTC
(In reply to comment #2)
> For hard drives yes, but for the generetic device that belongs to the hard
> drive, too?
> 
> The "reasonable" wasn't meent to be offensive but I wanted to point out, that
> my approach (the cdrom group) is not a clean solution of cause and I want to
> leave the decision how to fix this to people how know more about the topic.

I really don't see how is this an udev issue:

crw-rw----  1 root root  21, 0 Dec 19  2005 /dev/sg0

^^^ is a hard drive, permissions correct;

crw-rw----  1 root cdrom 21, 1 Dec 19  2005 /dev/sg1
# ls -al /dev/sr*
brw-rw----  1 root cdrom 11, 0 Dec 19  2005 /dev/sr0

are cdrom/cd writer devices, again permissions are correct. 

Sorry, but cdrecord/k3b/whatever being stupid and wanting to burn to hard drive instead of CD burner is anything but udev bug.
Comment 4 Sebastian Roeder 2006-01-19 05:34:52 UTC
OK, then it is not an udev issue - but it is still an issue :-( Can we leave this bug open and assign it to cdrecord or how can we deal with the problem?

I had a little discussion with another Dell Inspiron 6000 owner in the forum:
http://forums.gentoo.org/viewtopic-t-397496-highlight-.html

###### Here is a short summary of our observations:

CinzC wrote: Something I've wondered for long: when I try to burn a CD under Gnome with Nautilus I always had to allow write access on /dev/sg0 although the CD writer is attached to /dev/sr0. What is really wierd is that the (SATA) hard disk is attached to /dev/sg0 and the CD writer is attached to /dev/sg1.

Me wrote: What about the following test configuration: deleting /dev/sg0 and creating a symlink to /dev/sg1 instead. When burning still works then cdrecord is realy confused with the scsi busses and doesn't need access to the hard disk scsi bus. If not then this access is truely needed and permissions should be handled "correctly" by udev.

VinzC wrote: I don't believe this will work in fact - though I'm curious giving it a try. I suspect cdrecord looks for a SCSI device capable of burning. And remember we checked SCSI CDROM support in the kernel although the CDROM device is actually IDE, connected to a SATA controller. Hence cdrecord uses sg0 instead of sg1. This is my feeling rather than an actual observation. Things might be more complicated than expected in fact. Or I haven't understood anything, which is also quite possible :-).

Me wrote: It appears that you are right. Indead there is no access to the scsi bus for the hd needed - the linking stuff described above works perfectly well. 
Even stranger it works entirely without /dev/sg0 (delete it) ... So it looks like it is a cdrecord problem but I do not realy understand why it insists on using sg0 and sg1 ... What's the next step? Changing my bug report to be against cdrecord (which is a dead project)? Hopefully the Gentoo devs can fix this!

######## End of forum discussion summary

OK, my conclusion is that cdrecord needs rw permissions for the sgX device that belongs to the cdrecorder and that this sgX is created with the proper permissions by udev. But cdrecord is to silly to distinguish between the sgX from the cdrecorder and the sgX from my harddisk. The sgX from harddisk cames first in the naming sceme (sg0) and has permissions that are typical for HDs but not suffisant for cdburning. Now cdrecord takes this first sgX as the one it needs for burning and complains about wrong permissions. Question here: is the sgX for harddisks neeeded at all in the system or is it a fault that it is created? When I delete sg0 (sgX for the hd) then cdrecord works as expected - I guess it then finds sg1 finally which is sgX for the cdrecorder.

Hope that helps somehow.    
Comment 5 Carsten Lohrke (RETIRED) gentoo-dev 2006-01-20 09:32:37 UTC
Obviously not a KDE issue. 
Comment 6 Lars Weiler (RETIRED) gentoo-dev 2006-02-04 06:39:47 UTC
Can you give an example how you call cdrecord?
Comment 7 Lars Wendler (Polynomial-C) gentoo-dev 2006-02-10 07:52:38 UTC
Hi,

I'm also affected by this problem on a machine with real SCSI-devices.
Here's what I found out:
Using cdrecord the way its author prefers it doesn't work as user:

> cdrecord -atip -dev=0,4,0
Cdrecord-Clone 2.01.01a01 (i686-pc-linux-gnu) Copyright (C) 1995-2004 J
Comment 8 Lars Wendler (Polynomial-C) gentoo-dev 2006-02-10 07:52:38 UTC
Hi,

I'm also affected by this problem on a machine with real SCSI-devices.
Here's what I found out:
Using cdrecord the way its author prefers it doesn't work as user:

> cdrecord -atip -dev=0,4,0
Cdrecord-Clone 2.01.01a01 (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling
cdrecord: Warning: Running on Linux-2.6.13.5-mh2
cdrecord: There are unsettled issues with Linux-2.5 and newer.
cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris.
TOC Type: 1 = CD-ROM
scsidev: '0,4,0'
scsibus: 0 target: 4 lun: 0
cdrecord: Permission denied. Cannot open '/dev/sg0'. Cannot open SCSI driver.
cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root.
cdrecord: For possible transport specifiers try 'cdrecord dev=help'.

But using -dev=/dev/sg3 instead of -dev=0,4,0 works as user:

> cdrecord -atip -dev=/dev/sg3
Cdrecord-Clone 2.01.01a01 (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling
cdrecord: Warning: Running on Linux-2.6.13.5-mh2
cdrecord: There are unsettled issues with Linux-2.5 and newer.
cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris.
TOC Type: 1 = CD-ROM
scsidev: '/dev/cdrecorder'
devname: '/dev/cdrecorder'
scsibus: -2 target: -2 lun: -2
Warning: Open by 'devname' is unintentional and not supported.
Linux sg driver version: 3.5.33
Using libscg version 'schily-0.8'.
SCSI buffer size: 64512
atapi: 0
Device type    : Removable CD-ROM
Version        : 2
Response Format: 2
Capabilities   : SYNC LINKED
Vendor_info    : 'PLEXTOR '
Identifikation : 'CD-R   PX-W124TS'
Revision       : '1.07'
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC SWABAUDIO
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
Drive buf size : 2373168 = 2317 KB
Drive DMA Speed: 16209 kB/s 92x CD 11x DVD
Current Secsize: 2048
ATIP info from disk:
  Indicated writing power: 4
  Is not unrestricted
  Is not erasable
  Disk sub type: Medium Type A, high Beta category (A+) (3)
  ATIP start of lead in:  -11077 (97:34/23)
  ATIP start of lead out: 359848 (79:59/73)
Disk type:    Long strategy type (Cyanine, AZO or similar)
Manuf. index: 11
Manufacturer: Mitsubishi Chemical Corporation

Now what does k3b? I think it's using the -dev=x,y,z method to specify the device as the errormessage given by cdrecord thru k3b is the same as using cdrecord -dev=0,4,0 on the commandline...

Cheers
Poly
Comment 9 Lars Wendler (Polynomial-C) gentoo-dev 2006-02-10 07:57:46 UTC
Additional information:

the /dev/cdrecorder comes from a custom udev-rule I've written:

BUS=="scsi", KERNEL=="sg[0-9]*", SYSFS{model}=="CD-R   PX-W124TS", GROUP:="cdrw", SYMLINK="scd%n cdrecorder"

Poly
Comment 10 Luis Medinas (RETIRED) gentoo-dev 2006-03-25 10:51:34 UTC
still have the same problem with alpha 07 ?
Comment 11 Lars Wendler (Polynomial-C) gentoo-dev 2006-04-04 15:17:04 UTC
Yes, the error is still present in alpha07.
Comment 12 Andrei Alechin 2006-05-11 17:23:25 UTC
I'm also getting an issue where K3b complains of cdrecord not running as root. I tried dropping back to cdrecord itself, but it's throwing up an error about permissions when I try to "cdrecord -scanbus":

Cdrecord-Clone 2.01.01a06 (i686-pc-linux-gnu) Copyright (C) 1995-2006 J
Comment 13 Andrei Alechin 2006-05-11 17:23:25 UTC
I'm also getting an issue where K3b complains of cdrecord not running as root. I tried dropping back to cdrecord itself, but it's throwing up an error about permissions when I try to "cdrecord -scanbus":

Cdrecord-Clone 2.01.01a06 (i686-pc-linux-gnu) Copyright (C) 1995-2006 Jörg Schilling
cdrecord: Permission denied. Cannot open '/dev/sg0'. Cannot open SCSI driver.
cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root.
cdrecord: For possible transport specifiers try 'cdrecord dev=help'.

(My writer is a Plextor PX-716A, on Secondary IDE/Slave. I don't have any SCSI devices or controllers attached to my computer.)
Comment 14 Lars Weiler (RETIRED) gentoo-dev 2006-05-12 09:48:43 UTC
(In reply to comment #11)
> permissions when I try to "cdrecord -scanbus":

You have to name the bus it should scan.  Try cdrecord dev=ATA -scanbus
Comment 15 Andrei Alechin 2006-05-13 07:35:54 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > permissions when I try to "cdrecord -scanbus":
> 
> You have to name the bus it should scan.  Try cdrecord dev=ATA -scanbus
> 

Thanks, that scanned my writer correctly. Also gave me a comedy warning: "Using badly designed ATAPI via /ev/hd* interface."
Comment 16 Lars Wendler (Polynomial-C) gentoo-dev 2006-09-26 12:01:06 UTC
app-cdr/cdrkit suffers from the same problem. As it seems to be more likely that rather the cdrkit-devs would fix this instead of J
Comment 17 Lars Wendler (Polynomial-C) gentoo-dev 2006-09-26 12:01:06 UTC
app-cdr/cdrkit suffers from the same problem. As it seems to be more likely that rather the cdrkit-devs would fix this instead of Jörg "I-am-the-ultimate-unfailable-god-of-cdburning-apps-and-you-have-no-clue-about-anything-in-life" Schilling, maybe we should report this bug to the cdrkit-devs?

Cheers
Poly-C
Comment 18 Peter Sääf 2006-10-17 11:37:12 UTC
I have a similar problem, if not the same. This works for me:
http://qa.mandriva.com/twiki/bin/view/Main/MandrivaLinux2006ReleaseNotes#Plextor_burner

Maybe not the best solution. 
Comment 19 Lars Weiler (RETIRED) gentoo-dev 2006-10-28 01:16:12 UTC
(In reply to comment #15)
> I have a similar problem, if not the same. This works for me:
> http://qa.mandriva.com/twiki/bin/view/Main/MandrivaLinux2006ReleaseNotes#Plextor_burner
> 
> Maybe not the best solution. 

Well.  I don't want to install cdrtools with suid-root by default.  But I think about adding an einfo-note to the ebuild.
Comment 20 Lars Weiler (RETIRED) gentoo-dev 2006-12-02 19:14:24 UTC
I think this bug has been resolved in the latest cdrkit-version.  Can you test please?
Comment 21 Sebastian Roeder 2006-12-03 01:25:52 UTC
Dear Lars,

I apprechiate to work that is done both in cdrkit upstream and in your efforts to get in into portage. I'll try to get a cdrkit setting up and running here in the next ~ 2 weeks but to be honest I am a little concerned whether it is ready for prime time yet. I usualy prefer the stable portage tree ;) (I read your post on the planet one minute ago) My question is what do you mean by latest cdrkit? Is 1.0 enough or do we need 1.1?
Comment 22 Lars Wendler (Polynomial-C) gentoo-dev 2006-12-03 03:12:20 UTC
Hello Lars,

I'll give cdrkit-1.0 a try as soon as I'm at my SCSI machine again.

Cheers
Poly-C
Comment 23 Peter Sääf 2006-12-03 06:40:44 UTC
I can confirm that using cdrkit instead of cdrtools fixes this for me. Thanks.
Comment 24 Lars Weiler (RETIRED) gentoo-dev 2006-12-03 07:05:08 UTC
(In reply to comment #18)
> My question is what do you mean by latest cdrkit? Is 1.0 enough or do we need 1.1?

Please test cdrkit-1.0 first, as this one will be stabilised soon (this month).  If it works, report back.  Otherwise test cdrkit-1.1.0 and report the status.

Comment 25 Lars Weiler (RETIRED) gentoo-dev 2006-12-03 07:15:06 UTC
(In reply to comment #20)
> I can confirm that using cdrkit instead of cdrtools fixes this for me. Thanks.

Which version of cdrkit?
Comment 26 Peter Sääf 2006-12-03 07:46:47 UTC
>Which version of cdrkit?

cdrkit-1.0 at first. cdrkit-1.1.0 now. Both seem to be working fine with regard to the permissions problem.
Comment 27 Lars Wendler (Polynomial-C) gentoo-dev 2006-12-04 09:56:45 UTC
HI,

the same here. Both, version 1.0 and version 1.1.0 are working perfectly with regard to the permission problem. I did several testburns on my Plextor PX-W124TS with both versions and all succeeded.
Thanks for your work on this Lars...

Cheers
Poly-C
Comment 28 Lars Wendler (Polynomial-C) gentoo-dev 2007-05-29 00:27:34 UTC
app-cdr/cdrkit doesn't have this problem as some of us here already told. How about closing this bug with recommendation to use cdrkit instead of cdrtools?
Comment 29 Jakub Moc (RETIRED) gentoo-dev 2007-05-29 05:55:10 UTC
cdrkit-1.1.2 is stable now, use it.
Comment 30 Jakub Moc (RETIRED) gentoo-dev 2007-07-29 19:25:00 UTC
*** Bug 187056 has been marked as a duplicate of this bug. ***
Comment 31 Fabio Rossi 2007-08-02 13:47:40 UTC
The problem with cdrecord is now resolved with the upgrade to wodim. But there is still the same problem with cdrdao...
Comment 32 Jakub Moc (RETIRED) gentoo-dev 2007-10-11 21:34:29 UTC
*** Bug 195546 has been marked as a duplicate of this bug. ***
Comment 33 Jakub Moc (RETIRED) gentoo-dev 2007-11-07 16:51:11 UTC
*** Bug 198371 has been marked as a duplicate of this bug. ***
Comment 34 Jakub Moc (RETIRED) gentoo-dev 2008-01-09 07:59:04 UTC
*** Bug 204982 has been marked as a duplicate of this bug. ***
Comment 35 Carsten Lohrke (RETIRED) gentoo-dev 2008-01-09 16:12:04 UTC
Reopening this bug, given that cdrkit is apparently in low maintenance mode, according to upstream activity and also using cdrkit doesn't fix cdrtools issues.
Comment 36 Jakub Moc (RETIRED) gentoo-dev 2008-01-09 16:36:01 UTC
(In reply to comment #35)
> Reopening this bug, given that cdrkit is apparently in low maintenance mode,
> according to upstream activity and also using cdrkit doesn't fix cdrtools
> issues.

I really don't see what you are expecting here?!  Jörg Schilling refuses to fix his stuff, blames kernel developers, his "fix" being "install cdrecord suid-root" (which is completely unneeded as cdrkit proves) - and instead of fixing a blatant bug in the product he's bashing distros that fix his buggy code with friendly notes about "bastardized and defective variants".

http://cdrecord.berlios.de/private/cdrecord.html
Comment 37 Carsten Lohrke (RETIRED) gentoo-dev 2008-01-09 19:50:42 UTC
Jörg Schilling is indeed a problematic guy, but that doesn't fix that people use cdrtools, Jakub. And at the pace cdrkit is moving, don't expect that to change.