Steve French wrote: > > Perhaps extending FUSE on the user side, if autofs isn't appropriate. > > FUSE is very programmable, and the kernel side can cache some things. > > If better caching is needed, that would be to everyone's benefit. > > Caching as in cache-fs? or as in caching user credentials? User credentials in this case. I don't know if FUSE actually does that - only that the architecture could go in that direction if useful. > > That kind of approach would help other filesystems as much as CIFS. > > > > Of course all of this still needs the ability to create new CIFS > > sessions when needed :-) But triggering it from userspace has a lot of > > advantages. > > Yes, but not as easy as it sounds to ask the user anything > (e.g. on "find /") even if kde/gnome desktop would popups on > fist attempt to access each directory mounted to servers we don't > have credentials or userid/password for (for this user). > We need the userid/password or krb5 ticket to use to > setup the session (we could ask winbind or the kernel keyring to > provide this). I prefer longterm that cifs or its helpers don't do password > storage, but rather some service such as winbind working with > the kernel keyring do this - so it can be analyzed by more eyes > to make sure it is secure. I agree it's not particularly easy, and I agree with _not_ storing passwords in the kernel. You seem to agree that a userspace helper should be involved (winbind), and the keyring seems a natural thing to use kernel side, which is really the same as what I've suggested, only I'd put a bit more of the mount-traversal decision making and session setup into 'winbind-plus'. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
