Re: [PATCH 00/11] cifs: implement multisession mounts (try #2)

On Thu, 22 Apr 2010 13:02:22 -0500
Steve French <[email protected]> wrote:

> On Thu, Apr 22, 2010 at 12:51 PM, Jeff Layton <[email protected]> wrote:
> > On Thu, 22 Apr 2010 16:56:55 +0200
> > Stef Bon <[email protected]> wrote:
> >
> >> 2010/4/21 Jeff Layton <[email protected]>:
> >> > On Wed, 21 Apr 2010 16:16:26 +0200
> >> > Stef Bon <[email protected]> wrote:
> >> >
> >> >> I'm sorry but what is a multisession mount?
> >> >>
> >> >> Stef
> <snip>
> >> >>
> >> Yes very clear, what you want, but to me the whole problem is strange!
> >>
> >> Using more than one set of credentials (if using those) looks to me a not logic.
> >> NOt only because my construction (mount.md5key) is using seperate
> >> mountpoints per user, pure
> >> for securiity reasons. Another user is not allowed to access my mounts
> >> (not only to smb shares but every mount)
> >>
> >
> > I'm sure your solution solves some problems, but it's I don't think it
> > precludes this work. We have users of CIFS who do something similar
> > today (albeit much more manually).
> >
> > There are certainly cases where someone has a shared directory that
> > they need multiple users to access. Having to have a separate
> > mountpoint for each of those users seems rather cumbersome, IMO.
> >
> > In either case, this is simply a different way to solve that issue.
> > This solution will not preclude you from using CIFS in the way you wish
> > (with a single set of credentials per mount).
> 
> Yes - you are probably right here.  We also need to think about how
> Windows behaves here - they have done a good job on handling this
> issue (e..g in Windows 7)
> 

I'm not clear on how windows 7 handles this, but windows has
traditionally not had shared mount namespaces, right? i.e. if I map a
drive on windows to letter H and log in as another user, that drive
will not be similarly mapped in the new user's "session".

> >> But apart from that, I think all the data (files,permissions,..)
> >> depend on the credentials provided. The server "decides"
> >> what the client can see. Now you want to make the mounpoint present
> >> all the different "views" in one?
> >>
> >
> > CIFS does not cache readdir info, so the server will still decide what
> > each user can "see" based on the credentials that call the FIND_FILE
> > ops. In the event of a syscall against a dentry that's visible to one
> > user but not another, a call will still go out over the wire before
> > that syscall is satisfied. Therefore I don't think this patchset will
> > allow information "leakage" to users that shouldn't have it.
> 
> We do cached inode info on readdir results (if FindFirst can return
> enough info).
> could readdir from user1 return info on an inode, and stat from user2
> (on one of those inodes) happen fast enough so it would succeed when
> it should fail?  If so, we might allow that - although very low risk
> issue, and the alternative (horrible ls performance on some
> configurations of ls, would be bad)
> 

Actually, we don't...a readdir always causes FIND_FIRST to go out onto
the wire. A stat also always causes a QPathInfo call. I don't think
there are any "holes" with this, but if you see any please let me know.

It might be nice to eventually cache readdir info, but we'd need to
determine a way to test a directory to see if it has changed before we
trust that info. We'd also probably have to discard it and force on the
wire ops if the cached data was done with different credentials.

> 
> I would prefer that a "default" mount credential (not just anonymous)
> be allowed for unmapped users as an option - to be configurable on the
> client by root.  Since anonymous connections are forbidden on many
> servers.
> 

Sounds reasonable too. Again though, that'll probably be a future
feature and not in this initial implementation. I did however save a
radix tree tag so that we could tag a "default" session for each
superblock.

-- 
Jeff Layton <[email protected]>