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 75D97138330 for ; Sat, 13 Jan 2018 20:48:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 08556E0948; Sat, 13 Jan 2018 20:48:20 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 AF5EAE093D for ; Sat, 13 Jan 2018 20:48:19 +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 73E05335C5D for ; Sat, 13 Jan 2018 20:48:18 +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> From: Michael Orlitzky Message-ID: <731ea2b8-349d-28d4-72a6-3b9555f5bdf7@gentoo.org> Date: Sat, 13 Jan 2018 15:48:10 -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: <20180110215437.GA3156@whubbs1.gaikai.biz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: 07e8f78e-9671-4244-834f-2702d979ab59 X-Archives-Hash: 6853f0c608218f0458b451e24e9cb271 On 01/10/2018 04:54 PM, William Hubbs wrote: > > What are we saying newpath should do differently than checkpath if I > go this route? I think this covers everything that we've talked about: 1. It should refuse to modify existing paths. 1.a. If newpath is called on an existing path, and if the requested owner/permissions agree with the existing set, then do nothing. This is expected when services restart without a reboot. 1.b. If newpath is called on an existing path, and if the desired permissions differ from the existing set, then do nothing and log a warning. 2. It should have a flag (say, --as=[:group]) to make it run as an unprivileged user. Basically a portable "su -c". 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. And just to put it out there, this will probably make a lot of people mad. It discourages you from doing things like setting FOO_USER=foo in the conf.d file, because you can't "fix" the permissions on things like /var/log/foo.log if the value of $FOO_USER ever changes. That was inherently unsafe anyway, but I'll eat my shorts if nobody complains. (User variables, or RC_SVCNAME, should still work fine work multiple instances.)