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--