Re: Patch: Prompt for required password when mounting a drive

[David Zeuthen <david fubar dk>]

On Fri, 2005-08-26 at 17:03 +0200, Martin Pitt wrote:
> So far the only support for passwords is with LUKS encrypted devices;
> if you call pmount at the command line, it will just ask for the
> password interactively. However, for GUI integration pmount also
> supports the "--passphrase <file>" argument. For example, in Ubuntu we
> hacked gnome-volume-manager to spawn a password dialog for encrypted
> devices, create a pipe, shove the password into the pipe and let
> pmount read the password from that pipe with this command. This works
> fine, I just didn't submit it yet to upstream since it lacks some
> features still.

Oh, btw, if I recall correctly the plan for integrating LUKS, hal and
GNOME was always something like this

 http://flyn.org/easycrypto/easycrypto.html

which specifically didn't involve passing passwords to the mount program
=). So, I think this is potentially a bad idea.. it's a bad idea since
vendors use different mount programs. So, I'd be a little bit opposed to
such a patch upstream but I do think it would make sense to solve the
problem in a distro- independent way as, perhaps, outlined in Mike's
original plan. 

What I do think, however, is for GNOME to have a GNOME-specific mount
program with a well-defined API, preference model and user experience.
We'd be able to put pieces like LUKS encryption, "mounting read-only if
not authorized" and other things there... Plus we can read from gconf
what mount options etc. to use so we can have nice Nautilus property
pages with these bits (ppl following the hal list will know this is a
huge feature request)... 

Can also put non-HAL bits like what Nate is asking for

I started working on one a while back but other things got in the way. I
was modeling the behavior after what pmount does (e.g. don't rely
on /etc/fstab), but the implementation is probably going to end up
looking a little different (using HAL method calls for e.g. Mount() and
Unmount() so we can avoid running as setuid root etc.). 

What do you people think about such an approach?

Cheers,
David