I should say that this guide was of tremendous help for me. But I have to notice that I haven't edited /etc/devfsd.conf and /etc/group to allow non-roots to burn CD's, but, surprisingly, I can do it (logged in as a regular user)!

Do you think I should be worried on the security of my system said this happening?

But I have to notice that I haven't edited /etc/devfsd.conf and /etc/group to allow non-roots to burn CD's, but, surprisingly, I can do it (logged in as a regular user)!

Do you think I should be worried on the security of my system said this happening?

Terrible, perhaps you followed my recommendation to suid the cdrecord binary? If so, then I believe you have nothing to worry about. If the suid bit is set on the cdrecord binary then as soon as any user invokes cdrecord, cdrecord will run with root priveleges (because root is the owner of that particular file) and have full access to the SCSI bus. Consequently any user should be able to record whether devfs has been modified or not.

Try running cdrecord -scanbus as a non-root user. If no CD-R device is detected then everything is normal. Modifying devfs changes the permissions on the SCSI bus. Having write permissions on the SCSI bus can enable users to send arbitrary data out to a device and cause corruption and damage, so that's why devfs doesn't allow it by default. But this restriction doesn't apply to a process running as root because root has full access permissions to every device under /dev.

If you only want to record CDs as root, then do not suid the cdrecord binary, and leave devfs as you have. That will give you the best security i.e. non-root users simply will not be able to record CDs. This command will strip the suid bit from the binary:

it works for me now ...there was a forum i found (can't remember which one) that sloved my problem ...i only had to run ide-cdrom as module and scsi support as a built in _________________tea+free software+law=hook

Thanks for the great post kerframil. I set this up a few days ago and followed your instructions exactly. Everything works great for me... I've tested it thouroughly on my desktop pc (Athlon 1.4GHz, MSI-K7T-Turbo, 8x4x32 LG CDR and LG 16x DVDROM on the same IDE channel, lolo-sources). Supermount finally works good with my dvdrom using fluxbox/endeavour2 (supermount has been problematic for me with gnome2/nautilus at the best of times). I have no problems burning cd's and using my dvdrom to either watch movies or transfer files at the same time. Also no problems doing this when I max out everyting else (cpu, disk transfers and downloads)... xmms doesn't even skip a note. The only kernel parameters I am using that are in any way related are ide0/1=autotune, I also enable interrupt unmasking on hda,b,c,d. I had one weirdo problem at first. My cdr mounted on my dvdrom mount point (/dvdrom) and dvdrom mounted on my cdr mount point (/cdrw). I don't know why this happened.. fstab was fine. I modified fstab to mount cdr to /dvdrom and dvdrom to /cdrw and this fixed it. If anyone knows why my mount points got reversed... please tell me.

when i do an "ls -al /dev/sr0" it shows ownership as root:root. shouldnt it be root:cdrw? same goes for /dev/cdrom, cdrw, etc.. weird thing though: when i do:

"ls -al /dev/scsi/host0/bus0/target1/lun0/cd"

it shows ownershp as xamn:cdrom (xamn is my username)

No I don't think so. Top-level /dev entries are only symlinks (for backward compatibility in devfs) and having root:root permissions is fine AFAIK. It's the devices that they point to where it counts. So the permissions "xamn:cdrom" are also fine, because devfs grants permissions to you (in context) and to the cdrom group which is right, isn't it? This behaviour can be changed in devfsd.conf.

Having said that, I can't suss out why you shouldn't be able to play audio CDs. Let's assume the permissions could be a problem, in which case have you tried pointing your CD player tool directly to the real device node?

Perhaps devfs isn't too intelligent about determing whether a device is a CD or DVD. In fact, maybe it has no way to distinguish the difference. Have a look at devfsd.conf (the relevant section of which xamn has conveniently posted above, and look at the REGISTER lines and the "Change foo to suit your setup" comments. Maybe they need tweaking for your setup.

I did so and noticed that a non-root member of the wheel group can successfully run it as opposed to other non-root users.

That's most intriguing. That seems as though its in keeping with the nature of the wheel group, but I'm not sure what the mechanics behind the permissiveness granted to members of the wheel group in this case. I know that members of the wheel group are able to elevate to root priveleges, so maybe some programs are designed to allow that by implication (or to perform certain tasks that would only be allowed by root) at the program author's discretion (Portage is one such program in terms of it's searching and pretend options). Just a theory, anyway. But one thing's for sure, an untrusted user should never be in the wheel group.

Latest xcdroast (not in portage currently) supports ATAPI with cdrtools-2.0. However I read on its home page faq that using atapi, dma doesn't get enabled, which practically means that u won't be able to write a cd-r on speed s >= 16x.
So till atapi cd-rw support on linux becomes stable I' d suggest to stay on ide-scsi

So till atapi cd-rw support on linux becomes stable I' d suggest to stay on ide-scsi

yes, or use another os for burning. atapi support with openbsd is great!

I definitely don't want to start a linux vs. bsd flamewar, since I don't know that much about *bsd's, but at least windoze also use an "ide-scsi emulation" method for writing cd-r's IMHO. However ide-scsi works great so far so I guess it's ok