Return-Path: Received: from mail-oi0-f66.google.com ([209.85.218.66]:36858 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752592AbcLFVZX (ORCPT ); Tue, 6 Dec 2016 16:25:23 -0500 Received: by mail-oi0-f66.google.com with SMTP id u15so43058475oie.3 for ; Tue, 06 Dec 2016 13:25:23 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20161206203347.GC4498@jra3> References: <1476190256-1677-1-git-send-email-agruenba@redhat.com> <1476190256-1677-4-git-send-email-agruenba@redhat.com> <20161206201529.GA1203@fieldses.org> <20161206203347.GC4498@jra3> From: Miklos Szeredi Date: Tue, 6 Dec 2016 22:25:22 +0100 Message-ID: Subject: Re: [PATCH v27 03/21] vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags To: Jeremy Allison Cc: "J. Bruce Fields" , Andreas Gruenbacher , Alexander Viro , Christoph Hellwig , "Theodore Ts'o" , Andreas Dilger , Jeff Layton , Trond Myklebust , Anna Schumaker , Dave Chinner , "linux-ext4@vger.kernel.org" , LKML , linux-fsdevel , Linux NFS list , linux-cifs@vger.kernel.org, Linux API Content-Type: text/plain; charset=UTF-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: On Tue, Dec 6, 2016 at 10:13 PM, Jeremy Allison 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 >> > 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. Thanks, Miklos