From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5231 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl 1.0.x branch Date: Wed, 11 Jun 2014 09:09:37 -0400 Message-ID: <20140611130937.GR179@brightrain.aerifal.cx> References: <20140606175617.GA3914@brightrain.aerifal.cx> <20140609112352.1e7ad51e@ncopa-desktop.alpinelinux.org> <20140609200830.GK179@brightrain.aerifal.cx> <20140610094351.GE20596@example.net> <20140610160356.GL179@brightrain.aerifal.cx> <20140610203247.GG20596@example.net> <20140610215156.GO179@brightrain.aerifal.cx> <20140611102314.GI20596@example.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1402492197 6097 80.91.229.3 (11 Jun 2014 13:09:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Jun 2014 13:09:57 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5236-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jun 11 15:09:51 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WuiHn-0008Hp-1o for gllmg-musl@plane.gmane.org; Wed, 11 Jun 2014 15:09:51 +0200 Original-Received: (qmail 25827 invoked by uid 550); 11 Jun 2014 13:09:49 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 25817 invoked from network); 11 Jun 2014 13:09:49 -0000 Content-Disposition: inline In-Reply-To: <20140611102314.GI20596@example.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5231 Archived-At: 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