HAL methods at storage device level, to mount/unmount/eject volumes

David Zeuthen david at fubar.dk
Thu Dec 8 10:36:09 PST 2005


On Thu, 2005-12-08 at 16:49 +0100, Kay Sievers wrote:
> HAL volume method interface to request privileged operations like mount, umount, eject
> 
> Every storage device which contains a recognized filesystem exposes the
> methods, which can be invoked over the usual HAL D-BUS interface:
>   Mount(string:path, string:options)
>   UnMount()
>   Eject()
> 
> In the future, this interface could be extended to provide SetLabel(),
> Format() or any other useful action.

Awesome stuff! Suggest s/UnMount/Unmount/ and to pass options as an
array of strings.

Do we want to allow passing the filesystem to use? Thinking ppl want to
mount use fs msdos instead of vfat to get true 8.3 filenames. Deny
everything but this. Can this be done through mount options?

Also with the code given

> # pass only whitelisted mount options
> if [ "$GIVEN_MOUNTOPTIONS" != "" ]; then
>     MOUNTOPTIONS="nosuid,nodev,user"
>     case "$GIVEN_MOUNTOPTIONS" in
> 	*ro*)
> 	    MOUNTOPTIONS="$MOUNTOPTIONS,ro"
> 	    ;;
>     esac
>     case "$GIVEN_MOUNTOPTIONS" in
> 	*sync*)
> 	    MOUNTOPTIONS="$MOUNTOPTIONS,sync"
> 	    ;;
>     esac
>     case "$GIVEN_MOUNTOPTIONS" in
> 	*quiet*)
> 	    MOUNTOPTIONS="$MOUNTOPTIONS,quiet"
> 	    ;;
>     esac
> fi

how can iocharset=iso8859-1 be a legal option? 

List of options we should white-list probably depend on file-system but
I think a first conservative cut is fine. Btw, we probably don't need
'user' since the method-script runs as root, yes?

General mount options we probably want to include in the white-list in
addition to ro, sync, quiet (we do we allow quiet btw?)

 - noatime
 - nodiratime
 - noexec
 - dirsync

I'm thinking we'll have e.g. a gnome-mount program, that g-v-m and
gnome-vfs will use instead of mount(1), reading settings from gconf and
a nice Nautilus plug-in to click these boxes. Ditto for KDE and other
desktops.

For future enhancements, here are some thoughts

 - I suspect we may allow uid, gid, umask for fat, ntfs but only if the
   uid, gid matches that of the caller (do we pass this to the
   method-script, maybe we should?). At least on external drives

 - Probably allow option shortname for vfat as many ppl on the list
   have been wanting to change this in the current policy stuff we have

Great work!

Cheers,
David




More information about the hal mailing list