From: Stef Bon <stefbon@gmail.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: linux-cifs-client@lists.samba.org, linux-fsdevel@vger.kernel.org,
smfrench@gmail.com
Subject: Re: [linux-cifs-client] [PATCH 00/11] cifs: implement multisession mounts (try #2)
Date: Thu, 22 Apr 2010 16:56:55 +0200 [thread overview]
Message-ID: <h2y3c0132f01004220756l2c70189dxb9dd21f6ba503460@mail.gmail.com> (raw)
In-Reply-To: <20100421141301.4ca93513@corrin.poochiereds.net>
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
>>
>
> Sorry, I guess I should have been more clear.
Well you dio not have to apologise!
There is nothing wrong with asking.
>I'll try to flesh out the
> description a bit more on the next respin of this set:
>
> Currently, CIFS will only uses a single set of credentials on a
> mountpoint, and those credentials are decided at mount time. This is
> fine if you only ever have a single user using that mountpoint. In many
> cases though, multiple users on a client may access the mount. When
> this happens, those users share the mount's credentials. This means
> that you can't enforce permissions on a per-user basis on a CIFS mount.
>
> Now, CIFS tries to do several kludgey things to get around this
> limitation. It tries to enforce permissions locally, particularly if
> you have unix extensions enabled (which allows the client to fetch
> ownership and mode info from the server), but this is an inherently
> broken and racy proposition -- you have to be able to map local uid's
> to the server's, for instance and you also are faced with the
> possibility that permissions can change after you check them.
>
> There are also problems with inode creation. If you create a file, the
> ownership on the server is generally set to whatever the mount creds
> map to, and that has no relation to the user actually accessing the
> mount. This leads to a very confusing problem that users sometimes hit
> where they "touch" a new file on a mount, and get an error back. The
> file is created, but the ownership and mode are set in such a way that
> utimes() on it fails when the client tries to enforce permissions.
>
> The idea with this set is to address the root cause and allow the
> client to use multiple sets of credentials based on the fsuid of the
> task accessing the mount. This is a little more involved than with a
> filesystem like NFS -- you have to establish a "session" with the
> server for each set of credentials.
>
> Clear as mud?
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)
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?
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?
Stef
next prev parent reply other threads:[~2010-04-22 14:57 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 [this message]
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
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=h2y3c0132f01004220756l2c70189dxb9dd21f6ba503460@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).