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. _______________________________________________ utopia-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/utopia-list
