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

Previous Next

Full log

View this message in rfc822 format

From: Florian Weimer <fweimer <at> redhat.com>
To: Rich Felker <dalias <at> libc.org>
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 16:08:26 +0100

* 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.

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.

Thanks,
Florian

Previous Next

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