HAL policies for port. music players

David Zeuthen david at fubar.dk
Sun Jan 9 17:56:59 UTC 2005


Hi,

For reference, the thread mentioned from hal at fd.o is here

 http://lists.freedesktop.org/archives/hal/2005-January/001541.html

On Sun, 2005-01-09 at 14:13 +0000, Michael A. Peters wrote:
> I do not like the default behaviour of hal with respect to my iPod.
> Regardless of who is logged in at the console, if the iPod is docked -  
> it wanted mounted rw for the user, with a nice pretty tempting icon on  
> the desktop. Since it can take considerable time to reload one of these  
> devices (about 20 to 30 minutes for my mini - which is as small as they  
> come) - it's an accident waiting to happen like that.

This sounds more like a physical security problem to me: If you care
about the contents of your iPod you shouldn't leave it attached to a
machine that untrusted users (your kids :-), judging from the thread at
the hal mailing list) can physically access.

> I much prefer the autofs way - where it is not mounted on the desktop,  
> only mounts for users in the group specified in the auto.master file,  
> only mounts when it is needed, and unmounts when it is no longer  
> needed.
> 
> After some searching and a tip from someone on the hal list, I was able  
> to stop hal from mounting my iPod without having to turn of auto  
> mounting of all ieee1394 devices (created an iPod specific policy in  
> 95userpolicy)
> 

You can just use a device information much like this

 <deviceinfo version="0.2">
   <device>
     <match key="block.is_volume" bool="true">
       <match key="volume.fsusage" string="filesystem">
         <match
key="@block.storage_device:@storage.physical_device:usb.vendor_id"
int="0x0d7d">
           <match
key="@block.storage_device:@storage.physical_device:usb.product_id"
int="0x1600">
             <merge key="volume.policy.desired_mount_point"
type="string">my_mount_point</merge>
             <merge key="volume.policy.mount_option.uid=555"
type="bool">true</merge>
             <merge key="volume.policy.mount_option.gid=555"
type="bool">true</merge>
           </match>
         </match>
       </match>
     </match>
   </device>
 </deviceinfo>

This means: For a specific device (USB vendor_id 0x0d7d, USB
product_id 0x1600), HAL/fstab-sync will attempt to use the mount
point /media/my_mount_point (if it's not taken already!) and
add the mount options uid=555 and gid=555, which of course only
applies to vfat. Replace the UID and GID of yourself. You will have
to adapt to make it work for Firewire; use hal-device-manager to
look at what properties you may need - email me personally if you
cannot get this to work.

> Now that I have it working the way I want it with autofs - I want to  
> know if hal is currently capable of the autofs behaviour - mounting  
> only for users in specified group, only when needed, and auto  
> unmounting when no longer in use. If it is capable of this, then I  
> suggest for FC4 that such policies for large capacity portable music/ 
> video players either be the default, or easily configured as the  
> default through a sysconfig gui.
> 
> I'm tempted to add that as a RFE bug to hal, but don't want to if hal  
> isn't capable of it, and wanted to hear other thoughts first.
> 

No, HAL is not capable of automatically unmounting file systems when
they are not in use - I also think that the whole UI with gnome-vfs
and Nautilus would have to be reworked to support that (icons 
appearing and disappearing from the desktop for once). What HAL tries
to do is to fit most users needs (without using the evil shell) and
you cannot please 100% of people 100% of the time. Sorry.

What I do want to do for FC4 or FC5 (difficult to plan without the
schedule http://fedora.redhat.com/participate/schedule/ being up
to date :-/), is some UI a'la hal-device-manager where all sorts
of options, maybe even the cracktastic ones above, can be configured
on a per-device-basis. I do realize that it may asking users too
much to fiddle around with hal device information files.

Hope this helps,
David





More information about the fedora-devel-list mailing list