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 BD019138330 for ; Wed, 10 Jan 2018 21:54:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7FC69E0BE1; Wed, 10 Jan 2018 21:54:42 +0000 (UTC) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 308A7E0B94 for ; Wed, 10 Jan 2018 21:54:42 +0000 (UTC) Received: by mail-qk0-x22b.google.com with SMTP id w1so1316904qka.2 for ; Wed, 10 Jan 2018 13:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=blOHe6MOfKUvhodtgthMXUgFtv0sacpUNHhno+LDGgc=; b=rTObm5sCQzfQV2DsMUOmY0OTggcdr3TNMoWNznbQUYZ7LnftcYRFSSv4y0yiv2m/hm EvhtoLara/OPIxZ1Ovoe7LNmY4q83GwnQcxi8nQxzbeioQQWocBC2ogiLI2fNt3X9Y2P 2swqHG7hSAhsU00WZY2nbAp6SlHQbaqmmuEmgrmenzwRWtUOizXZxLDx7zzvZRQRUt2t bmopbyabIwgan4kAI5OPRWtCwQMO2KPSfGgro7move0fW3lIji8O6HDlF7SUHWGOhMcp v1cJdX++UrJ2vii2HjUk9xDspk900eyeeMKyQj2gjainrhepuX4RVq2NBVPh8tISRcKY 9ojA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=blOHe6MOfKUvhodtgthMXUgFtv0sacpUNHhno+LDGgc=; b=jBaixhFciRmJMIaL7PL/hcLL1AyZ4nrwnU0A7aROTCL5xI22qXoqXSHFakRhKdxGXV AZXFUbX8lPDQ2zwgdFlqafdXSV+d8OM7uTI8eB69Ak/dfnkPY1uEODMlQdR2Qk5ZjNmy ZFxitlwdArLGOSECehnXmgh32t5yOPOPNBvxMTr/gCik3EqYWfo/ggIbXfLqe6+b91e9 D5zOX5vC4qlwiFFccp0zDFDkD2w67iqHqVXqkLI7MdhVAG2CT+9wTLjUo/DYhrx7gZeT Y9e06Q0SPNg9D81lVueMfjnyvuN97yz3RF+cRT43p9eoq9TTfBiLgZUCfMvT2jWqQHL+ vwXg== X-Gm-Message-State: AKwxytc09+wDUmCrmaSSypWu5wT65x1TDQb6qNoZl8KMX8xEeIVlgWEZ KnXeRrnQc0TuTXC3SzB6B6RAiw== X-Google-Smtp-Source: ACJfBoutvYm5YZHCNHnTS4LI8I6oKhjy/7exFfGeDCiktcn4kn4J9rMsBolGYB65vXdYmv8AvOk7gg== X-Received: by 10.200.55.51 with SMTP id o48mr30107512qtb.41.1515621281026; Wed, 10 Jan 2018 13:54:41 -0800 (PST) Received: from whubbs1.gaikai.biz ([100.42.103.5]) by smtp.gmail.com with ESMTPSA id q189sm11543700qkd.78.2018.01.10.13.54.38 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 10 Jan 2018 13:54:39 -0800 (PST) Sender: William Hubbs Received: (nullmailer pid 3197 invoked by uid 1000); Wed, 10 Jan 2018 21:54:37 -0000 Date: Wed, 10 Jan 2018 15:54:37 -0600 From: William Hubbs To: gentoo-dev@lists.gentoo.org Cc: mjo@gentoo.org Subject: Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue Message-ID: <20180110215437.GA3156@whubbs1.gaikai.biz> Mail-Followup-To: gentoo-dev@lists.gentoo.org, mjo@gentoo.org References: <20180110000741.GA3995@whubbs1.gaikai.biz> <14e5af26-fdb7-802c-e6d2-7a69c5115e0d@gentoo.org> <20180110180443.GA1085@whubbs1.gaikai.biz> 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-Archives-Salt: 4634d1cf-561f-4cde-a753-da920f2813db X-Archives-Hash: 5f57e7b95598b38c6174f0ebed3a46d2 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 10, 2018 at 03:25:55PM -0500, Michael Orlitzky wrote: > On 01/10/2018 01:04 PM, William Hubbs wrote: > > On Tue, Jan 09, 2018 at 08:19:24PM -0500, Michael Orlitzky wrote: > >=20 > >> Ultimately, it's not safe to chown/chmod/setfacl/whatever in a directo= ry > >> that is not writable only by yourself and root. > >=20 > > Let me try to phrase this another way. > >=20 > > If the directory we are in is not owned by us or root and is group or > > world writable, checkpath should not change the ownership or permissions > > of the file passed to it. >=20 > There are also POSIX ACLs, NFSv4 ACLs, and god-knows-what-else to worry > about, but the above is a good start. >=20 >=20 > >> Here's a very tedious proposal for OpenRC: ... > >> > >> 2. Have newpath throw a warning if it's used in a directory that is > >> writable by someone other than root and the OpenRC user. This will > >> prevent people from creating /foo/bar after /foo has already been > >> created with owner "foo:foo". In other words, service script > >> writers will be encouraged to do things in a safe order. Since > >> we're starting over, this might even be made an error. > >=20 > > I'm not really a fan of creating a new helper unless I have to; I would > > rather modify checkpath's behaviour. > >=20 > > The first stage of that modification would be to release a version that > > outputs error messages, then convert the error messages to hard failures > > in a later release. > >=20 > > Is this reasonable? If we go this route, what should checkpath start > > complaining about? >=20 > /* > Disclaimer: I'm not even sure that this difficult proposal will solve > the problem. Moreover there may be legitimate things going on in some > init scripts that I haven't accounted for. > */ >=20 > The downside to keeping the name "checkpath" is that it makes it > difficult to identify unfixed scripts. If we change the name, then "grep > -rl checkpath" points them out for you; but if checkpath is modified, > you have to install the package and attempt to start/stop/save/reload it > and look for warnings. Good point, this may be a good reason to make a new helper and deprecate checkpath. What I would do is make checkpath throw an error but keep running,. It would have a message, something like: "Checkpath is deprecated, please use newpath instead." What are we saying newpath should do differently than checkpath if I go this route? William --9amGYk9869ThD9tj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTVeuxEZo4uUHOkQAluVBb0MMRlOAUCWlaLlwAKCRBuVBb0MMRl ONrQAJ4xs64YOLW9KvZyJ73fQjU/4aQg7QCeP6qSPG86+WHgbFAzn6GqX4J9qec= =RmV/ -----END PGP SIGNATURE----- --9amGYk9869ThD9tj--