Linux Manual Pages development
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Rich Felker <dalias@libc.org>
Cc: John Scott <jscott@posteo.net>,
	 musl@lists.openwall.com, tg@trevorgross.com,
	 linux-man@vger.kernel.org, libc-alpha@sourceware.org
Subject: Re: [musl] Re: async-signal-safety of chroot
Date: Wed, 23 Sep 2026 10:38:01 +0200	[thread overview]
Message-ID: <lhu4ifge51y.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <20260923044048.GU23438@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 23 Sep 2026 00:40:48 -0400")

* Rich Felker:

> On Wed, Sep 23, 2026 at 04:17:03AM +0000, John Scott wrote:
>> On Tue, 2026-09-22 at 21:34 -0400, Rich Felker wrote:
>> > Since it's no longer standard, there is no standard governing chroot,
>> 
>> On this claim only, I believe you're technically mistaken: ISO/IEC
>> 23360-1-2:2021 (Linux Standard Base: Core specification generic
>> part) is a current International Standard. It incorporates the
>> definition of chroot() from SUSv2 by reference without amendment, so
>> the same async-signal-safety limitations apply.
>
> Linux Standard Base is not relevant. It is not a standard musl aims to
> conform to, and it is largely an ad hoc third party description of a
> very old version of the glibc ABI and its integration into Red Hat
> Linux.

And glibc does not aim to conform to Linux Standard Base, either.  Only
very few architectures meet the symbol version requirements in ISO/IEC
23360-1-2:2021.  Any architecture that was added after glibc 2.3 is not
compliant (not even with the generic part).  This is a defect in the
standard.

Thanks,
Florian


  reply	other threads:[~2026-09-23  8:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-23  0:53 async-signal-safety of chroot tg
2026-09-23  1:34 ` [musl] " Rich Felker
2026-09-23  4:17   ` John Scott
2026-09-23  4:40     ` [musl] " Rich Felker
2026-09-23  8:38       ` Florian Weimer [this message]
2026-09-23 23:21   ` Trevor Gross
2026-09-24  0:34   ` Trevor Gross
2026-09-24  2:12     ` [musl] " Rich Felker
2026-09-24  9:21       ` Florian Weimer
2026-09-23 23:38 ` [PATCH 1/2] man/man2/chroot.2: Document that chroot is AS-safe Trevor Gross
2026-09-23 23:38 ` [PATCH 2/2] man/man2/fork.2: Document glibc and musl relaxed fork->exec AS requirements Trevor Gross
2026-09-23 23:47   ` [musl] " Rich Felker
2026-09-25 19:54     ` Florian Weimer
2026-10-02  6:50       ` Trevor Gross
2026-10-03 20:48         ` Gabriel Ravier

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=lhu4ifge51y.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=dalias@libc.org \
    --cc=jscott@posteo.net \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --cc=musl@lists.openwall.com \
    --cc=tg@trevorgross.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox