From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5234 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl 1.0.x branch Date: Wed, 11 Jun 2014 16:37:46 +0200 Message-ID: <20140611143746.GJ20596@example.net> 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> <20140611130937.GR179@brightrain.aerifal.cx> 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 1402497498 12218 80.91.229.3 (11 Jun 2014 14:38:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Jun 2014 14:38:18 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5239-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jun 11 16:38:12 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 1WujfI-0000wo-0t for gllmg-musl@plane.gmane.org; Wed, 11 Jun 2014 16:38:12 +0200 Original-Received: (qmail 17452 invoked by uid 550); 11 Jun 2014 14:38:10 -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 17444 invoked from network); 11 Jun 2014 14:38:10 -0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received-SPF: none receiver=mailfe05.swip.net; client-ip=171.25.193.20; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140611130937.GR179@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:5234 Archived-At: 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