Re: [PATCH v27 03/21] vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags

On Tue, Dec 6, 2016 at 10:25 PM, Miklos Szeredi [off-list ref] wrote:

On Tue, Dec 6, 2016 at 10:13 PM, Jeremy Allison [off-list ref] wrote:

quoted

On Tue, Dec 06, 2016 at 03:15:29PM -0500, J. Bruce Fields wrote:

quoted

On Fri, Dec 02, 2016 at 10:57:42AM +0100, Miklos Szeredi wrote:

quoted

On Tue, Oct 11, 2016 at 2:50 PM, Andreas Gruenbacher
[off-list ref] wrote:

quoted

Normally, deleting a file requires MAY_WRITE access to the parent
directory.  With richacls, a file may be deleted with MAY_DELETE_CHILD access
to the parent directory or with MAY_DELETE_SELF access to the file.

To support that, pass the MAY_DELETE_CHILD mask flag to inode_permission()
when checking for delete access inside a directory, and MAY_DELETE_SELF
when checking for delete access to a file itself.

The MAY_DELETE_SELF permission overrides the sticky directory check.

And MAY_DELETE_SELF seems totally inappropriate to any kind of rename,
since from the point of view of the inode we are not doing anything at
all.  The modifications are all in the parent(s), and that's where the
permission checks need to be.

I'm having a hard time finding an authoritative reference here (Samba
people might be able to help), but my understanding is that Windows
gives this a meaning something like "may I delete a link to this file".

(And not even "may I delete the *last* link to this file", which might
also sound more logical.)

I just did a recent patch here. In Samba we now check for
SEC_DIR_ADD_FILE/SEC_DIR_ADD_SUBDIR on the target directory
(depending on if the object being moved is a file or dir).

And MAY_DELETE_SELF as well, for rename?  That's really counterintuitive for me.

Yes, MAY_DELETE_SELF applies to delete as well as rename; otherwise
rename() would behave different from link() + unlink(); when a user
has the appropriate permissions, the result should be the same though.

Thanks,
Andreas