lkml.org 
[lkml]   [2014]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 1/1] Fix permission checking by NFS client for open-create with mode 000
From
On Fri, Jul 11, 2014 at 4:20 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
>
> 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.

Sure, but you can do OPEN(SHARE_ACCESS_READ) and
OPEN(SHARE_ACCESS_WRITE) separately and end up with a stateid that
allows both reading and writing. What does preventing
OPEN(SHARE_ACCESS_BOTH) gain you in this context.?


\
 
 \ /
  Last update: 2014-07-13 15:21    [W:0.258 / U:0.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site