cdrecord doesn't work with gentoo-dev-sources-2.6.9-r1. In 2.6.8-r10 everything works fine. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Can't verify. It works fine here for me on 2.6.9. Could you give detailed information about the problem and your output of emerge info?
$ uname -sr Linux 2.6.9-gentoo-r1 I use external usb Lite-on DVD-RW. $ cdrecord -dev=0,0,0 -blank=fast Cdrecord-Clone 2.01 (i686-pc-linux-gnu) Copyright (C) 1995-2004 JЖrg Schilling cdrecord: Warning: Running on Linux-2.6.9-gentoo-r1 cdrecord: There are unsettled issues with Linux-2.5 and newer. cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris. cdrecord: Warning: Linux-2.6.8 introduced incompatible interface changes. cdrecord: Warning: SCSI transport does no longer work for suid root programs. cdrecord: Warning: if cdrecord fails, try to run it from a root account. scsidev: '0,0,0' scsibus: 0 target: 0 lun: 0 Linux sg driver version: 3.5.31 Using libscg version 'schily-0.8'. cdrecord: Cannot allocate memory. Cannot get SCSI I/O buffer. If do same thing as root cdrecord works fine. But under 2.6.8-r10 I can do this as normal user, not root
I confirm - same here. This bug is well known and occurs because of the changes made in 2.6.9-rc4 regarding some scsi issues (now applications that want to use it must be run directly by root.. suid bit doesn't help much here). I hope that gentoo kernel maintainers will give us a properly patched release of gentoo-dev-sources. The other way is to patch cdrecord... I've found a patch for cdrtools-2.01a38 on kerneltrap.org. You can find it in this thread: http://kerneltrap.org/node/view/4022 Although I didn't try this out personally, some people reported that this patch actually kills the bug ;]. However - as you have probably already noticed - this is a patch for the 2.01a38 version only... Most probably it won't apply succesfuly on the final release. Maybe someone could rewrite it? :)
Created attachment 42797 [details, diff] Fix for cdrecord dropping priviledges This is based on the patch at http://kerneltrap.org/node/view/4022 - I hand patched the source and modified the ebuild to test it with the generated patch.
I patched cdrecord manually... it works fine now :) Did you post the new ebuild into portage?
When will that patch appear in portage?
For security reasons I don't like to add the patch into portage, as this affects all users and not only those with USB or IEEE1394 burners. A solution to your problem might be the newly added ebuild sys-apps/resmgr, which runs as a daemon and drops configured permissions to users. That it worked on 2.6.8-r10 was a deal with the Gentoo kernel-maintainers to include a patch similar to the attached one here, but it should be resolved with a newer kernel. So, it works again on built-in burners, but not on externals. I can add a dependency on usb or ieee1394 use-flag to resmgr, if that works. I can't test it here as I only own a built-in DVD-writer. So, please test sys-apps/resmgr and if it resolves your problem!
OK... I will test this... However, I don't own neither USB nor firewire burner... I have an internal CD recorder.
Well, tests failed... I still get the `/usr/bin/cdrecord: Cannot allocate memory. Cannot get SCSI I/O buffer.' error message. I've emerged resmgr, edited resmgr.conf as follows: -- BEGIN -- hell root # cat /etc/resmgr.conf # This is the default set of devices people logged in on the desktop get # access to: class desktop # # Standard multimedia devices add /dev/audio desktop add /dev/mixer desktop add /dev/dsp desktop add /dev/sequencer desktop add /dev/video desktop # # CD-ROMs - giving permission to open the corresponding SCSI # device is highly useful for CD writers such as cdrecord. add /dev/cdrom desktop scsi add /dev/cdroms/cdrom0 desktop scsi add /dev/ide/host0/bus1/target0/lun0/cd desktop scsi add /dev/dvd desktop scsi add /dev/cdroms/cdrom1 desktop scsi add /dev/ide/host0/bus1/target1/lun0/cd desktop scsi add /dev/sr0 desktop scsi add /dev/sr1 desktop scsi add /dev/sr2 desktop scsi add /dev/sr3 desktop scsi # # Dito for SCSI scanners, which all use /dev/scanner symlink. add /dev/scanner desktop scsi # # And USB scanners. add /dev/usbscanner desktop add /dev/usb/scanner desktop add /dev/usb/scanner0 desktop add /dev/usb/scanner1 desktop add /dev/usb/scanner2 desktop add /dev/usb/scanner3 desktop add /dev/usb/scanner4 desktop add /dev/usb/scanner5 desktop add /dev/usb/scanner6 desktop add /dev/usb/scanner7 desktop # # make /dev/console accessible read-only add /dev/console desktop read-only # For serial gphoto cameras. # add /dev/ttyS0 desktop # add /dev/ttyS1 desktop # # Sample rules, do not enable by default: # # This rule denies access to users uucp and news # # deny desktop user=uucp || user=news # # This rule gives access to all members of group wheel # # allow desktop group=wheel # # This rule grants access to users logged in locally # allow desktop tty=/dev/tty[1-9]* || tty=:0 -- END -- Then I ran /etc/init.d/resmgr start script: hell root # ps auxww |grep resmgr root 5725 0.0 0.0 1364 444 ? Ss 13:44 0:00 /sbin/resmgrd -- root 5783 0.0 0.0 3668 596 pts/1 S+ 13:47 0:00 grep resmgr
bump
with kernel-2.6.9-vanilla and cdrtools-2.01, strange things happen: run cdrecord as root --> works cdrecord setuid, run as user --> fails with "Cannot allocate memory. Cannot get SCSI I/O buffer." cdrecord not setuid, run as user --> works! cdrecord setuid, run as user under strace --> works!!! can anyone confirm?
*** Bug 69863 has been marked as a duplicate of this bug. ***
>>>cdrecord setuid, run as user under strace --> works!!! could you please give me the exact command to test? I can confirm everything else (see my bug report for details).
with cdrecord permissions at 4711: "cdrecord dev=/dev/hdc somefile" gives the error, while "strace -ostrace.log cdrecord dev=/dev/hdc somefile" works
Yeah, I can confirm... this is weird. Exactly as you have said: >> run cdrecord as root --> works >> cdrecord setuid, run as user --> fails with "Cannot allocate memory. Cannot get >> SCSI I/O buffer." >> cdrecord not setuid, run as user --> works! >> cdrecord setuid, run as user under strace --> works! The strace thing is odd :-P
Okay. That's very odd. I don't know what happens when you run it with strace. But I would say, as long as you can run it as user non-setuid it would be still fine. For security reasons I ever suggest not to install any program setuid root. Is it okay with you to close this bug with WORKSFORME or do you need cdrecord set setuid root?
I _need_ it to run with priority -20, or else I'll risk getting buffer underruns most of the times I do anything else, like opening my file manager or stupid stuff like that.
Hmm... I don't need suid bit set on cdrecord executable. Frankly, I really don't care: if there is such a need of suid, I set it. If not, then not. I have no objections - you can close the bug with WORKSFORME resolution. I've already posted a message to k3b developers regarding this issue.
Confirm that for me the workaround was to remove the setuid bit from cdrecord and cdrdao...
well ... I recently migrated (using the Gentoo 2.4 -- 2.6 migration guide) from 2.4.25 to 2.6.10-r2. This started happening on my built-in CD-RW with both K3B and xcdroast. I got K3B to work by removing the SUID bit from "cdrecord" and "cdrdao". I have *not* tested xcdroast, and don't plan to immediately; I only use xcdroast to do CD-CD copies with verification.
Still, cdrecord and cdrdao will be installed without suid bit set. k3b has a einfo, that informs you about not setting that bit. And usually it does not touch the bit and the warning message is also removed. Everything should be fine.
Maybe there's something I'm really missing. Is it supposed to be "fine" to run cdrecord with priority 0, so that I can't open my browser or file manager without risking a buffer underrun???
Guys, i will dare to reopen this bugs. I am running 2.6.10-gentoo-r6 kernel and got problems with cdrecord. XCdroast says: "cdrecord: Cannot allocate memory. Cannot get SCSI I/O buffer." resmgr made no difference. Applying this patch though does resolve the issues. I know a lot of people who have same problems, so being user oriented we should either patch cdrtools and get it other with OR if you know of any other way to get it working let me know of it, so I could write clear documentation on it.
Hi! Try removing the suid bit from cdrecord. It should work
Removing the suid bit worked for me too. I was originally worried about suggesting this because you lose the other good advantages of being suid. However this has been the most widely suggested workaround, recent versions of k3b have been automatically removing the suid bit, and I havent seen any reported ill effects. Lets go for that.
Ok, here are some additional test results. I tried to fall back to unpatched cdrtools. K3b managed to identify my CD-RW both with and without suid flag. With XCdroast it did not help though. Switching it debug level 3 I saw that it is using /usr/lib/xcdroast-0.98/bin/xcdrwrap tool. So I tried to test this tool separately: /usr/lib/xcdroast-0.98/bin/xcdrwrap CDRECORD dev="ATAPI:0,1,0" -prcap It worked just fine with suid flag removed. However! xcdroast will NOT run unless suid is set on xcdrwrap. Apparently it is xcdroast issue which needs to be fixed.
Created attachment 50521 [details, diff] Fix xcdroast not to check SUI flag. well, here is the tiny patch for xcdroast (should it go to new bug report?) As part of the check for Non-Root-Mode xcdroast checked for suid flag. Apparently this check is redundant.
Just curious on the status of this bug, having just stumbled across it. I'm running gentoo-dev-sources 2.6.10-gentoo-r6, cdrtools 2.01, and xcdroast 0.98_alpha15-r3. I'm getting the "cdrecord: Cannot allocate memory. Cannot get SCSI I/O buffer." error with xcdroast. cdrecord does not have suid set. And setting suid didn't help either.
@comment #27 Ehm. That patch does not look well. What happens if you are not an kernel >=2.6.8? It may be easier to install xcdrwrap with suid set, although this is a security risk. Asking the maintainer of xcdroast may be hard as well, as xcdroast seems to be unmaintained now.
xcdroast isn't maintained? that's real bad news ... K3B isn't exactly ready for prime time either. Should I just learn how to use the command line CD tools and forget about GUIs? I've got to be able to burn and verify CDs reliably!!
Write an email to the xcdroast-maintainer that he still has fans and that he should update his application. That's out of our focus.
*** Bug 94039 has been marked as a duplicate of this bug. ***
