Re: musl 1.0.x branch

[Rich Felker <dalias@libc.org>]

On Wed, Jun 11, 2014 at 12:24:19PM +0200, u-igbb@aetey.se wrote:
> > In any case, it's also a matter of maintenance cost. Supporting
> > environment variables to override these things is not always trivial.
> > Some (most?) of these interfaces are required to be thread-safe and
> > accessing the environment is not thread-safe with respect to other
> > threads modifying it. There may also be storage/allocation burdens
> 
> Do you mean that getenv("SOMETHING") can be screwed if a different
> thread is doing setenv("SOMETHINGELSE",...) at a wrong time?

Indeed. In POSIX, being non-thread-safe (which setenv is) is a very
strong condition: it allows behaviors such as the above. Also note
that you can modify the environment via extern char **environ, and in
fact doing so with (compiler-specific or C11) atomics is the only safe
way to modify the environment in a multithreaded program.

> (This "SOMETHING"'s value is _not_ to be modified under the lifetime of
> the process.)

Indeed, but the environment could otherwise be modified.

XSH 2.9.1 Thread-Safety reads:

"Since multi-threaded applications are not allowed to use the environ
variable to access or modify any environment variable while any other
thread is concurrently modifying any environment variable, 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. The only safe solution I know to this
problem is to do the environment processing at program start time.

> > when allowing a custom runtime path requires concatenating it with
> > another string. Even if none of this were difficult, it's extra
> 
> An unmodified program can be impossible to compile against the
> modified libc as we do it, as certain macros become no longer constants
> but expressions to evaluate at run time. This is of course expected.

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.

> > > We solve this pretty straightforwardly by using environment variables,
> > > pointing to a relevant "shadow" file and/or pam configurations.
> > 
> > Note that the "tcb shadow" support in musl already provides this
> > functionality. For your purposes, of course, you already have path
> > override so it makes sense just to use the same tool you're using for
> > everything else. But for other uses outside yours, tcb shadow is a
> > really nice solution to this problem.
> 
> 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.

> In this sence it is orthogonal to what we do, we
> may choose to use it for its nice virtues but we still need to be able
> to point out the necessary tcb shadow database instance per process,
> not per compiled binary.

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
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).

Rich