From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 84C10138206 for ; Wed, 17 Jan 2018 15:41:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0199CE09F6; Wed, 17 Jan 2018 15:41:29 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A6EDFE09C4 for ; Wed, 17 Jan 2018 15:41:28 +0000 (UTC) Received: from [192.168.1.100] (c-98-218-46-55.hsd1.md.comcast.net [98.218.46.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id D95B9335C38 for ; Wed, 17 Jan 2018 15:41:26 +0000 (UTC) Subject: Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue To: gentoo-dev@lists.gentoo.org References: <20180110000741.GA3995@whubbs1.gaikai.biz> <14e5af26-fdb7-802c-e6d2-7a69c5115e0d@gentoo.org> <20180110180443.GA1085@whubbs1.gaikai.biz> <20180110215437.GA3156@whubbs1.gaikai.biz> <731ea2b8-349d-28d4-72a6-3b9555f5bdf7@gentoo.org> <20180117152108.GA9130@linux1.home> From: Michael Orlitzky Message-ID: <04627c1a-64b7-9370-41d8-ddc79213de5b@gentoo.org> Date: Wed, 17 Jan 2018 10:41:21 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <20180117152108.GA9130@linux1.home> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: dd1e740b-3cce-464c-940e-28d14eea06ac X-Archives-Hash: 032b61a569c9ea9eff2574c27c6c81cf On 01/17/2018 10:21 AM, William Hubbs wrote: > > For both A and B above I think you mean owner/group/permissions right? Yep. >> 2. It should have a flag (say, --as=[:group]) to make it run as >> an unprivileged user. Basically a portable "su -c". > > I'm not following why I need this. > >> 3. It should die if it's used in a directory that is writable by >> anyone other than itself or root. (If it's feasible, we might want >> to check the parent directories all the way up to the root; if I can >> write to "b", then I can write to "e" in /a/b/c/d/e.) > >> Since newpath can't modify existing paths, the aforementioned "--as" >> flag will be needed to avoid this error. > > Which error are you referring to? I don't follow you here. I don't see > how newpath not modifying existing paths is related to this. > If I want to create /run/foo and /run/foo/bar, both owned by the "foo" user, how would I do it using newpath? 1. I could create /run/foo with owner "foo", and then create /run/foo/bar with owner "foo". That can be done without modifying existing permissions, but it's not safe, because you wind up working as root in the directory /run/foo which is owned by the non-root "foo" user. If newpath disallows that unsafe operation, this approach is out. 2. I could create /run/foo as root:root, and then create /run/foo/bar as "foo". That much is safe, but then what do I do about /run/foo? It already exists, so if newpath will refuse to modify existing paths, then this approach is out too. That leaves... 3. I can create /run/foo with owner "foo", and then setuid to the foo user. Now, *as the foo user* I can create /run/foo/bar, which will be owned by "foo". There's no risk in doing so, because the "foo" user can only trick himself. Moreover, the directory is writable only by root and the OpenRC user (currently: foo) at that point, so the extra safety precautions don't get in the way.