GNU bug report logs - #39236
[musl] coreutils cp mishandles error return from lchmod

Previous Next

Full log

View this message in rfc822 format

From: Rich Felker <dalias <at> libc.org>
To: Florian Weimer <fweimer <at> redhat.com>
Cc: musl <at> lists.openwall.com, 39236 <at> debbugs.gnu.org
Subject: bug#39236: [musl] coreutils cp mishandles error return from lchmod
Date: Wed, 22 Jan 2020 10:15:07 -0500

On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote:
> * Rich Felker:
> 
> > On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote:
> >> * Rich Felker:
> >> 
> >> > coreutils should be opting to use the system-provided lchmod, which is
> >> > safe, and correctly handling error returns (silently treating
> >> > EOPNOTSUPP as success) rather than as hard errors.
> >> 
> >> glibc's lchmod always returns ENOSYS (except on Hurd).  I don't know how
> >> lchmod is used in coreutils, but I suspect it is not particularly
> >> useful.
> >
> > When preserving permissions (cp -p, archive extraction, etc.), you
> > want lchmod to work correctly just for the purpose of *not* following
> > the link and thereby unwantedly changing the permissions of the link
> > target. But, fchmodat with AT_SYMLINK_NOFOLLOW works just as well and
> > is standard, and that's really what coreutils should be using.
> 
> I think you misread what I wrote: lchmod *always* returns ENOSYS.  Even
> if the file is not a symbolic link.  Likewise, fchmodat with
> AT_SYMLINK_NOFOLLOW *always* returns ENOTSUP.

Yes, I understood that. I was going into why there should be a real
implementation, but didn't make it clear that that was what I was
doing.

> The reason for this is that the kernel does not provide a suitable
> system call to implement this, even though some file systems allow a
> mode change for symbolic links.  I think we can do better, although I
> should note that each time we implement such emulation in userspace, it
> comes back to bite us eventually.

Emulations in userspace that are approximate, have race conditions,
etc. are bad. Ones that are rigorous are good, though.

Rich

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.