On Tue, Dec 06, 2016 at 10:25:22PM +0100, Miklos Szeredi wrote: > On Tue, Dec 6, 2016 at 10:13 PM, Jeremy Allison <jra@xxxxxxxxx> wrote: > > On Tue, Dec 06, 2016 at 03:15:29PM -0500, J. Bruce Fields wrote: > >> On Fri, Dec 02, 2016 at 10:57:42AM +0100, Miklos Szeredi wrote: > >> > On Tue, Oct 11, 2016 at 2:50 PM, Andreas Gruenbacher > >> > <agruenba@xxxxxxxxxx> wrote: > >> > > 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. Yeah on the source handle we insist on DELETE_ACCESS|FILE_WRITE_ATTRIBUTES permissions also. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
