linux-kernel - Re: [PATCH] vfs: add fchmodat2 syscall

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200910163949.GJ3265@brightrain.aerifal.cx>
Date:   Thu, 10 Sep 2020 12:39:50 -0400
From:   Rich Felker <dalias@...c.org>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     linux-api@...r.kernel.org,
        Alexander Viro <viro@...iv.linux.org.uk>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vfs: add fchmodat2 syscall

On Thu, Sep 10, 2020 at 05:20:59PM +0100, Christoph Hellwig wrote:
> On Thu, Sep 10, 2020 at 10:23:37AM -0400, Rich Felker wrote:
> > userspace emulation done in libc implementations. No change is made to
> > the underlying chmod_common(), so it's still possible to attempt
> > changes via procfs, if desired.
> 
> And that is the goddamn problem.  We need to fix that _first_.

Can you clarify exactly what that is? Do you mean fixing the
underlying fs backends, or just ensuring that the chmod for symlinks
doesn't reach them by putting the check in chmod_common? I'm ok with
any of these.

> After that we can add sugarcoating using new syscalls if needed.

The new syscall is _not_ about this problem. It's about the missing
flags argument and inability to implement fchmodat() without access to
procfs. The above problem is just something you encounter and have to
make a decision about in order to fix the missing flags problem and
make a working AT_SYMLINK_NOFOLLOW.

Rich