Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod

[Rich Felker <dalias@libc.org>]

On Wed, Feb 12, 2020 at 08:05:55AM -0500, Rich Felker wrote:
> On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote:
> > * Paul Eggert:
> > 
> > > On 1/22/20 2:05 PM, Rich Felker wrote:
> > >> I think we're approaching a consensus that glibc should fix this too,
> > >> so then it would just be gnulib matching the fix.
> > >
> > > I installed the attached patch to Gnulib in preparation for the upcoming 
> > > glibc fix. The patch causes fchmodat with AT_SYMLINK_NOFOLLOW to work on 
> > > non-symlinks, and similarly for lchmod on non-symlinks. The idea is to 
> > > avoid this sort of problem in the future, and to let Coreutils etc. work 
> > > on older platforms as if glibc 2.32 (or whatever) is already in place.
> > 
> > The lchmod implementation based on /proc tickles an XFS bug:
> > 
> >   <https://sourceware.org/ml/libc-alpha/2020-02/msg00467.html>
> 
> Uhg, why does Linux even let the fs driver see whether the chmod is
> being performed via a filename, O_PATH fd, or magic symlink in /proc?
> It should just be an operation on the inode.

OK, I don't think it's actually clear from the test that the use of
the magic symlink is the cause. It's plausible that XFS just always
returns failure on success for this operation, and I don't have XFS to
test with.

Note that in any case, musl's lchmod/fchmodat is not affected since it
always refuses to change symlink modes; I did this because I was
worried that chmod on the magic symlink in /proc might pass through
not just to the symlink it refers to, but to the symlink target if one
exists. With current kernel versions it seems that does not happen; is
it safe to assume it doesn't?

Further, I've found some inconsistent behavior with ext4: chmod on the
magic symlink fails with EOPNOTSUPP as in Florian's test, but fchmod
on the O_PATH fd succeeds and changes the symlink mode. This is with
5.4. Cany anyone else confirm this? Is it a problem?

Rich