Date: Wed, 11 Jun 2014 09:09:37 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: musl 1.0.x branch On Wed, Jun 11, 2014 at 12:24:19PM +0200, u-igbb@...ey.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
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.