[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260923134051.GA20206@brightrain.aerifal.cx>
Date: Wed, 23 Sep 2026 09:40:51 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Default path search for locale - request for comments
One goal for the outcome of the locale overhaul making locales
actually usable was to get rid of the requirement of having the
MUSL_LOCPATH environment variable set to enable loading, which does
not work with suid binaries and precluded any support for running them
in anything but C/C.UTF-8 locale. It was also an impediment even to
non-suid use, since users in an environment-scrubbed setting might
find LC_* variables suddenly not working for them.
So, we need to pick a default search path.
Overriding the path will still be an option but limited to the
libc.secure==0 case (i.e. unavailable to suid binaries) as it is now.
We may pick a different name for the override variable just to avoid
clashing with names anyone using the old locale framework with old
binaries might be using.
I know this is very much a bikeshed topic, so I am laying out some
contraints below for properties a default path needs to satisfy and
going over some things that have already been proposed on IRC and
other channels, grouped by whether they are rejected (with reasons) or
under consideration. Please read and be aware of these if you want to
participate in the discussion.
Design constraints for a default path:
- It should not be dependent on configure-time --prefix. Having it
depend on prefix would make it so static binaries built from a
toolchain installed in a nonstandard prefix, or on a distro that
uses an unusual prefix, fail to find locales when run on a standard
musl-based system.
- It cannot search locations that are expected to be writable by
(non-root) users.
- It should avoid imposing new rules on filesystem layout beyond
assumptions we already make on absolute paths.
- It should be configurable by the administrator without the need to
modify a filesystem that's allowed to be read-only.
Based on these constaints, the proposal I've made on IRC is that the
default path be something under /etc. This is *not* a place you are
expected to store the actual installed locale files (doing so would
violate FHS); rather, the expectation is that it would be a symlink
allowing administrators and integrators to configure where they have
locales installed to avoid hard-coding any expectation of where the
distro puts things and to allow an administrator to opt out of using
the distro-provided files and instead use their own build (where they
may have different opinions about what cultural conventions their
locales should reflect).
Some particular rejected ideas:
/usr/share/locale - This path already belongs to gettext localization
for applications, and contains ll[_TT]/LC_MESSAGES/$textdomain.mo
files.
/usr/lib/locale - This is what glibc uses and is probably not
FHS-compliant but is grandfathered in.
/var/... - The entire /var tree is for runtime-modifiable data/state,
not configuration (which this is) or read-only tables (which the
configuation points to).
/locale/... - Not FHS-compliant, seriously overstepping bounds.
$prefix/... - See above.
/usr/share/... (as the only search path) - This does not meet the need
to be configurable, as it's a path managed by the package manager and
expected to be read-only.
/etc/locale* - Clashes with too many random/bogus things.
Some non-rejected ideas that have been proposed:
/etc/musl/locale -> [location] - Clearly belongs to musl, unambiguous.
My only hesitation is that it suggests that it invites inventing other
things to put in /etc/musl, which we probably should not be doing.
/etc/muslocale -> [location] - Probably not a serious name, but the
general pattern of "name at the top level of /etc that's chosen to be
clearly non-clashing" is reasonable.
Borderline ideas:
/usr/share/..., (either as part of a multi-path search, or to use if a
configured location (via symlink) in /etc doesn't exist) - I'm
hesitant to do this because as a policy we generally don't invent new
things that depend on a particlar layout of /usr or other parts of the
filesystem. The only uses of /usr we have now are for things with
strong historical precedent for files that are not libc-impl-dependent
but used by all libcs, like /usr/share/zoneinfo and the default execvp
search path if $PATH is unset. (Note: default dynamic linker path also
includes /usr/[local/]lib, but this is not something that is baked
into static binaries, only the installed ldso.)
/etc/musl/locale (or similar) as a "symlink containing data" (like
openbsd malloc uses) where the symlink contents would be a full
:-separated search path - This is nice in that it lets you configure a
full default search path rather than just a link to one directory, but
it requires more machinery in the locale loading code to read it in.
/etc/musl/locale.conf (or similar) as a file containing a search path
in the file body - This is "more conventional" than the "symlink
containing data" approach, but adds considerable syscall overhead at
startup compared to the symlink or symlink-containing-data approach.
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.
