From: "J. Bruce Fields" <bfields@fieldses.org>
To: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: Frank Filz <ffilzlnx@mindspring.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Linux Kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] Fix permission checking by NFS client for open-create with mode 000
Date: Fri, 11 Jul 2014 16:20:44 -0400 [thread overview]
Message-ID: <20140711202044.GD11931@fieldses.org> (raw)
In-Reply-To: <CAHQdGtTkTh4MQJk6bec46OjsyZHnEGGws3b_2HA+kszzOHM-pw@mail.gmail.com>
On Wed, Jul 09, 2014 at 07:12:09PM -0400, Trond Myklebust wrote:
> Oops. Sorry, the correct sub-sub-sub-sub-....paragraph is this one:
>
> Permission to execute a file.
>
> Servers SHOULD allow a user the ability to read the data of the
> file when only the ACE4_EXECUTE access mask bit is allowed.
> This is because there is no way to execute a file without
> reading the contents. Though a server may treat ACE4_EXECUTE
> and ACE4_READ_DATA bits identically when deciding to permit a
> READ operation, it SHOULD still allow the two bits to be set
> independently in ACLs, and MUST distinguish between them when
> replying to ACCESS operations. In particular, servers SHOULD
> NOT silently turn on one of the two bits when the other is set,
> as that would make it impossible for the client to correctly
> enforce the distinction between read and execute permissions.
>
>
> > To me that translates as saying that the server SHOULD accept an
> > OPEN(SHARE_ACCESS_READ|SHARE_ACCESS_WRITE) request in the above
> > situation.
>
> Same conclusion, though....
Are we sure that's not just a spec bug?
Allowing OPEN(BOTH) on a -wx file seems like a pretty weird result.
--b.
next prev parent reply other threads:[~2014-07-11 20:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-09 21:54 [PATCH 1/1] Fix permission checking by NFS client for open-create with mode 000 Frank S. Filz
2014-07-09 22:17 ` Trond Myklebust
2014-07-09 22:42 ` Frank Filz
2014-07-09 23:06 ` Trond Myklebust
2014-07-09 23:12 ` Trond Myklebust
2014-07-10 4:26 ` Frank Filz
2014-07-10 4:32 ` Trond Myklebust
2014-07-10 5:22 ` Frank Filz
2014-07-10 12:42 ` Trond Myklebust
2014-07-10 14:23 ` Frank Filz
2014-07-11 20:20 ` J. Bruce Fields [this message]
2014-07-11 20:46 ` Trond Myklebust
-- strict thread matches above, loose matches on Subject: below --
2014-07-09 21:55 Frank S. Filz
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=20140711202044.GD11931@fieldses.org \
--to=bfields@fieldses.org \
--cc=ffilzlnx@mindspring.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@primarydata.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.