Bug 12127 - HAL does not consider eSATA drives to be hotpluggable
Summary: HAL does not consider eSATA drives to be hotpluggable
Status: RESOLVED FIXED
Alias: None
Product: hal
Classification: Unclassified
Component: hald (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: David Zeuthen (not reading bugmail)
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-23 20:46 UTC by Tristan Schmelcher
Modified: 2010-09-10 05:59 UTC (History)
7 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Output of running "lshal" after plugging in the drive via eSATA and getting the error (142.83 KB, text/plain)
2007-08-24 14:48 UTC, Tristan Schmelcher
Details
/etc/hal/fdi/policy/preferences.fdi (1.17 KB, application/octet-stream)
2009-06-11 03:04 UTC, Matthew Gatto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tristan Schmelcher 2007-08-23 20:46:08 UTC
Hard drives connected by eSATA are hotpluggable from the end-user's perspective, but HAL erroneously considers them to be fixed. This causes problems for users on distros that forbid normal users from mounting fixed drives as a security precaution (e.g., Debian, Ubuntu). Meanwhile, using the same drive as a USB device via an eSATA-to-USB adapter works correctly. Further, manually mounting the eSATA device as root works as correctly.

Steps to reproduce:

1) Obtain a computer with an eSATA port, an eSATA drive, and an eSATA-to-USB adapter.

2) Setup HAL to give your user account the hal-storage-removable-mount permission but not the hal-storage-fixed-mount permission (this is hard-coded in Debian because it does not have PolicyKit yet; see http://people.debian.org/~terpstra/message/20070807.181731.32cacc62.en.html).

3) Plug in the drive via USB and observe that it mounts automatically.

4) Plug in the drive via eSATA and observe that it erroneously fails to mount, giving the following error message:

Cannot mount volume.

Error org.freedesktop.Hal.Device.PermissionDeniedByPolicy.

-> Details

    hal-storage-fixed-mount refused uid 1000

5) Try to open the drive in Nautilus and observe the same error. Try to mount it with gnome-mount as yourself (e.g., "gnome-mount -d /dev/sdb1") and observe the same error.

6) Mount the eSATA drive manually as root (e.g., "sudo gnome-mount -d /dev/sdb1" or "sudo mount /dev/sdb1 /media/disk") and observe that it works and that the drive is accessible.

Expected behaviour:

eSATA drives should be considered to be hotpluggable, and thus the normal user account should be able to successfully mount the eSATA drive (either automatically as in step 4 or manually as in step 5). For an end user who switches from a USB connection to eSATA to get the extra speed (me), the error message is a rude awakening.

I have observed this bug on Debian Etch/Lenny 2.6.18-5 amd64 for each of the following package versions for hal and libhal-storage1:

0.5.8.1-9
0.5.9.1-2
0.5.9.1-4

For the latter two tests, hal-info was 20070618-1. For all three, libhal1 was version 0.5.9.1-2, but I'd imagine the bug is not in libhal.

Some info on my system: it is a Dell XPS M1710 laptop with a Core 2 Duo. The eSATA port actually comes from an eSATA-to-ExpressCard adapter, which requires only the pciehp kernel module (which on my system must be loaded with the option pciehp_force=1).

The output of lshal -m follows.

When inserting via USB:

$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
19:25:10.144: usb_device_152d_2338_7CA0D1820141 added
19:25:10.204: usb_device_152d_2338_7CA0D1820141_if0 added
19:25:10.222: usb_device_152d_2338_7CA0D1820141_usbraw added
19:25:15.164: usb_device_152d_2338_7CA0D1820141_if0_scsi_host added
19:25:15.165: usb_device_152d_2338_7CA0D1820141_if0_scsi_host_scsi_device_lun0 added
19:25:15.195: usb_device_152d_2338_7CA0D1820141_if0_scsi_host_scsi_device_lun0_scsi_generic added
19:25:15.263: storage_serial_WDC_WD32_WD_WCAPD1820141_7CA0D1820141 added
19:25:15.301: volume_uuid_5dae87a8_e207_42f2_85a5_812936842bda added
19:25:15.492: volume_uuid_5dae87a8_e207_42f2_85a5_812936842bda property volume.mount_point = '/media/disk-1'
19:25:15.497: volume_uuid_5dae87a8_e207_42f2_85a5_812936842bda property volume.is_mounted = true

When inserting via eSATA:

$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
19:28:41.331: pci_197b_2360_scsi_host added
19:28:41.333: pci_197b_2360_scsi_host_scsi_device_lun0 added
19:28:41.353: pci_197b_2360_scsi_host_scsi_device_lun0_scsi_generic added
19:28:41.415: storage_serial_SATA_WDC_WD3200KS_00_WD_WCAPD1820141 added
19:28:41.442: volume_uuid_5dae87a8_e207_42f2_85a5_812936842bda added

Viewing the lshal output for that storage ID confirms that it does not realize that the eSATA drive is hotpluggable (see indicated line):

udi = '/org/freedesktop/Hal/devices/storage_serial_SATA_WDC_WD3200KS_00_WD_WCAPD
1820141'
  block.device = '/dev/sdb'  (string)
  block.is_volume = false  (bool)
  block.major = 8  (0x8)  (int)
  block.minor = 16  (0x10)  (int)
  block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_SATA_WDC_W
D3200KS_00_WD_WCAPD1820141'  (string)
  info.capabilities = {'storage', 'block'} (string list)
  info.category = 'storage'  (string)
  info.parent = '/org/freedesktop/Hal/devices/pci_197b_2360_scsi_host_scsi_devic
e_lun0'  (string)
  info.product = 'WDC WD3200KS-00P'  (string)
  info.udi = '/org/freedesktop/Hal/devices/storage_serial_SATA_WDC_WD3200KS_00_W
D_WCAPD1820141'  (string)
  info.vendor = 'ATA'  (string)
  linux.hotplug_type = 3  (0x3)  (int)
  linux.sysfs_path = '/sys/block/sdb'  (string)
  storage.automount_enabled_hint = true  (bool)
  storage.bus = 'scsi'  (string)
  storage.drive_type = 'disk'  (string)
  storage.firmware_version = '21.0'  (string)
  storage.hotpluggable = false  (bool)    <-------------------- WRONG
  storage.lun = 0  (0x0)  (int)
  storage.media_check_enabled = false  (bool)
  storage.model = 'WDC WD3200KS-00P'  (string)
  storage.no_partitions_hint = false  (bool)
  storage.originating_device = '/org/freedesktop/Hal/devices/pci_197b_2360_scsi_
host_scsi_device_lun0'  (string)
  storage.partitioning_scheme = 'mbr'  (string)
  storage.physical_device = '/org/freedesktop/Hal/devices/pci_197b_2360_scsi_hos
t_scsi_device_lun0'  (string)
  storage.removable = false  (bool)
  storage.removable.media_available = true  (bool)
  storage.removable.media_size = 320072933376  (0x4a85d56000)  (uint64)
  storage.requires_eject = false  (bool)
  storage.serial = 'SATA_WDC_WD3200KS-00_WD-WCAPD1820141'  (string)
  storage.size = 320072933376  (0x4a85d56000)  (uint64)
  storage.vendor = 'ATA'  (string)

Thanks in advance, and good luck! I certainly hope that it does not turn out to be impossible to distinguish between eSATA drives and internal SATA drives ...
Comment 1 Danny Kukawka 2007-08-24 07:39:37 UTC
Please provide the complete lshal output as attachment
Comment 2 Tristan Schmelcher 2007-08-24 14:48:51 UTC
Created attachment 11260 [details]
Output of running "lshal" after plugging in the drive via eSATA and getting the error
Comment 3 Tristan Schmelcher 2007-08-24 14:53:20 UTC
Btw, I have confirmed this now on 2.6.22-1 too, and that's the kernel that I used for the lshal attachment.
Comment 4 Danny Kukawka 2007-08-24 17:29:25 UTC
what print:
grep . /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/*
Comment 5 Tristan Schmelcher 2007-08-24 17:39:36 UTC
$ grep . /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/*
grep: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/delete: Permission denied
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/device_blocked:0
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/iocounterbits:32
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/iodone_cnt:0x16625
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/ioerr_cnt:0xd
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/iorequest_cnt:0x16625
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/modalias:scsi:t-0x00
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/model:Hitachi HTS72101
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/queue_depth:1
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/queue_type:none
grep: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/rescan: Permission denied
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/rev:MCZO
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/scsi_level:6
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/state:running
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/timeout:30
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/type:0
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/uevent:DRIVER=sd
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/uevent:PHYSDEVBUS=scsi
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/uevent:PHYSDEVDRIVER=sd
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/uevent:MODALIAS=scsi:t-0x00
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/vendor:ATA
Comment 6 Danny Kukawka 2007-08-24 20:07:32 UTC
Looks to me as if we can't do anything here atm. I see no way to differ between SATA and eSATA. Maybe the kernel guys know more if this is possible at all.
Comment 7 Tristan Schmelcher 2007-08-24 21:38:48 UTC
I was afraid of that. I'll leave it to you guys to open a bug at kernel.org or whatever. As an experienced user/engineer, having to run "sudo gnome-mount" in a terminal doesn't bother me too much. Once eSATA becomes more common though, I think you'll get a lot more complaints.

Thanks.
Comment 8 Tristan Schmelcher 2007-08-24 21:51:05 UTC
One last thing:

If worst comes to worst, you might want to consider making _all_ SATA drives count as hotpluggable (because technically they are), and then tell the Debian/Ubuntu people to find a better way to enforce their security ideals.

Just my two cents.
Comment 9 Gilles Dartiguelongue 2009-03-02 04:44:54 UTC
hello there, this issue is starting to get a bit old. Did someone contact the kernel guys ?

our downstream issue is at:
https://bugs.gentoo.org/show_bug.cgi?id=260409
Comment 10 Patrice Vetsel 2009-03-20 05:06:18 UTC
Add myself to CC.

External hdd have more and more often an esata connection for great performances. But the system refuse to mount it automatically. It's a bad point.
Comment 11 Patrice Vetsel 2009-03-20 07:08:56 UTC
Upstream bug on kernel :
http://bugzilla.kernel.org/show_bug.cgi?id=12898
Comment 12 Patrice Vetsel 2009-03-20 07:32:38 UTC
From upstream :

Currently, the only controller which has a way to tell the kernel whether a
port is external or not is ahci.  Unfortunately, there doesn't seem to be many
machines which actually use the facility.  I haven't seen any yet.  The only
workable solution seems to be developing eSATA whitelist on the hal side.
Comment 13 Patrice Vetsel 2009-03-20 07:35:30 UTC
Can hal simply consider that under a running sytem, when a new sata drive appear (eSATA), it should consider it as removable/hotplug and so Gnome can automount it ?
Comment 14 Matthew Gatto 2009-06-11 03:03:18 UTC
Here is a hal rule I've put in my preferences.fdi which works for me in my case where I have an external esata drive plugged into a esata cardbus adapter in my laptop. I think it should work for anyone in a similar situation.

Note that you have to either put it before, or comment out the other entry in the preferences.fdi that prevents automounting internal drives. I'll attach the full /etc/hal/fdi/policy/preferences.fdi.

The rule:
  <!-- Fix properties for external esata drives connected via cardbus -->
  <match key="block.device" exists="true">
    <match key="block.is_volume" bool="false">
      <match key="storage.removable" bool="false">
        <match key="@info.parent:@info.parent:@info.parent:@info.parent:info.linux.driver" string="pcieport-driver">
          <merge key="storage.removable" type="bool">true</merge>
          <merge key="storage.hotpluggable" type="bool">true</merge>
        </match>
      </match>
    </match>
  </match>
Comment 15 Matthew Gatto 2009-06-11 03:04:54 UTC
Created attachment 26669 [details]
/etc/hal/fdi/policy/preferences.fdi
Comment 16 Martin von Wittich 2009-06-16 10:19:26 UTC
You can't actually distuingish SATA from eSATA ports - I'm using an eSATA bracket which is internally connected to a SATA port. Looks like this: http://www.cooldrives.com/essaii3gbexp.html
Comment 17 Sam Morris 2009-06-16 12:30:49 UTC
And I have one of these: <http://www.scan.co.uk/Products/Icy-Dock-MB-453SPF-Fits-into-2-525-Bays-Hosting-3-SATA-SATAII-Hard-Drive-with-Hot-swapable>, that connects via SATA internally.

IMHO, all drives should be hot-pluggable. There is no harm in this because if they are mounted by HAL on behalf of a user, they will be mountned with nodev,nosuid and other appropriate options. If they are mounted by root then the exact options that the administrator desires will be given on the 'mount' command line, or in /etc/fstab, etc.
Comment 18 Tristan Schmelcher 2009-06-16 13:21:40 UTC
I agree, all SATA drives should be considered hotpluggable. After all, they really are. Even an internal SATA drive can be unmounted and removed while the computer is on.

Of course non-SATA internal drives should still be reported as not hotpluggable, since they aren't (e.g., IDE).
Comment 19 Matthew Gatto 2009-06-16 17:11:26 UTC
This more general rule works for me and might work for any SATA drive, but I can't be sure as I only have my own to test it on:

  <match key="block.device" exists="true">
    <match key="block.is_volume" bool="false">
      <match key="storage.removable" bool="false">
        <match key="@info.parent:linux.subsystem" string="scsi">
          <match key="@info.parent:scsi.vendor" string="ATA">
            <merge key="storage.removable" type="bool">true</merge>
            <merge key="storage.hotpluggable" type="bool">true</merge>
          </match>
        </match>
      </match>
    </match>
  </match>
Comment 20 Patrice Vetsel 2009-06-16 22:47:30 UTC
For informations, I'v this problem on Ubuntu 9.04, but not in Fedora 11


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.