From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev+bounces-83521-garchives=archives.gentoo.org@lists.gentoo.org> 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 A185E138206 for <garchives@archives.gentoo.org>; Wed, 17 Jan 2018 15:21:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2A9B8E09F2; Wed, 17 Jan 2018 15:21:13 +0000 (UTC) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (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 C05FFE09A2 for <gentoo-dev@lists.gentoo.org>; Wed, 17 Jan 2018 15:21:12 +0000 (UTC) Received: by mail-ot0-x230.google.com with SMTP id 44so16228574otk.8 for <gentoo-dev@lists.gentoo.org>; Wed, 17 Jan 2018 07:21:12 -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=4Sq6V0Jeystb3bi66KYO8KIltNEF12BY8imaqpBjXV8=; b=tsackJs4HfhdueNEgjuSAm1rvwyoUYzSxncvu34KslX1H/TMZt4ihJ83iHiJ9sCJ1j Hw6NJ6i9nwUKnOvuQIgA7GQkcJmfo3SgKUPaVClMsj+JBRGjd0hbGKyGldAbVZ6Hf5wP mkfcoB11k51ml8MZy3exlyzTt9fkJ+GaSkD79/s0QuM8ZdmI0SqONyADlHm24MfGZBBw zfbf7cCwS7HS869WgHOMunGj+pR+XMW75qM6rVtAkP84+CvWj7sY3WrVGnQQJwhF6Ri4 y/KY086sAyk7k9awl9GCOEkVBXi2V/pW/cDZxuMOF0bpKsozDNw6DVE97iZeeFA7wjrF RY9g== 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=4Sq6V0Jeystb3bi66KYO8KIltNEF12BY8imaqpBjXV8=; b=PD6l+OZwbIKizKXHmrnr7CzaSBKhrjOIBd2uYgrQrsG2ErukTUQqg54W+BNaOjhxtn Julj29R5L/F7zWMx3QIAQhtXWTtpipyGad8EhTxNyeyBlW7I2fToqnoIfs0kd4BVZMyY vpIQyONVo5Dt1tLBnEsqkozdNnbZJgLGzO4Yanmufj5kNluiwhwKkczAPWe+7pXp+ZwZ gMDmMKxAXzsvbfQ/VzF9/SR8X+GtSgmjsw6JY351TXWPTRbNM8SfihQFvWNLlrhTEzFL mEaswnjPkuIupmqKoFK+LVU14cmOHlrl9XJiW+Op6Mz8NtkFQDjHqVeSiLBNs28cKqyz IPLg== X-Gm-Message-State: AKwxytdfRqOF/9dL07iyysDgXiPECNd2cq705sewwWGHIxXpjgNhaIHn 2LIGRJgX8abgSOtZuQ02zC4zFQ== X-Google-Smtp-Source: ACJfBou6Ejb408hcR22t47knMEJ8RoH+hDr8jZh3oSEJglJd+tnU0Dyj0CeHKCRen2c7Q5H/n78uvQ== X-Received: by 10.157.44.2 with SMTP id f2mr1437501otb.166.1516202471464; Wed, 17 Jan 2018 07:21:11 -0800 (PST) Received: from linux1 (cpe-66-68-34-247.austin.res.rr.com. [66.68.34.247]) by smtp.gmail.com with ESMTPSA id 96sm2187175oth.4.2018.01.17.07.21.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Jan 2018 07:21:09 -0800 (PST) Sender: William Hubbs <w.d.hubbs@gmail.com> Received: (nullmailer pid 9221 invoked by uid 1000); Wed, 17 Jan 2018 15:21:08 -0000 Date: Wed, 17 Jan 2018 09:21:08 -0600 From: William Hubbs <williamh@gentoo.org> To: gentoo-dev@lists.gentoo.org Cc: mjo@gentoo.org Subject: Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue Message-ID: <20180117152108.GA9130@linux1.home> 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> <b41e288a-2ec4-00f7-2b44-f72259ec9831@gentoo.org> <20180110215437.GA3156@whubbs1.gaikai.biz> <731ea2b8-349d-28d4-72a6-3b9555f5bdf7@gentoo.org> Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> 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="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <731ea2b8-349d-28d4-72a6-3b9555f5bdf7@gentoo.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-Archives-Salt: 53296f30-80ba-42ca-9a27-a06e2c4d3280 X-Archives-Hash: 650905eac68f8693405c34a13773b65f --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 13, 2018 at 03:48:10PM -0500, Michael Orlitzky wrote: > On 01/10/2018 04:54 PM, William Hubbs wrote: > >=20 > > What are we saying newpath should do differently than checkpath if I > > go this route? >=20 > I think this covers everything that we've talked about: >=20 > 1. It should refuse to modify existing paths. >=20 > 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. >=20 > 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. =20 For both A and B above I think you mean owner/group/permissions right? > 2. It should have a flag (say, --as=3D<user>[: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.) =20 Checkpath doesn't handle multiple layers of directories currently; you can't do "checkpath -d /run/a/b" without doing "checkpath -d /run/a" first, so I don't see a way to check parents. > 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. William > 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=3Dfoo 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. >=20 > (User variables, or RC_SVCNAME, should still work fine work multiple > instances.) >=20 --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTVeuxEZo4uUHOkQAluVBb0MMRlOAUCWl9p3QAKCRBuVBb0MMRl OKLGAJ9X9j7K5vreL2XWhTZqJOnJsyktPQCgp9QDIwt400DFjtfL9IJtw2D43q0= =m/8A -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT--