[Pkg-utopia-devel] pmount stuff

Sjoerd Simons sjoerd@spring.luon.net
Thu, 28 Oct 2004 12:42:47 +0200


On Thu, Oct 28, 2004 at 09:00:20AM +0200, Martin Pitt wrote:
> >     * It seems that pmount just tries various filesystems, but g-v-m already
> >       knows the filesystem type from hal. Probably would be nice if we could
> >       give this info to pmount (i think trying several types causes at least
> >       kernel warnings)
> 
> I can add such an option, if it is desired.

I think it would be an improvement, but it's your choice ofcourse :)
  
> >     * According to pmounts documentations about umount:
> >       - <device> is mounted according to /etc/mtab and /proc/mounts with the
> >         calling user's uid
> > 
> >       but that isn't checked in the code. I'm able to umount every disk in
> >       /media as normal user...
> 
> It is checked in the code, see policy.c, device_mounted():
> 
>     if( mounted && expect && uid > 0 && (uid_t) uid != getuid() ) {
>         fprintf( stderr, "Error: device %s was not mounted by you\n", device );
>         return 0;
>     }

Oh didn't expect device_mounted to also check uid :) But this is buggy.. If the
drive is mounted by root (like it was in my tests), anyone is allowed to
umount.

> May it be possible that you tried the Ubuntu version instead? This
> indeed contains a patch which disables the check, because we needed a
> quick workaround for allowing hal to pumount devices which were ripped
> out without proper unmounting. This hack will disappear in Hoary, I
> will fix g-v-m to do the unmounting instead (but this involves
> nontrivial changes).

g-v-m for umount is plain wrong imho, we talked about this once :).. I'll send
a mail to linux-hotplug-devel, what their opinions are about a hotplug script
that runs umount -l (that's what it's about, right)
  
> >     * With hal 0.4.0 fstab-sync uses some policy information from the hal
> >       database, like whether it should be mounted sync and a suggested
> >       mountpoint. 
> 
> Controlling the sync flag is indeed on my wishlist (and I also have an
> assigned bug: https://bugzilla.ubuntulinux.org/show_bug.cgi?id=2386).
> I thought about adding a --nosync option to accomodate that.

Cool..
  
> >       Would be nice if there was some way to use this info to pmount..
> >       But i don't think the setuid binary should link in hal, maybe a
> >       hal_pmount wrapper program ? 
> 
> No, please nothing of this sort. I think g-v-m should be responsible
> to be the bridge between hal and pmount. g-v-m already reads out the
> hal stuff and calls pmount, so the option passing should be
> implemented there as well IMHO.

Yeah your mostly right ofcourse :). I've no problem adapting g-v-m to pass the
options, that was the first thing i thought about. 

The only downside is that when a k-v-m (or any other volume manager) is
packaged, it should also be patched to pass extra options instead of another
mount command. Which means extra work, because in the ideal case every volume
manager in debian would do basically the same (wrt to mounting) and keeping
stuff in sync is tiresome.. Ubuntu ofcourse doesn't have this problem :)

For now, as soon as the group thing is solved i'll push pmount in g-v-m :)..

  Sjoerd
-- 
It's very inconvenient to be mortal -- you never know when everything may
suddenly stop happening.