Bug 88512 - problems if other sgX not writeable
Summary: problems if other sgX not writeable
Status: CLOSED DUPLICATE of bug 90565
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: nautilus-cd-burner
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-10 16:31 UTC by Gérard Milmeister
Modified: 2007-04-18 16:52 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-02-21 18:52:36 UTC

Attachments (Terms of Use)
output of nautilus-cd-burner (199.51 KB, image/png)
2003-04-18 20:12 UTC, Gérard Milmeister
no flags Details
Patch for nautilus-cd-burner-0.4.3 (from rawhide) (878 bytes, text/plain)
2003-06-26 16:34 UTC, John Franks
no flags Details

Description Gérard Milmeister 2003-04-10 16:31:42 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686) Gecko/20030313 Galeon/1.3.3

Description of problem:
In order to use nautilus-cd-burner, it must be run as root for cdrecord to work.
However I think it is generally a bad idea to run nautilus as run from a user
account. In order to make it work I set cdrecord suid. I knew this, but somehow
I expected it to work out of the box. There is no hint in the Red Hat
documentation as far as I a can acertain. So currently nautilus-cd-burner is of
little use to a normal user, isn't it?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Additional info:

Comment 1 Alexander Larsson 2003-04-15 10:06:44 UTC
kudzu is suppoed to make a /dev/cdwriter symlink, and cdwriter is listed in
/etc/security/console.perms, so a console login should have gotten write
permissions to the cd writer.

Didn't this happen?

Comment 2 Gérard Milmeister 2003-04-15 18:45:01 UTC
I have

lrwxrwxrwx    1 root     root            8 Apr  8 04:21 cdwriter -> /dev/sg1
crw-------    1 gemi     disk      21,   1 Jan 30 11:24 /dev/sg1

and in console.perms

<cdrom>=/dev/cdrom* /dev/cdroms/* /dev/cdwriter* /mnt/cdrom*

so this seems to be ok, but the error output is:

cdrecord: For possible transport specifiers try 'cdrecord dev=help'.
cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root.
cdrecord: Permission denied. Cannot open '/dev/sg0'. Cannot open SCSI driver.
scsibus: 1 target: 0 lun: 0
scsidev: '1,0,0'
cdrecord: WARNING: This causes a high risk for buffer underruns.
cdrecord: Permission denied. WARNING: Cannot set priority using setpriority().
cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler
cdrecord: WARNING: This causes a high risk for buffer underruns.
cdrecord: Operation not permitted. WARNING: Cannot do mlockall(2).

Here, the problem is /dev/sg0 instead of /dev/sg1.
I also had the impression, that in order to access the CD-Writer via scsi
commands, cdrecord would have to be run as root, and that making the device
writable would not be sufficient. Also, why must gtoaster be run still as root?

Comment 3 Gérard Milmeister 2003-04-15 19:18:12 UTC
I think I found the problem.

cdrecord -scanbus displays:
	0,6,0	  6) 'IOMEGA  ' 'ZIP 100         ' 'J.03' Removable Disk
	1,0,0	100) 'PLEXTOR ' 'CD-R   PX-320A  ' '1.05' Removable CD-ROM

scanbus seems to scan one scsi device after another.
However the first one (zip drive /dev/sg0) has no user privileges (but /dev/sda)
has, so it seems that the second one (/dev/sg1) is not found by cdrecord.
If I set the required permissions on /dev/sg0, the burning works!
So /dev/sg0 must also be present in console.perms.
BTW when are the permission from console.perms set?

Comment 4 Alexander Larsson 2003-04-16 10:03:24 UTC
Hmmm. I don't get it, the fact that it couldn't open /dev/sg0 shouldn't matter.
Well, it might warn some, but the actual writing is to sg1, which should work.
And indeed, after the sg0 warning it prints "scsidev: '1,0,0'", which is right.

You only need to be root to set realtime priority, which isn't strictly
necessary. Especially on modern machines.

Comment 5 Gérard Milmeister 2003-04-18 20:09:00 UTC
Well I changed back to:
crw-rw----    1 root     disk      21,   0 Jan 30 11:24 /dev/sg0

I attach a screenshot of a session.

Comment 6 Gérard Milmeister 2003-04-18 20:12:42 UTC
Created attachment 91192 [details]
output of nautilus-cd-burner

Comment 7 Alexander Larsson 2003-04-22 08:52:23 UTC
Strange, but i think it should be fixable.

Comment 8 John Franks 2003-06-26 07:24:00 UTC
The problem is with the way cdrecord works.  If /dev/sg0 is a SCSI
drive (e.g. sda) and /dev/sg1 is the cdwriter then cdrecord requires
permission to sg0 (i.e. the hard drive) when it writes to sg1.  This
is true when it is invoked as

  cdrecord dev=x,x,x [whatever]

But if it is invoked as

  cdrecord dev=/dev/sg1:x,x,x [whatever]

then it works without needing access to sg0!  Apparently without
the devicename is accesses sg* in order and quits if it does not
have permission.
At least I have tested this with the commands

  cdrecord dev=1,0,0 driveropts=help -checkdrive
  cdrecord dev=/dev/sg1:1,0,0 driveropts=help -checkdrive

The fix for nautilus-cd-burner should be to use cdrecord with
dev=<devicename>:scsibus,target,lun instead of just

Comment 9 John Franks 2003-06-26 16:34:24 UTC
Created attachment 92633 [details]
Patch for nautilus-cd-burner-0.4.3 (from rawhide)

This is a patch to the version of nautilus-cd-burner from rawhide.  I think it
fixes the problem that requires a user to have permissions to /dev/sg* if the
cdwriter is /dev/sgx where x > 0.  I have not tested this much.  Use at your
own risk!

A similar change could be made to the RH9 version of nautilus-cd-burner to get
it to work for non-root users when a SCSI hard drive is present.

Comment 10 John Franks 2003-06-26 19:14:20 UTC
Comment on attachment 92633 [details]
Patch for nautilus-cd-burner-0.4.3 (from rawhide)

The attachment was bad I deleted it.

Comment 11 John Franks 2003-06-27 17:47:12 UTC
This bug is a duplicate of 90656 which has been fixed and closed.  Installation
of the current rawhide version of cdrecord will solve the problem.

Comment 12 Alexander Larsson 2003-07-04 12:31:31 UTC
What? 90656 is a amd64 SATA bug, it doesn't seem related at all. Did you mean
another bug?

Comment 13 John Franks 2003-07-04 13:50:07 UTC
Sorry, that should have been bug #90565.

Comment 14 Alexander Larsson 2003-07-07 09:42:36 UTC

*** This bug has been marked as a duplicate of 90565 ***

Comment 15 Red Hat Bugzilla 2006-02-21 18:52:36 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.