From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7141 Path: news.gmane.org!not-for-mail From: William Ahern Newsgroups: gmane.linux.lib.musl.general Subject: Re: getenv_r Date: Wed, 4 Mar 2015 17:34:57 -0800 Message-ID: <20150305013457.GA20317@wilbur.25thandClement.com> References: <20150304230920.GA21838@wilbur.25thandClement.com> <20150305004133.GI16260@port70.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 1425519324 9494 80.91.229.3 (5 Mar 2015 01:35:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Mar 2015 01:35:24 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7154-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 05 02:35:22 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YTKh7-0004Eo-99 for gllmg-musl@m.gmane.org; Thu, 05 Mar 2015 02:35:21 +0100 Original-Received: (qmail 11901 invoked by uid 550); 5 Mar 2015 01:35:19 -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 11848 invoked from network); 5 Mar 2015 01:35:10 -0000 Content-Disposition: inline In-Reply-To: <20150305004133.GI16260@port70.net> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:7141 Archived-At: On Thu, Mar 05, 2015 at 01:41:33AM +0100, Szabolcs Nagy wrote: > * William Ahern [2015-03-04 15:09:20 -0800]: > > I noticed that getenv is not thread-safe. Would there be any interest in > > accepting a patch to implement getenv_r (a NetBSD function) and internal > > locking? Other than leaving getenv, setenv, and putenv unsafe in threaded > > environments, the only other alternative is the ugliness that glibc, > > Solaris, and some others implement, which is basically to leak environ > > memory. > > getenv is thread-safe if the environ is not modified > > in a multi-threaded application environ modification > is unsafe and problematic even if you do the locks: > different threads may want different value for an env > var and when you read an env var you cannot know if > it is up to date when you want to use it. That criticism applies to almost any software, no matter the interface, with or without locks. Locks don't solve all TOCTTOU bugs, either. Anyhow, any use of setenv is unsafe in a multi-threaded environment, even for different variables. In musl the __environ array is invalidated by a setenv call that needs to grow it. The system(3) implementation in musl passes __environ to posix_spawn. > does netbsd use getenv_r somewhere to solve some issue? There are a few uses in NetBSD, such as in librump, but AFAICT getenv_r isn't widely used. It just seems a much nicer interface than the contortions other libc libraries go through. One obvious use for a thread-safe setenv and getenv is when trying to generate a time_t timestamp from a UTC struct tm. timegm is not standard. The glibc manual page suggests to instead set the TZ environment variable to UTC, call tzset, call mktime, restore TZ, and call tzset again. You can't use that technique portably from multiple threads unless all code that might call setenv for any reason synchronizes on the same lock you use to implement timegm (including any locale code that needs to read LC_ values). Whereas the only code _setting_ TZ is likely to be the timegm code. But really the issue is most intractable in my position, where I'm trying to implement a bindings module. In Lua especially, where the Lua VM has no global state, it's simple to run Lua scripts in a multi-threaded environment and have them mostly just work without issue. But those scripts are exceedingly unlikely to have been concerned with thread-safety, and with setenv being unsafe to use. And they can't be expected to use synchronization primatives because module A might have no relationship to module B. I can't paper-over all thread issues, but I still think it worthwhile to make it as safe as possible. No amount of finger pointing would ever fix the problem. Granted, at the end of the day this may be none of musl's concern. Adding getenv_r certainly won't solve all issues. That would require other measures. But it does seem like a worthwhile QoI issue to address. I mean, presumably the system implementation uses posix_spawn rather out of concern for QoI. musl could have punted and simply disclaimed any support for threaded environments.