From: simo <idra@samba.org>
To: Jon Severinsson <jon@severinsson.net>
Cc: linux-fsdevel@vger.kernel.org, linux-cifs-client@lists.samba.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] CIFS posix acl permission checking
Date: Thu, 04 Mar 2010 08:44:22 -0500 [thread overview]
Message-ID: <1267710262.2375.280.camel@localhost> (raw)
In-Reply-To: <201003041150.08341.jon@severinsson.net>
On Thu, 2010-03-04 at 11:50 +0100, Jon Severinsson wrote:
> Hello
>
> Early this weak I sent a patch implementing posix acl permission checking in
> the linux cifs filesystem module. Unfortunately I only sent it to linux-fsdev
> as I was unaware of the linux-cifs-client list. I later tried to submit it to
> linux-cifs-client as well, but my message seems to have been lost in the
> moderation queue, so I subscribed and am trying again.
>
> I don't believe my patch is perfect, but I think it's a good start, and would
> like some comments from more experienced cifs developers to be able to get it
> into shape for inclusion in the kernel.
>
> I did get some comments from Matthew Wilcox at linux-fsdev, but unfortunately
> he never followed up on my response, so I'm including some unresolved
> questions I still have, as well as attaching the patch for further comments.
Hi Jon,
although you did a good job with the code itself, I have to say that I
think the approach is just wrong. Checking ACLs on the client is simply
the wrong way to go. It is just racy and it is not authoritative anyway.
It is like trying to look up a path using a cached directory listing and
then try to open by inode. It simply doesn't work, by the time you do
that, things may have been completely changed on the server.
And we are not counting the problem that with CIFS (and samba in
particular) the client have no way to know what are the real credentials
assigned to the session and that the client may have no idea what the
users and groups in the ACL are (if client and server do not use exactly
the same user database).
The right way is to let the server enforce ACLs, and use multisessions
mounts if multiple users are involved. Time would be better spent
working in that direction IMO.
Simo.
--
Simo Sorce
Samba Team GPL Compliance Officer <simo@samba.org>
Principal Software Engineer at Red Hat, Inc. <simo@redhat.com>
next prev parent reply other threads:[~2010-03-04 13:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-04 10:50 [RFC PATCH] CIFS posix acl permission checking Jon Severinsson
2010-03-04 13:44 ` simo [this message]
2010-03-04 15:21 ` Jon Severinsson
2010-03-04 15:51 ` simo
2010-03-04 17:33 ` Jeremy Allison
2010-03-04 16:18 ` Jeff Layton
2010-03-05 9:47 ` Michael Adam
2010-03-11 22:45 ` Michael Adam
2010-03-12 1:24 ` Jeff Layton
2010-03-12 1:53 ` Jeremy Allison
2010-03-12 8:09 ` Michael Adam
-- strict thread matches above, loose matches on Subject: below --
2010-03-01 16:00 Jon Severinsson
2010-03-01 15:15 Jon Severinsson
2010-03-01 17:03 ` Matthew Wilcox
2010-03-01 18:33 ` Jon Severinsson
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=1267710262.2375.280.camel@localhost \
--to=idra@samba.org \
--cc=jon@severinsson.net \
--cc=linux-cifs-client@lists.samba.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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).