linux-kernel - Re: [PATCH v27 03/21] vfs: Add MAY_DELETE_SELF and MAY_DELETE

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: <CAJfpegsvoZfzUXyCJrxXAG6dxk8HMCGMEKA0E-6FzWNGkM17Tw@mail.gmail.com>
Date:   Tue, 6 Dec 2016 22:25:22 +0100
From:   Miklos Szeredi <miklos@...redi.hu>
To:     Jeremy Allison <jra@...ba.org>
Cc:     "J. Bruce Fields" <bfields@...ldses.org>,
        Andreas Gruenbacher <agruenba@...hat.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christoph Hellwig <hch@...radead.org>,
        "Theodore Ts'o" <tytso@....edu>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Jeff Layton <jlayton@...chiereds.net>,
        Trond Myklebust <trond.myklebust@...marydata.com>,
        Anna Schumaker <anna.schumaker@...app.com>,
        Dave Chinner <david@...morbit.com>,
        "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux NFS list <linux-nfs@...r.kernel.org>,
        linux-cifs@...r.kernel.org, Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH v27 03/21] vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD
 permission flags

On Tue, Dec 6, 2016 at 10:13 PM, Jeremy Allison <jra@...ba.org> 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@...hat.com> 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