cdrecord and suid

[Guinpen]

Hi,

When running cdrecord as a user, I get:

Code: Select all

$ cdrecord /dev/sr0
cdrecord: No write mode specified.
cdrecord: Assuming -sao mode.
cdrecord: If your drive does not accept -sao, try -tao.
cdrecord: Future versions of cdrecord may have different drive dependent defaults.
Cdrecord-ProDVD-ProBD-Clone 2.01.01a66 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2009 Jörg Schilling
cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler.
Linux sg driver version: 3.5.34
Using libscg version 'schily-0.9'.
No target specified, trying to find one...
Using dev=1,0,0.
Device type    : Removable CD-ROM
Version        : 5
Response Format: 2
Capabilities   :
Vendor_info    : 'HL-DT-ST'
Identifikation : 'DVD-RAM GH22LS30'
Revision       : '1.00'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Using generic SCSI-3/mmc-3 DVD+RW driver (mmc_dvdplusrw).
Driver flags   : NO-CD DVD MMC-3 SWABAUDIO BURNFREE
Supported modes: PACKET SAO LAYER_JUMP
cdrecord: Track 1 has unknown length.
cdrecord: Use tsize= option in SAO mode to specify track size.

Note the warning about setting the RR-scheduler. Running with sudo does not show this warning.

The solution described in hundreds of places is setting cdrecord as suid with "sudo chown u+s /usr/bin/cdrecord". But my cdrecord is already suid!

Code: Select all

-rws--x--x 1 root bin 306128 2009-10-16 01:01 /usr/bin/cdrecord

So what am I missing?

Note: I am aware of the security implications of setting cdrecord as suid, so let's ignore those for the time being.

Thanks!

[Guinpen]

Anyone?

[i92guboj]

Try "emerge -C cdrtools && emerge cdrkit" better.

[Guinpen]

As far as I know, cdrkit is a a fork created for licensing reasons, which is technically inferior and not maintained much. Most distributions use cdrtools, so I'm willing to trust that better.

In any case, my questions still stands. What is the technical difference between running something that is SUID root and running something that is SUID root with sudo?

[i92guboj]

As far as I know, cdrkit is a a fork created for licensing reasons, which is technically inferior and not maintained much. Most distributions use cdrtools, so I'm willing to trust that better.

Yeah, I know all that stuff. However I've been having similar problems lately with k3b, with similar output in the logs, I couldn't even burn a dvd today. I followed that path and suddenly it worked again. I don't care about politics, I want to burn a disk once in a month without having to read a book each time I need to burn a damn disk. Lately this is becoming an Odyssey in Gentoo. The main problem is that, for the amount of disks I burn I really refuse to look into this issues. I already have a lot of things to worry about and almost no time to attend them all.

Besides that, I am really not sure which of them is better maintained. Both home pages are really ancient. But that's for another topic.

[SamuliSuominen]

In any case, my questions still stands. What is the technical difference between running something that is SUID root and running something that is SUID root with sudo?

cdrtools bundle a code that's checking if the binary is suid or not, and if it's not, you won't be able to see the device list properly.

otherwise there wouldn't be a difference.

(note: it's been like few months if not a year since i've last checked this)

and yeah, cdrtools is the preferred one in gentoo because cdrkit doesn't work for everyone at all.

[Guinpen]

cdrtools bundle a code that's checking if the binary is suid or not, and if it's not, you won't be able to see the device list properly.

The binary is suid. My question is the difference between running:
1) the suid binary as user (directly)
2) the suid binary with sudo

I believe there should be no difference, but 1) gives me "cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler. ", while 2) does not. That's the phenomenon I'm trying to understand.

[i92guboj]

and yeah, cdrtools is the preferred one in gentoo because cdrkit doesn't work for everyone at all.

Well.....

The owner of this thread and I are witnesses that cdrtools don't work for everyone at all, either There are more at Google surely.

[Guinpen]

Oh, don't get me wrong. Cdrecord works perfectly (it did NOT work on k3b 1.0 alpha2, but it did work after an upgrade to alpha3, without touching cdrecord).

This whole thread exists so that I can find out the answer of the fundamental UNIX question of why sudo makes a difference on a suid binary - since common sense tells me the application should be running as root due to the suid, whether I use sudo or not.

Destipe the cdrecord message, cdrtools burns fine

[Guinpen]

Anyone?

[ratthing]

The only difference I would think, between using sudo and running as root, is that sudo will not have root's environment unless you explicitly 'sudo su -' (or the equiv, 'sudo -s'? I don't remember) to get root's login environment. I'd try comparing that to your own env, see what differences exist.

=RT=

[Draco-LVNH]

Add me to the count..... cdrkit worked better for me, cdrecord also gave me an error and installing cdrkit solved the problem for me.

I am also tired of hearing of licensed things and all that, like when KDE was marked as the ugly duck because the licence of Qt, people just used to say that and do not give KDE a chance just because of that, at least I think that is a topic of the past.

Some people should be a little more open, if you do not accept software because it's licence is not GPL then you are not different from the Windows' users who are closed to say that Windows and Microsoft are everything and anything else is "bad and sucks".

Let us have more open minds and use things that solve our problems and if the neighbor uses a different tool then it's the neighbor live and let us keep going.