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

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)

>> 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)

>> I do not know this is possible. The client should maintain different
>> views (or sessions as you call it) and present the view to the user.
>> But what if a user which is not linked to any credentials on the
>> client accesses the mountpiont?
>>
>
> There are a couple of possibilties. In the current patchset, they'll
> get back an error when they try to access the mount -- -ENOKEY
> currently in most cases, but I will likely need to translate that to
> something that more syscalls will expect, such as -EACCES.
>
> As a future feature, it might be helpful to establish an anonymous
> session to the server and map users without credentials to that.

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.

-- 
Thanks,

Steve