From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408

Description of problem:
if a cdrom reader is NON-ATAPI IDE (which includes SCSI, usb, and possibly ide's
which cannot read CDDA, and thereby require the /dev/sg ide-scsi support), then
grip (probably also cdparanoia, and possibly cdda2wav (but I am not positive
about this last one)) and any other ripping front end program that uses
cdparanoia (and possibly the other rippers) won't work in normal user mode.

The reason is that drive that can read CDDA will use ioctls directly to
/dev/cdrom (or /dev/hd?), which will be properly permissioned (by the entry in
/etc/security/console.perms) to 600, and owned by the logged in user. rippers
that can't talk to /dev/cdrom, will talk to the respective /dev/sg* device, and
that device is still permissioned as 660 root.disk.

/etc/security/console.perms actually has a hook in there to allow for easy
implementation of sg support. All one needs to so is to arrange for a soft-link
in /dev/cdroms/ to link back to the respective sg device that matchs the cdrom.

for example, on my system, my scsi cdrom is fixed at /dev/scd0, which has a
respective sg device /dev/sg4. By manually creating teh following soft link:

       /dev/cdroms/cdrom -> ../sg4

when I log in as whichever user I log in as, I will have access to my cdrom sg
device.

For fixed scsi cdroms, this ought to be fairly straight forward.

I also have a usb cdrom device. Someone created a /dev/cdrom1 -> /dev/scd1 link
for me, when my usb cdrom was initially plugged in. If they had also created a
matching /dev/cdroms/cdrom1 -> ../sg9, I would be all set. Note that as/when the
usb bus changes, and the sg devices are re-assigned, then this soft link might
need to be re-linked (and it might be the case that the permission policy will
need to be reapplied, I'm not sure on this one).





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


How reproducible:
Always

Steps to Reproduce:
1. go to a system a/ a scsi cdrom.
2. log in as a normal user.
3. run grip, and proceed to try to rip some tracks from the scsi cdrom drive.
This will fail. Then su to root, re-run grip as "grip -v" - you will see the
/dev/sg device access in the debug dialog.
	

Actual Results:  can't rip from non-ATAPI IDE drives

Expected Results:  should be able to rip from said drives.

Additional info:

This is probably not a grip bug. it is more likely to be a bug
in the component (or more likely components) that creates links in /dev that
works in conjunction with /etc/security/console.perms - this might include kudzo
(but I'm not positive), and whichever package manages teh usb hot-plug conenctions.