[fuse-devel] fuse desktop integration / management library

[nf2]

Danny Milosavljevic wrote:
>   
>> what about 
>>     
>>>> setting a FUSE_MOUNT_PASSWORD envir variable? would that be safe?
>>>>         
>
> No.
> Environment variables are about as private as a wallpaper on the entire side of a skyscraper (ok, on the backside, at least you have to look on the backside first :-)).
>
> Try
>   $ cat /proc/3617/environ
>
>   

oh! ;-)

>> but for modules like curlftpfs i would suggest setting the password in an environment variable.
>>     
>
> Why have it any different for "curlftpfs" than for anything else?
>   


i'm just looking for a simple way to do this. perhaps it would also be 
possible to just pipe the password to stdin of the mount executable 
(waiting for a standardized "password:" prompt...). i just believe that 
ssh-askpass is too complicated. i want to pass the password to the mount 
operation in libfusi (or receive a callback from it)...

gboolean            fusi_mountpoint_is_password_required(FusiMountPoint 
* mpoint);

FusiMountResult     fusi_mountpoint_mount(FusiMountPoint * mpoint, char 
* passwd, GError ** err);


> If you want fancy "remember my password"-style stuff, you can always put a bells-and-whistles ssh-askpass in place (the savefile being "~/.netrc"). And give it the service info (filesystem name, user name, domain name, whatever) in its environment (or read from /proc/`getppid()`, hmmm)
>   
i would rather use kwallet/keyring for remembering passwords...

>   
>> i have continued working on "libfusi":
>>
>>   
>
> I glanced over it and it's quite nice. I like the registry for fuse-able programs, kinda reminiscent of (freedesktop.org) desktop entries :-).
>   
thx :-) ... yes - i'm using GKeyFile a lot in libfusi (for mountspecs 
and modulespecs).

>   
>> the "gfuse-manager" package contains a gtk based client which uses 
>> libfusi (sshfs works well when ssh-askpass is installed)
>>     
>
> However, I'm not much a friend of a global management program. I'd prefer a file manager context menu entry on directories that would run your program, which would be the following dialog, allowing to mount / umount / union stuff onto this one directory.
> Of course this is just a nitpicking point :-)
>
>   
well, i would consider mounting "anywhere" as an expert feature (libfusi 
could be extended to allow this). for "average" users i would rather use 
a standard location (like "~/network-servers/{user defined mountname}"). 
integration with file-managers and file-choosers (like "connect to 
server..." in nautilus) would be ideal - that's why i have separated the 
management API (libfusi) from the presentation layer (gfuse-manager and 
fusi-client).

my biggest problem now is how to integrate smb. it's hard to fit into 
the mountpoint model. i believe every share should be a separate mount 
(otherwise you can't mount/unmount them individually), and 
authentication should only happen during mount operations...

i would prefer the following simple model (instead of mounting the whole 
smb:// tree at once):

1) user clicks "connect to smb server"...
2) the mountpoint property form with username, workgroup, host, share 
and mountpoint-name fields pops up.
3) there is an extra "Browse..." button which shows the smb:// network 
browser results*). by clicking on a server or share the 
mountpoint-property-form is auto-filled in (workgroup, host and share).
4) the user types in username and mountpoint-name and clicks "mount".

*) as tree - provided by a browser service, perhaps dbus.

i hope the authors of "fusesmb" or "smbnetfs" can help me with this...

btw: here is a screenshot of gfuse-manager:
http://www.scheinwelt.at/~norbertf/devel/fusi/

norbert