From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13318 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: setrlimit hangs the process Date: Tue, 25 Sep 2018 12:38:50 -0400 Message-ID: <20180925163850.GL17995@brightrain.aerifal.cx> References: <20180925141551.GE10209@port70.net> <20180925153605.GF10209@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1537893418 18587 195.159.176.226 (25 Sep 2018 16:36:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Sep 2018 16:36:58 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13334-gllmg-musl=m.gmane.org@lists.openwall.com Tue Sep 25 18:36:54 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1g4qKU-0004kF-Ae for gllmg-musl@m.gmane.org; Tue, 25 Sep 2018 18:36:54 +0200 Original-Received: (qmail 9860 invoked by uid 550); 25 Sep 2018 16:39:03 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9834 invoked from network); 25 Sep 2018 16:39:02 -0000 Content-Disposition: inline In-Reply-To: <20180925153605.GF10209@port70.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13318 Archived-At: On Tue, Sep 25, 2018 at 05:36:05PM +0200, Szabolcs Nagy wrote: > * Rabbitstack [2018-09-25 16:54:37 +0200]: > > Sorry. Let me describe the problem in more detail. > > > > The process only hangs when launched without root privileges on the host > > (Arch Linux x64 with kernel 4.17.5-1) where Alpine docker container is > > running. Once with root privileges, it starts up correctly (but this is > > obvious since it doesn't hit setrlimit call). The odd side is that on other > > hosts it hangs even when started with root. No error messages so far. > > Strace output: > > > > $ sudo strace -p 9285 > > > > futex(0x2cddfc0, FUTEX_WAIT_PRIVATE, 0, NULL > > > > $ sudo strace -f -p 9285 > > > > ..... > > [pid 9287] getdents64(10, /* 14 entries */, 2048) = 336 > > [pid 9287] tgkill(9285, 9285, SIGRT_2) = 0 > > [pid 9287] futex(0x7efbff70008c, FUTEX_LOCK_PI_PRIVATE, > > {tv_sec=1537887068, tv_nsec=51442144}) = -1 ETIMEDOUT (Connection timed out) > > it looks like musl tries to sync a setuid call across > all threads (which is necessary since the linux syscall > only changes the uid for the current thread instead of > all threads so you can end up with different privileges > in the same address space which is dangerous as well as > non-posix conform setuid behaviour) > > it's possible that the setuid syncing is somehow wrong > in musl, but it's more likely that there are threads > that are not created by the c runtime (but from go) and > thus the sync cannot possibly work. It actually can kinda work with such threads. musl's stop-the-world __synccall pokes all kernel-level threads in the same process (thread group) as the caller using signals and /proc/self/task to ensure it didn't miss any, so it will work as long as they haven't blocked libc-internal signals. There may be problems with the thread pointer being invalid, though. The __synccall framework itself does not use the TCB, but other stuff in the callback might. This should probably be fixed. > so try to look for where set*id is called and ensure it > is not called or called before any threads are created > (or at least before any go threads are created) > > note that syscall.Set*id from go does not work either, > it does not sync the threads (which is dangerously > broken for a runtime that's always multi-threaded). Yep, that's unsafe to use. Any use is likely exploitable. Rich