Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260923013428.GT23438@brightrain.aerifal.cx>
Date: Tue, 22 Sep 2026 21:34:28 -0400
From: Rich Felker <dalias@...c.org>
To: tg@...vorgross.com
Cc: linux-man@...r.kernel.org, musl@...ts.openwall.com,
	libc-alpha@...rceware.org
Subject: Re: async-signal-safety of chroot

On Wed, Sep 23, 2026 at 12:53:16AM +0000, tg@...vorgross.com wrote:
> Hi everyone,
> 
> Is `chroot` async-signal-safe?
> 
> It is a somewhat popular pattern to `fork`, `chroot`, then `exec`.
> However, only AS-safe functions may be called between `fork` and `exec`
> (stated at [1]) but the manual entry for `chroot` makes no such mention
> [2]. signal-safety(7) [3] only covers POSIX, so it is also not listed
> there.
> 
> The rather old POSIX edition that last specified chroot also does not
> mark it AS-safe [4], [5].
> 
> Is code using this pattern buggy, or is it just missing documentation?
> I expect it's the latter but it would be nice to confirm either way.

The restriction to only using AS-safe functions after fork only
applies in multi-threaded processes. So unless your process is
multi-threaded, that's a non-issue.

Since it's no longer standard, there is no standard governing chroot,
but in practice on most systems, including Linux/musl, chroot is going
to be AS-safe because it's just a single syscall.

Also, both glibc and musl relax the restriction on only calling
AS-safe functions in the child after a multi-threaded parent forks. In
glibc this is sort of a best-effort thing, but in musl we went through
a detailed process of ensuring that everything is made consistent for
the child. The only thing that might not be consistent is dynamic
linker state, which might make it impossible to dlopen in the child,
but this is treated as a reportable error condition not a crash or
deadlock or anything.

The changes to lift the restrictions on the child happened in commit
167390f05564e0a4d3fcb4329377fd7743267560

Rich

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.