This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 64533 - grip cannot rip from scsi / usb cdroms
grip cannot rip from scsi / usb cdroms
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: grip (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-05-07 09:56 EDT by greg hosler
Modified: 2014-03-16 22:27 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-02-06 00:15:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description greg hosler 2002-05-07 09:56:08 EDT
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.
Comment 1 Bill Nottingham 2003-02-06 00:15:32 EST
Fixed in kudzu-0.99.92-1.

Note You need to log in before you can comment on or make changes to this bug.