[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260923142601.GW23438@brightrain.aerifal.cx>
Date: Wed, 23 Sep 2026 10:26:02 -0400
From: Rich Felker <dalias@...c.org>
To: Pablo Correa Gomez <pabloyoyoista@...tmarketos.org>
Cc: musl@...ts.openwall.com
Subject: Re: Default path search for locale - request for comments
On Wed, Sep 23, 2026 at 10:17:08AM -0400, Rich Felker wrote:
> On Wed, Sep 23, 2026 at 04:04:01PM +0200, Pablo Correa Gomez wrote:
> > Hi Rich,
> >
> > It seems we just talked over each other in 2 different threads
> >
> > El Wed, 23-09-2026 a las 09:40 -0400, Rich Felker escribió:
> > > 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).
> >
> > I really dislike the idea to hard-code something that is not standards-
> > compliant, as anybody following a standard would have to violate it (place a
> > system-symlink under /etc) just to make it compliant.
>
> I don't understand what you think is not standards-compliant here. We
> are talking about storing in /etc a configuration for where to look
> for a particular resource. As I see it this is very much the same
> thing as having the system-wide library search path stored in
> /etc/ld-musl-$ARCH.path, having the DNS stored in /etc/resolv.conf,
> and so on.
>
> Can you clarify what you think is nonconforming here? My best guess is
> that you misunderstood it as actually storing installed locale files
> there (which would very much be a bad thing, and non-conforming), but
> if that's not the case I'd like to know so we can figure this out.
I didn't see you'd replied to the other thread when I wrote this. I'll
take a look and see if that answers my questions and follow up here.
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.
