Bug 22879

(In reply to comment #0)
> Created an attachment (id=27888) [details]
> Add DKD_REMOVABLE attribute.
> 
> DKD's gets whether a device is removable or not by looking at sysfs, and sysfs
> cannot be changed.
> The attach patch adds a look-up to the udev-provided environment for the
> DKD_REMOVABLE key and uses it to override sysfs's removable attribute if it is
> provided.

Is there any particular reason why you'd want the feature? I'm not totally against it, just curious as to why you want it. Do note that this changes behavior in how desktop environments, like GNOME, handles the device.

FWIW, I know that most USB keys pretends to be removable (they are not; they are hotpluggable which is different) but the idea of maintaining a white-list of quirks (which is what this attribute suggests) is just not a good idea.

Since we already have a number of ID_DRIVE_* properties it would probably be better to call this ID_DRIVE_REMOVABLE. I don't know, going to talk to Kay about the whole ID_* namespace as it is becoming a bit messy (and right now DKD is appropriating parts of the ID_DRIVE_* namespace; that's probably wrong).

(In reply to comment #1)
> Is there any particular reason why you'd want the feature? I'm not totally
> against it, just curious as to why you want it. 

I am using some eSATA connectors on a motherboard SATA controller.
The devices are marked by sysfs as not removable and I want them to be handled as removable.

> Do note that this changes behavior in how desktop environments, like GNOME,
> handles the device.

Well unless someone manually changed udev to add the DKD_REMOVABLE attributes, the change should be completely transparent to Gnome.

> FWIW, I know that most USB keys pretends to be removable (they are not; they
> are hotpluggable which is different) but the idea of maintaining a white-list
> of quirks (which is what this attribute suggests) is just not a good idea.

I am a little bit fuzzy on the subtle differences between both ;-)

> Since we already have a number of ID_DRIVE_* properties it would probably be
> better to call this ID_DRIVE_REMOVABLE. I don't know, going to talk to Kay
> about the whole ID_* namespace as it is becoming a bit messy (and right now DKD
> is appropriating parts of the ID_DRIVE_* namespace; that's probably wrong).

Whichever is convenient or makes more sense, I am not dead set on DKD_REMOVABLE, it's the key that made most sense to me.

Phil.

(In reply to comment #2)
> (In reply to comment #1)
> > Is there any particular reason why you'd want the feature? I'm not totally
> > against it, just curious as to why you want it. 
> 
> I am using some eSATA connectors on a motherboard SATA controller.
> The devices are marked by sysfs as not removable and I want them to be handled
> as removable.

This doesn't really explain what you are trying to achieve... if you could elaborate on *why* you want this it would be useful... let me guess.. it is because you don't want to enter the root password just to filesystems that reside on the disk?

> > Do note that this changes behavior in how desktop environments, like GNOME,
> > handles the device.
> 
> Well unless someone manually changed udev to add the DKD_REMOVABLE attributes,
> the change should be completely transparent to Gnome.

The interactions between GNOME and DeviceKit-disks are far from trivial; what you can do with icons representing storage devices in GNOME, and what automatic things happen, depends on a great number of variables....

> > FWIW, I know that most USB keys pretends to be removable (they are not; they
> > are hotpluggable which is different) but the idea of maintaining a white-list
> > of quirks (which is what this attribute suggests) is just not a good idea.
> 
> I am a little bit fuzzy on the subtle differences between both ;-)

OK, "removable" means that the media of the device is removable. For example, CD-ROM drives or Nin1 card readers for flash media. Typically the _disk_ itself tells you this via e.g. the IDENTIFY inquiry (a command sent from the host to the microcontroller on the _disk_ itself). ATA disks connected via eSATA aren't removable, you can't remove the platters. So they report themselves with removable==0 and we should not try to fix this up.

(Of course, hardware sucks so virtually all USB keyfobs reports "removable==1" probably because the maker of the device wanted to be "helpful" and make things work better on windows. However USB enclosures for ATA devices typically report "removable==0" because we are actually able to send the ATA IDENTIFY command and get the _disk_ itself (not the enclosure) to tell us what it is.)

Now, there is _another_ interesting attribute about a disk device. That is, whether the device itself can be easily hotplugged on the system. Now, all (modern) buses in use in current systems are hotpluggable - most new systems allow you to add/remove SATA disks while the system is running. 

So what we _really_ want to know is whether the device is considered "system internal". That is, is the device something that a user is expected to hotplug? So that's why we have the :device-is-system-internal property

http://hal.freedesktop.org/docs/DeviceKit-disks/Device.html#Device:device-is-system-internal

Currently we only consider devices connected via USB and Firewire to be non-system-internal.

Why do we actually care about whether the device is "system-internal"? Well, we want to know this because, in order to implement lock down, we only want to allow standard users (e.g. without extra privileges or authorization) at the local console (e.g. not logged in via ssh) to manipulate (mount, format, partition) devices that are _not_ system internal. With the way things work in DeviceKit-disks you will typically have to enter the root password to mount system internal devices.

Ideally we'd have a way to determine if a certain phy/port is using eSATA (or for SAS: Infiniband / External Mini-SAS (SFF 8088)) and adjust the :device-is-system-internal property. Unfortunately, at least for SATA, there is no way we can determine this.

What we can do, however, is read well-defined UDEV properties (such as DKD_DRIVE_IS_SYSTEM_INTERNAL) that can override whether the device is system-internal. And, also, we might want to allow quirking the connection type so you get drive icons with an eSATA placard instead of just an ATA placard.

Yes, all this is kind of confusing. Apologies for that.

This could also help with devices such as the ThinkPad Ultrabay where you can hotplug the block device, but currently it is being handled as 'internal'.

To work around the issue right now we have a HAL script, which prevents Gnome from popping up password dialog to mount the filesystem.
http://www.thinkwiki.org/wiki/How_to_hotswap_Ultrabay_devices#HAL_support

It is rather complex because the Ultrabay has a different location on different model ThinkPads.

In addition to this, we also need to have the actual eject managed, which requires today the udev eject handler and the eject script to unmount the filesystems. Both are to be found on the same page and it would be great getting this sort of functionality into DeviceKit-disks.

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Is there any particular reason why you'd want the feature? I'm not totally
> > > against it, just curious as to why you want it. 
> > 
> > I am using some eSATA connectors on a motherboard SATA controller.
> > The devices are marked by sysfs as not removable and I want them to be handled
> > as removable.
> 
> This doesn't really explain what you are trying to achieve... if you could
> elaborate on *why* you want this it would be useful... let me guess.. it is
> because you don't want to enter the root password just to filesystems that
> reside on the disk?

Yes.

> 
> > > Do note that this changes behavior in how desktop environments, like GNOME,
> > > handles the device.
> > 
> > Well unless someone manually changed udev to add the DKD_REMOVABLE attributes,
> > the change should be completely transparent to Gnome.
> 
> The interactions between GNOME and DeviceKit-disks are far from trivial; what
> you can do with icons representing storage devices in GNOME, and what automatic
> things happen, depends on a great number of variables....
> 
> > > FWIW, I know that most USB keys pretends to be removable (they are not; they
> > > are hotpluggable which is different) but the idea of maintaining a white-list
> > > of quirks (which is what this attribute suggests) is just not a good idea.
> > 
> > I am a little bit fuzzy on the subtle differences between both ;-)
> 
> OK, "removable" means that the media of the device is removable. For example,
> CD-ROM drives or Nin1 card readers for flash media. Typically the _disk_ itself
> tells you this via e.g. the IDENTIFY inquiry (a command sent from the host to
> the microcontroller on the _disk_ itself). ATA disks connected via eSATA aren't
> removable, you can't remove the platters. So they report themselves with
> removable==0 and we should not try to fix this up.
> 
> (Of course, hardware sucks so virtually all USB keyfobs reports "removable==1"
> probably because the maker of the device wanted to be "helpful" and make things
> work better on windows. However USB enclosures for ATA devices typically report
> "removable==0" because we are actually able to send the ATA IDENTIFY command
> and get the _disk_ itself (not the enclosure) to tell us what it is.)
> 
> Now, there is _another_ interesting attribute about a disk device. That is,
> whether the device itself can be easily hotplugged on the system. Now, all
> (modern) buses in use in current systems are hotpluggable - most new systems
> allow you to add/remove SATA disks while the system is running. 
> 
> So what we _really_ want to know is whether the device is considered "system
> internal". That is, is the device something that a user is expected to hotplug?
> So that's why we have the :device-is-system-internal property
> 
> http://hal.freedesktop.org/docs/DeviceKit-disks/Device.html#Device:device-is-system-internal
> 
> Currently we only consider devices connected via USB and Firewire to be
> non-system-internal.
> 
> Why do we actually care about whether the device is "system-internal"? Well, we
> want to know this because, in order to implement lock down, we only want to
> allow standard users (e.g. without extra privileges or authorization) at the
> local console (e.g. not logged in via ssh) to manipulate (mount, format,
> partition) devices that are _not_ system internal. With the way things work in
> DeviceKit-disks you will typically have to enter the root password to mount
> system internal devices.
> 
> Ideally we'd have a way to determine if a certain phy/port is using eSATA (or
> for SAS: Infiniband / External Mini-SAS (SFF 8088)) and adjust the
> :device-is-system-internal property. Unfortunately, at least for SATA, there is
> no way we can determine this.
> 
> What we can do, however, is read well-defined UDEV properties (such as
> DKD_DRIVE_IS_SYSTEM_INTERNAL) that can override whether the device is
> system-internal. And, also, we might want to allow quirking the connection type
> so you get drive icons with an eSATA placard instead of just an ATA placard.
> 
> Yes, all this is kind of confusing. Apologies for that.

No problem.

I don't really know how to answer most of your questions :-)

What I want to achieve is:

 - eSATA hard drives should not require the root pw to mount.

DKD_REMOVABLE was the easiest thing to do.

Now that I upgraded to a system that uses udisks, I've ported to patch to udisks 1.0.1.

Find it attached.

I'm willing to do more work on this patch if you don't find the approach satisfying (eg. working on a UDISKS_IS_SYSTEM_INTERNAL) attribute.

Phil.

Created attachment 43350 [details] [review]
system internal patch

I've added an alternate patch for overriding system internal with a udev property. I've sent it to the list as well.

There should be a way to mark somehow SATA devices or ports as removable. This should allow removing HDDs (echo 1 >  /sys/block/sdh/device/delete) from DE (GNOME, KDE, etc) via GUI.

I've filled wish for KDE, but they said that udisks just doesn't support it. This is really needed by end-users.

This is now possible with

http://cgit.freedesktop.org/udisks/commit/?id=156ebd5ca8f88b7a4772c03ed269ae30718f866d