From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6823 Path: news.gmane.org!not-for-mail From: stephen Turner Newsgroups: gmane.linux.lib.musl.general Subject: Re: Fixing multithreaded set*id() AS-safety Date: Sun, 11 Jan 2015 11:31:55 -0500 Message-ID: References: <20141220033918.GA3273@brightrain.aerifal.cx> <20150110053321.GD4574@brightrain.aerifal.cx> <20150111040717.GH4574@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113aa9f28be84a050c62ed89 X-Trace: ger.gmane.org 1420993935 27269 80.91.229.3 (11 Jan 2015 16:32:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 Jan 2015 16:32:15 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6836-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jan 11 17:32:10 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 1YALQv-0005ow-G5 for gllmg-musl@m.gmane.org; Sun, 11 Jan 2015 17:32:09 +0100 Original-Received: (qmail 16111 invoked by uid 550); 11 Jan 2015 16:32:06 -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 16103 invoked from network); 11 Jan 2015 16:32:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=mXN26quOHNRECrN+9D/K2x7BMXCcfvVpAOHS+4s1TAU=; b=f/FXGJn7d4CJ1IT09cT664N615LJv8TKC9TmDZhzn4+3m9yzG46NC3Hr+E8yhp7scO u5r2+NoFyGCWVYjn0kUD7Ug5MyXZkYe1/3wkmDrJ+NgcDlw8yG4o9ue7W6gKPztp8B5w Nhhao/qXfpvrQuglmCvI2qsB7poLYpEOxqrpWLjovER59x6YuL2jyf6gJBh5h1LLeKpE E0YAko1BJuWBmzkIl7vsZOnGLoCUsgTBVYOAEodQ1GGBffcG9Ol5nVA9t+wBjUE1JerK xaiN9JPoGfOX7aHSV8+0EuOhKNoxJUywXL2tG1FeHhoEwiEzxE2ByLCZGvuPlKLiILdA i5sA== X-Received: by 10.170.85.70 with SMTP id c67mr21831467yka.107.1420993915249; Sun, 11 Jan 2015 08:31:55 -0800 (PST) In-Reply-To: <20150111040717.GH4574@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:6823 Archived-At: --001a113aa9f28be84a050c62ed89 Content-Type: text/plain; charset=UTF-8 On Jan 10, 2015 11:07 PM, "Rich Felker" wrote: > > On Sat, Jan 10, 2015 at 05:52:45PM -0500, stephen Turner wrote: > > Does that require any special requirementd in the way of modules or > > settings to use from the kernel? If proc doesnt exist what will happen? A > > kernel panic, absence of threading or will it create the missing folders or > > such? > > No. As mentioned (I think) earlier, if /proc is not mounted, > multi-threaded set*id would not be able to work, but would just report > failure. Nothing would blow up. I'm not sure if it's a problem for > multi-threaded set*id not to work without /proc mounted, but in > general: > > - Various functions in musl already require /proc to operate correctly > because the kernel does not provide a way to do the necessary > operations without /proc. Some of these are less arcane than > multi-threaded set*id. > > - It's rather a bad design to be calling setuid in a multi-threaded > process to begin with; usually it happens only in Java or other > "higher level" langs where you're calling out to setuid via some > native interface and it's hard to prevent multiple threads from > already existing at that point. These sorts of programs should not > be running early boot before /proc is mounted. > > If failure when /proc is not mounted is really a problem, I'm not sure > how we solve it. But in any case, I think we should start pushing for > the kernel to fix this issue properly: with a syscall that affects all > threads atomically, so that all this mess is used only as a fallback > for old kernels. > > Rich Thanks Rich for the details. You had mentioned it would fail but my experience says that any failure leads to a system meltdown. Im not used to failures not being the end of the world. I include proc so for me theres no issue. I guess my devils advocate kicked in. --001a113aa9f28be84a050c62ed89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jan 10, 2015 11:07 PM, "Rich Felker" <dalias@libc.org> wrote:
>
> On Sat, Jan 10, 2015 at 05:52:45PM -0500, stephen Turner wrote:
> > Does that require any special requirementd in the way of modules = or
> > settings to use from the kernel? If proc doesnt exist what will h= appen? A
> > kernel panic, absence of threading or will it create the missing = folders or
> > such?
>
> No. As mentioned (I think) earlier, if /proc is not mounted,
> multi-threaded set*id would not be able to work, but would just report=
> failure. Nothing would blow up. I'm not sure if it's a problem= for
> multi-threaded set*id not to work without /proc mounted, but in
> general:
>
> - Various functions in musl already require /proc to operate correctly=
> =C2=A0 because the kernel does not provide a way to do the necessary > =C2=A0 operations without /proc. Some of these are less arcane than > =C2=A0 multi-threaded set*id.
>
> - It's rather a bad design to be calling setuid in a multi-threade= d
> =C2=A0 process to begin with; usually it happens only in Java or other=
> =C2=A0 "higher level" langs where you're calling out to = setuid via some
> =C2=A0 native interface and it's hard to prevent multiple threads = from
> =C2=A0 already existing at that point. These sorts of programs should = not
> =C2=A0 be running early boot before /proc is mounted.
>
> If failure when /proc is not mounted is really a problem, I'm not = sure
> how we solve it. But in any case, I think we should start pushing for<= br> > the kernel to fix this issue properly: with a syscall that affects all=
> threads atomically, so that all this mess is used only as a fallback > for old kernels.
>
> Rich

Thanks Rich for the details. You had mentioned it would fail= but my experience says that any failure leads to a system meltdown. Im not= used to failures not being the end of the world.

I include proc so for me theres no issue. I guess my devils = advocate kicked in.

--001a113aa9f28be84a050c62ed89--