From: Stef Bon <stefbon@gmail.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, smfrench@gmail.com,
linux-cifs-client@lists.samba.org
Subject: Re: [PATCH 00/11] cifs: implement multisession mounts (try #2)
Date: Thu, 22 Apr 2010 21:55:06 +0200 [thread overview]
Message-ID: <v2g3c0132f01004221255q8b3e2265v314e9866ad231255@mail.gmail.com> (raw)
In-Reply-To: <20100422135105.71c0bc72@barsoom.rdu.redhat.com>
2010/4/22 Jeff Layton <jlayton@redhat.com>:
> On Thu, 22 Apr 2010 16:56:55 +0200
> Stef Bon <stefbon@gmail.com> wrote:
>
>> 2010/4/21 Jeff Layton <jlayton@redhat.com>:
>> > On Wed, 21 Apr 2010 16:16:26 +0200
>> > Stef Bon <stefbon@gmail.com> wrote:
>> >
>> >> I'm sorry but what is a multisession mount?
>> >>
>> >> Stef
>> 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 I understand. This is another way to provide data on the remote server,
but its just so not my idea of mounting.
But now when I read and think futher about this, I see that's a
providing new functionality
I can understand.
>
>> 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
So in this situation the amount of mountpoints is never more than the
number of smb shares available in the network, and does not depend
on the number of users, which in my construction is.
>
>> 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.
That's a sound idea.
Stef
>
> --
> Jeff Layton <jlayton@redhat.com>
>
prev parent reply other threads:[~2010-04-22 19:55 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-20 20:07 [PATCH 00/11] cifs: implement multisession mounts (try #2) Jeff Layton
2010-04-20 20:07 ` [PATCH 01/11] cifs: add function to get a tcon from cifs_sb Jeff Layton
2010-04-20 20:07 ` [PATCH 02/11] cifs: add tcon field to cifsFileInfo struct Jeff Layton
2010-04-20 20:07 ` [PATCH 03/11] cifs: make various routines use the cifsFileInfo->tcon pointer Jeff Layton
2010-04-20 20:07 ` [PATCH 04/11] cifs: have find_readable/writable_file filter by fsuid Jeff Layton
2010-04-20 20:07 ` [PATCH 05/11] cifs: fix cifs_show_options to show "username=" or "multises" Jeff Layton
2010-04-20 20:07 ` [PATCH 06/11] cifs: have cifs_new_fileinfo take a tcon arg Jeff Layton
2010-04-20 20:07 ` [PATCH 07/11] cifs: allow for cifs_sb_tcon() to return an error Jeff Layton
2010-04-20 20:07 ` [PATCH 08/11] cifs: fix handling of signing with writepages Jeff Layton
2010-04-20 20:07 ` [PATCH 09/11] cifs: add routines to build sessions and tcons on the fly Jeff Layton
2010-04-20 20:07 ` [PATCH 10/11] cifs: on multises mount, set ownership to current_fsuid/current_fsgid Jeff Layton
2010-04-20 20:07 ` [PATCH 11/11] cifs: add "multises" mount option Jeff Layton
2010-04-21 2:42 ` [PATCH 00/11] cifs: implement multisession mounts (try #2) Steve French
2010-04-21 14:16 ` Stef Bon
2010-04-21 18:13 ` [linux-cifs-client] " Jeff Layton
2010-04-22 14:56 ` Stef Bon
2010-04-22 15:39 ` Jamie Lokier
2010-04-22 16:57 ` Steve French
2010-04-24 2:30 ` [linux-cifs-client] " Jamie Lokier
2010-04-22 19:25 ` Jeff Layton
2010-04-22 19:55 ` Steve French
2010-04-24 2:26 ` [linux-cifs-client] " Jamie Lokier
2010-04-22 17:51 ` Jeff Layton
2010-04-22 19:55 ` Stef Bon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=v2g3c0132f01004221255q8b3e2265v314e9866ad231255@mail.gmail.com \
--to=stefbon@gmail.com \
--cc=jlayton@redhat.com \
--cc=linux-cifs-client@lists.samba.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=smfrench@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).