From: Rich Felker <dalias@libc.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: 39236@debbugs.gnu.org, musl@lists.openwall.com
Subject: Re: [musl] coreutils cp mishandles error return from lchmod
Date: Wed, 22 Jan 2020 10:15:07 -0500 [thread overview]
Message-ID: <20200122151507.GB30412@brightrain.aerifal.cx> (raw)
In-Reply-To: <87a76fjzpx.fsf@oldenburg2.str.redhat.com>
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
next prev parent reply other threads:[~2020-01-22 15:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-22 14:15 Rich Felker
2020-01-22 14:34 ` Florian Weimer
2020-01-22 14:42 ` Rich Felker
2020-01-22 15:08 ` Florian Weimer
2020-01-22 15:15 ` Rich Felker [this message]
2020-01-22 15:32 ` Florian Weimer
2020-01-22 16:07 ` Rich Felker
2020-01-22 16:19 ` Florian Weimer
2020-01-22 17:15 ` Rich Felker
2020-01-22 20:48 ` Florian Weimer
2020-01-22 20:56 ` Rich Felker
2020-01-22 21:05 ` Florian Weimer
2020-01-22 21:55 ` bug#39236: " Paul Eggert
2020-01-22 22:05 ` Rich Felker
2020-02-08 0:37 ` Paul Eggert
2020-02-12 11:50 ` Florian Weimer
2020-02-12 13:05 ` Rich Felker
2020-02-12 19:07 ` Rich Felker
2020-02-12 19:13 ` Florian Weimer
2020-02-12 19:59 ` A. Wilcox
2020-02-12 20:56 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200122151507.GB30412@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=39236@debbugs.gnu.org \
--cc=fweimer@redhat.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).