[proposal] VolumeAutomount and VolumeAutoUnmount notifications

[Luke Kenneth Casson Leighton]

On Thu, Sep 23, 2004 at 11:03:00PM +0200, David Zeuthen wrote:

> I'm not sure this is a good idea; I actually think it's very desirable
> to do the mount in the actual desktop session instead of letting some
> root process mount it. 

 hmmm...

> OK, mount(1) is setuid root, but it manages to
> get the permissions right, so e.g. my USB stick is only writable for uid
> 500.

 autofs doesn't even get that right.  fortunately, for my
 1-user-distribution, i can follow the lead of the "usbmount" script i
 found (google search) which either derives the uid=NNNN from
 analysing /dev/console (or was it /dev/xconsole) or just... whips the
 uid out of a config file /etc/usb-mount.conf.


> Another reason is that g-v-m and k-v-m I suppose respects the users
> preferences (e.g. only automount USB sticks and not optical discs) and
> these are stored in gconf or the KDE equivalent.

 so, some mount points get treated as autofs, and some get treated as
 /etc/fstab, yes?

 that would mean having two programs in /etc/hal/devices.d,
 both of which respond to user-driven configuration files.

 so again, you'd need to determine the presently logged on user in
 fstab-sync, then determine where the config files are for kde or gnome,
 or have kde or gnome write to some well-known config file
 (e.g. /home/username/.hal.mountpoints)

> Sometimes we also want explicitly not to mount something - for instance,
> g-v-m now refuses to mount an optical disc if another process is holding
> a lock on the hal device object representing the optical drive. This is
> useful as a cd-recording application can take this lock and a non-blank
> CD-RW won't be mounted (which is the desired effect as the cd-recording
> app is asking the user to insert a disc to write that .iso file to).
 
 oooo, niiiccee :)

> > also, i don't believe it's a good idea for KVM or GDM to actually be
> > doing the mounts and unmounts themselves: as i mentioned before, it
> > leads to OS-specific code in KDE and Gnome [that HAL is supposed to
> > alleviate].
> > 
> 
> Yeah. I just mailed to the hal mailing list about the libhal-storage
> library which is basically a C wrapper of the hal string-based property
> API. Suitable for bindings etc. One interesting thing I mentioned was
> having abstraction functions for mount and unmount. 
 
 understand.

> > _so_ :)
> > 
> > this is fun!
> > 
> > btw i'm getting there with the automount stuff in hald:
> > 
> > - i've added into fstab-sync (in-autofs-mode) some code that updates
> >   "volume.mount_point".
> > 
> > - after the hal_callout_device() in detect_media() i run a
> >   "VolumeMount" notify (which i think should be VolumeAutoMount).
> > 
> > - i've switched off VolumeMount and VolumeUmount notifies from
> >   /etc/mtab parsing.
> > 
> > more to do...
> > 
> 
> I'm a little lost here, sorry; is the goal to provide the exact same hal
> API (e.g. volume.is_mounted, volume.mount_point, volume.fstype etc.) to
> applications as if we weren't using autofs? 

 no, my goal is to make hal (and kde) _work_ with autofs.

 what you are saying above is an implicit assumption that hal will work
 cleanly with autofs: it most definitely will not!!!

 1) autofs mount entries go in /etc/auto.foo they do NOT go in /etc/fstab.

 2) the mountpoints don't actually exist until the user tries to access
    them - then they "appear" as if by magic...

 3) KDE users accessing a mountpoint results in a hotplug event
    results in a HAL notify results in KVM reacting results in a
	popup on-screen saying "please remember to unmount this device
	before taking it out"

	... only to have that same mountpoint automatically disappear
	4 seconds later.

	a subsequent access to the subdirectory has the whole thing happen
	again, and again, and again.

> But with the following
> changes:
> 
> 1. The added benefit that the user can actually remove usb sticks and
> cdrom media after they haven't been written to for some time?

 yes.  um.  four seconds.  to make sure users don't screw up their data.

 but you also have to use fusexmp "proxy redirection" to
 _guarantee_ that the filesystem isn't in use.

 because even with autofs, if you have a file handle on the filesystem,
 autofs _still_ won't unmount the filesystem.

 if you can guarantee that all applications will close all files,
 including konqueror stopping all its "Directory Notify" stuff,
 and if you can guarantee that FAM will stop hanging about, then
 yes, you automatically get your filesystem back...

 ... otherwise you have to use fusexmp (fuse example mount program).

 it works very well!!


> 2. Real mounting happens at root level on-demand?

 autofs mounting happens automatically, by root, on-demand.
 if you want it on a per-user basis you have to specify
 "fstype=auto,uid=myusername"
                  ^^^^^^^^^^

 i have this covered in a config file (/etc/fstab-sync.conf).

 to solve this user-mounting thing "neatly", autofs can run
 programs rather than read flat files.

 if i were to make /etc/auto.hal a script /etc/auto.hal.sh i could
 mount, at runtime, by analysing the user of /dev/xconsole, the
 filesystem with the uid of the currently logged in KDE or Gnome user.



> 3. The applications thinks the volume got mounted once it is inserted.

 due to the modifications i've made to both hal and fstab-sync: yes.

 l.

_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal