[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lhu4ifge51y.fsf@oldenburg.str.redhat.com>
Date: Wed, 23 Sep 2026 10:38:01 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Rich Felker <dalias@...c.org>
Cc: John Scott <jscott@...teo.net>, musl@...ts.openwall.com,
tg@...vorgross.com, linux-man@...r.kernel.org,
libc-alpha@...rceware.org
Subject: Re: Re: async-signal-safety of chroot
* 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
