Now that I've got a cd writer again I've been trying to straighten out the CD burning situation in recent 2.6 kernels. To put it in context:

Sometime soon after 2.6.7, it was decided that allowing users to execute SCSI commands was a big security issue (even though they are usually connected through IDE/ATAPI, cd writers use SCSI commands for CD writing).

2.6.8 came out with a security fix, which was too restrictive and mostly broke cd writing. 2.6.9 improved upon this and has solved the problem (I think!).

The thing is, gentoo-dev-sources and ck-sources (probably others too) include a patch in the 2.6.8 and 2.6.9 releases, which completely bypasses the security fix. So these issues probably weren't visible anyway.

I removed the patch and tested writing on my new burner. It worked as expected, minus cdrdao not being able to read the buffer capacity. I wrote a kernel patch to allow it to be able to read that again,which got accepted into the 2.6.10 tree yesterday.

I've removed the bypass-security-fix from gentoo-dev-2.6.9-r3 and added my own patch to allow cdrdao to be happy again. What I'd appreciate now is testing from people who burn CDs or DVDs, so that we can be sure that the security fix isnt rejecting SCSI commands that are required.

Here's what you need to do:

1. Get the latest sources:

Code:

emerge =gentoo-dev-sources-2.6.9-r3

This has just gone into portage so you probably need to sync. Also its marked ~arch so will involve you going into the testing tree.

2. Apply a further debug patch which will tell us if SCSI commands are being rejected:

3. Compile, install, and reboot into your new kernel in the usual way.

4. Ensure that you have write access to your CD/DVD writer node. My CD writer is /dev/hdc and I can see that I need to be in the "disk" group to be able to write to it:

Code:

# ls -l /dev/hdc
brw-rw---- 1 root disk 22, 0 Nov 3 22:36 /dev/hdc

5. Make sure your CD writing software is *not* setuid root.

Code:

chmod -s /usr/bin/cdrecord
chmod -s /usr/bin/cdrdao
# repeat for all other cd writing software you use

6. Write a CD. Simulation will do. Do this as a user, *not* as root.
And make sure you use the dev=/dev/hdc notation for cdrecord. Using dev=ATAPI:0,0,0 style notation no longer works.

7. Run "dmesg". Towards the end of the output, you will probably see output such as:

Code:

verify_command: rejected command 1

Post all of those rejection messages here.

Please repeat this for other software you have available. I'm especially interested in getting this tested with k3b (I don't fancy compiling X, half of KDE, ..., on my server just to try this). Also testing from DVD writing software would be great, since I don't own a DVD writer.

yes, that will be useful - thanks
i think USB cd writing goes over the same transport. It should be easy to see for certain, since it should definately reject command 1 a few times (still trying to find out exactly what this is)_________________http://dev.gentoo.org/~dsd

Made some testing, and... nothing. there is no output on /var/log/messages...

I am using cdrecord with a GUI called cdbakeoven. The only thing is that cdrecord complains about not being able to do a mlockall and set RR-scheduler, but I think this has nothing to do with the SCSI transport...

hm, in a way thats good news, perhaps rejecting command 1 is something specific to my setup.

even so, you could run a couple of checks to make sure you are running the right kernel:

running "uname -v" will tell you the date and time when the active kernel was compiled.

when you open /usr/src/linux-2.6.9-gentoo-r3/drivers/block/scsi_ioctl.c in a text editor, you should be able to do a search for "rejected" which will take you to a code block looking like the following:

thanks! command 1 seems to be obseleted so i wont worry about that, but 1e is PREVENT_ALLOW_MEDIUM_REMOVAL which basically allows the software to ask the drive not to allow the user to eject the disc, or to let them eject it again, etc. it doesn't conflict with any other commands and looks safe so i'll get it added to the kernel._________________http://dev.gentoo.org/~dsd

I don't know if you're interested (I was going to do some tests...) but when I booted your kernel, burned, and then tried to reboot, my kernel crashed. As I went to the toilet while it was rebooting, I couldn't see what actually went wrong, but the callstack (if that was a callstack) indicated some problems in the SCSI modules/functions.

The door of my CDR was open when trying to reboot, maybe that was an issue. I managed to hang the computer as well unplugging my USB 2.0 PCMCIA adapter (my connection is PCMCIA --> USB --> CDR).

Unfortunately, I tried burning a CD with cdrecord as a regular user (via xcdroast) and all it can give me is this:

Code:

cdrecord: Cannot allocate memory. Cannot get SCSI I/O buffer.

Before doing chmod -s /usr/bin/cdrecord, it also had a statement at the end that said something like Using 'schily-0.8.'

Checking dmesg, all I get is a long string of rejected commands type "55" interspersed with some types "bb."

In any event, I'm very glad someone is addressing this issue, as I really did not want to downgrade my kernel so I could have functional CD writing. Thanks for the patch.

EDIT: Tried to burn the same files to CD using xcdroast in su mode. Both times I tried, OPC failed and the whole operation stopped within a few seconds. dmesg didn't show up with anything new. I uploaded the saved cdrecord.out file for reference.

Last edited by Broot on Sat Nov 06, 2004 9:17 pm; edited 1 time in total

Update: I tried to burn the Ubuntu Linux 4.10 LiveCD ISO again using the Nautilus CD-writing plugin as a normal user. Everything seemed to go normally, although I could hear the CD drive speed up and slow down frantically during certain intervals, especially after fixating. As before (with 2.6.9-gentoo-r1 - refer to this thread for more info and ignore my second post), the CD is unreadable. :/

dont write cd's as root. take all the suid bits off etc (please reread the instructions at the top). it should work just fine as normal user. but, if when you are doing this, rejection messages appear in dmesg, then i'd like to know.

55 and bb are already permitted by the kernel, but only if the software opens the devices in write mode - some software opens in RDONLY, which causes rejections like this. same issue exists for the 1e command mentioned already in this thread..its time to track down which software caused that request. i've already fixed cdmrw and cdrwtool here.

your cd recording issue sounds a little odd if you have definately followed the instructions in this thread. which other kernels have you tried? when did it last work?_________________http://dev.gentoo.org/~dsd

keyson: as mentioned above, your rejected command 1e is not a kernel issue. it is most likely it came from dvd+rw-format, and i just checked their sources, they have already fixed this in the latest ~arch release. thanks for the testing!_________________http://dev.gentoo.org/~dsd

# NOTE: The next line is critical for boot!
none /proc proc defaults 0 0

# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
# POSIX shared memory (shm_open, shm_unlink).
# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
# use almost no memory if not populated with files)
# Adding the following line to /etc/fstab should take care of this:

irondog: you should change the ownership of the device so that root owns it and its group is a CD Buring group, "cdrom" for example. Then set the permissions to 660 and put your normal user, and any other users on the box that will use the burner in that group.

which software are you using? 4d is log sense, doesnt conflict with anything, might be worth adding if the context looks ok.

donjuan : is this with cd's or dvds? do you know which software k3b is invoking to do the writing? 1e has already been addressed if its dvd+rw-format .. the others are outside of the scsi spec which is odd. could you please post the output of