From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [linux-cifs-client] [PATCH 00/11] cifs: implement multisession mounts (try #2) Date: Sat, 24 Apr 2010 03:30:35 +0100 Message-ID: <20100424023035.GG15349@shareable.org> References: <1271794039-22787-1-git-send-email-jlayton@redhat.com> <20100421141301.4ca93513@corrin.poochiereds.net> <20100422153948.GA6265@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Stef Bon , Jeff Layton , linux-cifs-client@lists.samba.org, linux-fsdevel@vger.kernel.org To: Steve French Return-path: Received: from mail2.shareable.org ([80.68.89.115]:33393 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751789Ab0DXCai (ORCPT ); Fri, 23 Apr 2010 22:30:38 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Steve French wrote: > > Perhaps extending FUSE on the user side, if autofs isn't appropriat= e. > > FUSE is very programmable, and the kernel side can cache some thing= s. > > If better caching is needed, that would be to everyone's benefit. >=20 > 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 :-) =A0But triggering it from userspace has a = lot of > > advantages. >=20 > 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 p= assword > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html