[PATCHES] Two patches for gpfs sharemodes

[Christof Schmitt]

On Thu, Aug 24, 2017 at 10:22:41AM -0700, Christof Schmitt wrote:
> On Thu, Aug 24, 2017 at 01:46:36PM +0200, Volker Lendecke wrote:
> > On Wed, Aug 23, 2017 at 01:40:54PM -0700, Christof Schmitt via samba-technical wrote:
> > > From 9474f1b1865636c7cc53a302b3225e3197f154c1 Mon Sep 17 00:00:00 2001
> > > From: Christof Schmitt <cs at samba.org>
> > > Date: Wed, 23 Aug 2017 10:33:42 -0700
> > > Subject: [PATCH 1/2] vfs_gpfs: Do not map DELETE sharemode access to WRITE
> > > 
> > > A SMB client can deny the WRITE sharemode, but still grant the DELETE
> > > sharemode. Mapping the requested DELETE access to WRITE access breaks
> > > this case. Fix this by removing the incorrect mapping from DELETE access
> > > to WRITE access.
> > 
> > Isn't the problem with GPFS_DENY_DELETE that it is mapped to a
> > combination of other flags internally? The last time we discussed this
> > GPFS_DENY_DELETE was not an independent bit in GPFS. This goes along
> > with Ralph's question about the precise semantics. Can we get someone
> > from the GPFS team to describe exactly what's going on internally?
> 
> The limitation of DENY_DELETE is that this bit can only be set together
> with either DENY_READ, DENY_WRITE or both. So this does not cover all
> possible cases (a SMB client allowing READ and WRITE access to others,
> but preventing DELETE cannot be enforced through the current API).
> 
> On the other hand, we should leverage the current API as much as
> possible and allow a SMB client to prevent others from deleting the file
> when that can be enforced.

To follow-up on the offline discussion we had: I did some additional
testing: The file system sharemodes are enforced across cluster nodes as
expected, including the DENY_DELETE one. The only limitation is the one
mentioned in the comment, that DENY_DELETE is only possible together
with one of the other DENY flags.

Christof