[Utopia] gnome-mount 0.2 + hal mount/unmount changes

[David Zeuthen <david fubar dk>]

Hi,

(sorry for the cross-posting)

I've released gnome-mount 0.2 here

 http://freedesktop.org/~david/gnome-mount-0.2.tar.gz

The grand plan with gnome-mount is to get the appropriate GNOME software
to use this instead of invoking mount(1)/umount(1)/eject(1) / invoking
methods on HAL directly. Included in gnome-mount is also gnome-umount
and gnome-eject. All programs utilize the methods on HAL and as such run
unprivileged. The rationale for gnome-mount is to have a centralized
place (in gconf) where settings (e.g. mount options, mount location) are
maintained. Future plans include UI for editing settings and support for
passworded media (e.g. LUKS).

Also, I've made some changes to how the Mount/Unmount/Eject operations
work in HAL

 - We now maintain a property volume.mount.valid_options with the
   options we choose to allow - these are merged from device information
   file at fdi/policy/10osvendor/20-storage-methods.fdi - for example,
   for my USB stick formatted with vfat I get these options

    ro, sync, dirsync, noatime, nodiratime, noexec
    quiet, utf8, shortname=, codepage=, iocharset=,
    umask=, uid=

   If an entry in the volume.mount.valid_options ends with a '=' it
   means that the user can pass in any value. However, the shell script
   for mounting, hal-system-storage-mount, checks that, if you are not
   uid=0, that only uid=$HAL_METHOD_INVOKED_BY_UID is allowed. We also
   do other checks. 

   We still always add noexec,nosuid,nodev to the mount options.

   I'd appreciate if someone can do a security review of the mount shell
   script (at least the changes I made) since this is an attack vector
   (see the guard against passing umask=0600,dev,suid,exec for example).
   Thanks.

 - Fixed the hal-system-storage-eject such that we rmdir the directory
   if applicable (since eject(1) unmounts too)

We might want to expand 20-storage-methods.fdi with what options are
allowed, for example we might allow 'uid=' for e.g. hfsplus, ntfs etc.
but only if the volume stems from an external drive [1]. Should be
entirely possible with the storage.hotpluggable and/or storage.bus
property but the question is whether we can trust these properties.
Something to think about.

Also changed gnome-mount to choose sane default options (e.g. uid=$UID
for vfat, udf and iso9660) and put some TODO's in that we should read
this from gconf. It would also be cool with some UI (a Nautilus
extension perhaps?) for editing settings per volume and maybe even
defaults settings. Should probably use the volume.mount.valid_options to
generate the UI with available options. Might require input from
usability people to minimize the amount of techno babble (e.g. "[ ]
Optimize for fast removal" instead of "[ ] Sync"). Patches are welcome!

All this will go into the development tree of Fedora shortly so any bugs
will be shaken out pretty soon I hope.

In the next release of HAL the fstab-sync and volume.policy.*,
storage.policy.* properties will be removed in favor of using
gnome-mount or pmount.

(Btw, from whom do I need permission to put gnome-mount into GNOME CVS?
I already got a GNOME CVS account.)

Cheers,
David


[1] : The obvious attack vector are dual-boot systems. We don't really
want to allow an unprivileged user at the console to snoop at the files
on e.g. the WinXP or Mac OS X system.