linux-kernel - Re: [PATCH 1/1] Fix permission checking by NFS client for open-create with mode 000

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140711202044.GD11931@fieldses.org>
Date:	Fri, 11 Jul 2014 16:20:44 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Trond Myklebust <trond.myklebust@...marydata.com>
Cc:	Frank Filz <ffilzlnx@...dspring.com>,
	Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
	Linux Kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] Fix permission checking by NFS client for
 open-create with mode 000

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/