Bug 137364

Summary:	fstab entry not created for scsi dvdrom
Product:	[Fedora] Fedora	Reporter:	Timothy Sandel <timothy>
Component:	hal	Assignee:	David Zeuthen <davidz>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	low	Docs Contact:
Priority:	medium
Version:	3	CC:	alan, mclasen
Target Milestone:	---
Target Release:	---
Hardware:	athlon
OS:	Linux
Whiteboard:
Fixed In Version:	0.4.0-10	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-10-28 19:10:59 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Timothy Sandel 2004-10-27 19:32:54 UTC

Description of problem: 
scsi dvdrom recognized as /dev/scd0 but no "/media/dvdrom" created 
and no entry in the fstab. 
 
Version-Release number of selected component (if applicable): 
 
 
How reproducible: 
Install issue. 
 
Steps to Reproduce: 
1. Install fc3 rc2  
2. 
3. 
   
Actual results: 
 
 
Expected results: 
 
 
Additional info:

Comment 1 Timothy Sandel 2004-10-28 12:15:38 UTC

Created a file called scsi-cdrom.fdi in the
/usr/share/hal/fdi/95userpolicy with the following data and rebooted.
 After that the directory "/media/cdrom" and an fstab entry were
created.  This was a suggestion from David Zeuthen on the test list.


<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
  <device>
    <match key="storage.bus" string="scsi">
      <match key="storage.drive_type" string="cdrom">
        <merge key="storage.policy.should_mount" type="bool">true</merge>
      </match>
    </match>
  </device>
</deviceinfo>

Created a file called scsi-cdrom.fdi in the
/usr/share/hal/fdi/95userpolicy with the

Comment 2 David Zeuthen 2004-10-28 15:22:00 UTC

The reason we don't do this today is that we don't want to add entries
for SCSI devices as they may in fact be iSCSI devices which are not
local (e.g. within proximity of the box). And if we cannot guarantee
that they are local we will not give the local user (pamconsole)
access to them. 

However, in the event that the SCSI device is an optical device I've
got a hunch feeling that it cannot be iSCSI, not sure. Alan, is this
the case? Can we go ahead and add entries for SCSI optical drives?

Comment 3 David Zeuthen 2004-10-28 16:29:24 UTC

After some internal discussion we should match previous behavior (from
kudzu) and add the entries for SCSI optical drives. 

It might be theoritical possible that some remote box connected
through iSCSI exports one or more optical drives (say, a server
serving ISO's), however the local user cannot gain much by being able
to mount that device and the entry will be with the 'ro' option anyway.

Comment 4 Alan Cox 2004-10-28 18:44:58 UTC

iSCSI is like any other scsi - any device possibly located at arbitary
locations not matching the machine. Unfortunately (unless someone has
a brilliant idea [not image recognition of your CD-ROM using your
webcam]) it may have to stay user configured. 

Fortunately scsi dvd-rom is rare and also generally on servers so
hopefully smarter users. We do have an RFE post FC3 for making
Anaconda/firstboot ask a nice easy question to set the policy

Comment 5 David Zeuthen 2004-10-28 19:10:59 UTC

For post-FC3 my plan is to have a whitelist of SCSI adapters in hal
(though device information files) to tell whether the device is local
- of course, unless someone comes up with a better solution :-).

I guess FC2 and earlier would add the entry anyway so we do that now
in hal-0.4.0-10 which available from

 http://people.redhat.com/davidz/dist/

and these will either go into FC3 or will appear as an update.
Otherwise we would have a regression and since the /etc/fstab entry is
ro anyway a console user doesn't really gain anything.

Btw, the console user will be given rw permission to the device node
(since it's an optical drive) anyway due to how udev is configured. We
might want to revisit that for post-FC3.