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
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
