[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 11 Jun 2014 16:37:46 +0200
From: u-igbb@...ey.se
To: musl@...ts.openwall.com
Subject: Re: musl 1.0.x branch
On Wed, Jun 11, 2014 at 09:09:37AM -0400, Rich Felker wrote:
> any
> function dependent on any environment variable is not thread-safe if
> another thread is modifying the environment; see XSH exec."
> This makes "dependent on an environment variable" a formal property of
> standard interfaces which introduces subtle breakage if/when a
> function which is not specified to be dependent on an environment
> variable actually uses one.
Oh indeed. Seen from this angle the problem is apparent.
> The only safe solution I know to this
> problem is to do the environment processing at program start time.
I am not really afraid of such thread-related breakage (even if the
application uses threads, the chance of corruption is quite low).
Nevertheless I'll aim to fix the patches and move the value fetches
to the startup, as you mention.
> Hopefully this only affects programs using paths.h or similar, which
> are legacy mess I just left around because it sometimes helps build
> programs which are otherwise a pain to build.
The programs including paths.h are in a sense "well behaving",
the other ones which boldly use hardcoded strings are more
unfriendly to modifications. In my eyes path.h should exist, be used
and actually define the databases-related-macros, which would serve
as the redirection means - it is what we do.
A path.h with mere constants is indeed a nuisance.
> > Yes I looked at it - it is unfortunately also a solution for goals
> > "other than ours". AFAICS it still assumes a hardcoded database
> > placement (/etc/tcb).
>
> Yes. I suppose it wouldn't fundamentally have to do so, since programs
> authenticating user accounts would be configured to the right location
> for the system user database, but it seems safest (and of course
> simplest) to always use that location anyway.
No matter which location this would be, it is one constant for all concerned
processes, assuming a single database instance in a local place to be used
by all processes on the host - the Unix practice hardly ever questioned
by anyone :( aka "blindly followed for ages" :)
> Yes. BTW your approach is also very nice from a unit-testing
> perspective. It's hard to test things like dns resolver, user
> database, etc. due to the difficulty of mocking in controlled
> configurations for them. Modern Linux does however provide user
I would be happy to rework and submit the patches, indeed they are a
straightforward and fine-grained instance isolation tool, without the
constraints of chroot and similar. Just never setuid the binaries
using the resulting library :)
> namespaces / mount namespaces which allow doing this, and that's
> probably what we'll use for testing at least in the short-term (it
> also makes it easy to apply the tests to other libcs).
It is nice to have a choice.
Regards,
Rune
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.
