From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-83549-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 0C236138206
for <garchives@archives.gentoo.org>; Sat, 20 Jan 2018 01:14:17 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 74319E0AA4;
Sat, 20 Jan 2018 01:14:11 +0000 (UTC)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f])
(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 0E9B0E096A
for <gentoo-dev@lists.gentoo.org>; Sat, 20 Jan 2018 01:14:10 +0000 (UTC)
Received: by mail-oi0-x22f.google.com with SMTP id j129so2358605oib.12
for <gentoo-dev@lists.gentoo.org>; Fri, 19 Jan 2018 17:14:10 -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=yEG1rTloXrgM0nFdXNi1uLks6dZhmtAHS9AXHSAayD8=;
b=mC1C394PgloS4PygkO9EBxyKvqwEXY2XD2mpWS7pKWvKM/J3W+KxGEytPOT/FXUTfN
gFRGS/JG8az2lFFbIbUtwngd2f9pr3BasknBQMsZodT46n7gVbimNZCv1FEA+UWs6HiG
MplQsNfJaP4TBZrJmOUU3noUOfcxeaCuudPEoQ0B5Fs8ubC6cH3leWwYtDTpk2wfHXcn
DAGlF6lzZNkbEgN1XsSDNWb/o2G/tjcEyfi6cIj2dKbufTCUaMsw5KO38JQcUf/W1IRX
TE1qnEUFRC+Zoi2FjM7k4hVlw+VV4tqQJRQtwpIqpLGEkh4h/Hq0tMaxy233PdvkriMx
Qr7A==
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=yEG1rTloXrgM0nFdXNi1uLks6dZhmtAHS9AXHSAayD8=;
b=gYrslirEC3/5pV+Fxe43pKeSpX/LY0Uy+HmAJBk99Eko8NCe94j4bw2vGHWWhZxPFq
crPP0za21v3pvmIkZgN1lTGYoVdIaEcYicGiA7DRTaGVrNH87m4JCNjb9sqEQzbyOgjX
BNUF4h4ucfHI2uzhrqE1gRpikq539aUNWc0ShPz+47obEl5pxSlVztHd4oOiXWchDXRQ
AxDhBi28FzZ5WankuDZPlvcU+bBG9UM12qygUQ0NVmtusirV5hOvuIw7TlC7Bvoxn1eH
qFITuIMAb7G4kbvlXubvUk1AK12D4ZH9KeU81jpqoyyyiTIY2O3JT2bgs4gC/eMqIdqN
9T3g==
X-Gm-Message-State: AKwxytfMr0HCe9UfK9FrcGFVwJF/auarqN2XJwI4TsM4IEvmnqHJtq5p
ykWX9IHW5mo0hxkyfrzM+SoUhA==
X-Google-Smtp-Source: AH8x224huwjilSqmKMV6X7jE3/Gromv7EdeE49BnldCA6RgdhX3Nb/JeRa2UKBvLhEFG34dmTDnwSg==
X-Received: by 10.202.188.2 with SMTP id m2mr242291oif.180.1516410849795;
Fri, 19 Jan 2018 17:14:09 -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 o48sm1711802otb.27.2018.01.19.17.14.07
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Fri, 19 Jan 2018 17:14:07 -0800 (PST)
Sender: William Hubbs <w.d.hubbs@gmail.com>
Received: (nullmailer pid 25653 invoked by uid 1000);
Sat, 20 Jan 2018 01:14:07 -0000
Date: Fri, 19 Jan 2018 19:14:06 -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: <20180120011406.GA25389@linux1.home>
Mail-Followup-To: gentoo-dev@lists.gentoo.org, mjo@gentoo.org
References: <20180110180443.GA1085@whubbs1.gaikai.biz>
<b41e288a-2ec4-00f7-2b44-f72259ec9831@gentoo.org>
<20180110215437.GA3156@whubbs1.gaikai.biz>
<731ea2b8-349d-28d4-72a6-3b9555f5bdf7@gentoo.org>
<20180117152108.GA9130@linux1.home>
<04627c1a-64b7-9370-41d8-ddc79213de5b@gentoo.org>
<20180117171416.GA18843@whubbs1.gaikai.biz>
<03558fda-26b3-2e3a-ad42-c94848f49955@gentoo.org>
<20180120001648.GA24415@linux1.home>
<464a4683-8613-1b79-35a1-9e4d53ae36e6@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="vkogqOf2sHV7VnPd"
Content-Disposition: inline
In-Reply-To: <464a4683-8613-1b79-35a1-9e4d53ae36e6@gentoo.org>
User-Agent: Mutt/1.7.2 (2016-11-26)
X-Archives-Salt: f48a831c-23de-4160-b2b9-fe44b3cec009
X-Archives-Hash: 17dfc6154eb4add4d0530c1fcc34dbbb
--vkogqOf2sHV7VnPd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jan 19, 2018 at 07:53:06PM -0500, Michael Orlitzky wrote:
> On 01/19/2018 07:16 PM, William Hubbs wrote:
> >=20
> > It looks like we can't use your --as suggestion if we want to be
> > able to create paths in /var/lib and /var/spool that are owned by
> > non-privileged users because of the permissions on those paths. It is
> > possible that service scripts are doing this.
> >=20
>=20
> Why not? Since /var/lib is root:root and mode 755, we can create
> /var/lib/foo while running --as=3Droot (the default). Then afterwards,
> anything beneath /var/lib/foo would need to be created "--as" the owner
> of that directory.
That would create an extra level of indirection for some things though,
what if /var/lib/foo needs to be owned by foo? I have /var/lib/dhcp
which is owned by dhcp:dhcp. You can't creat that with --as=3Ddhcp.
>=20
> /var/lib or /var/spool should be no different than /run in that regard.
>=20
> (Although, the ebuild should be responsible for /var/lib and /var/spool)
>=20
>=20
> > Is it worth changing the algorithm to do this instead:
> >=20
> > 0. test for existance by opening a read-only file descriptor to this
> > file.
> > 1. Creating the file/directory/fifo.
> > a. If it doesn't exist, create it -- note that I'm not setting
> > permissions with the create call.
> > b. Open a read-only file descriptor that attaches to the newly created
> > file.
> > 2. Setting Permissions.
> > a. Fix the permissions of the file if necessary.
> > 3. setting ownership
> > a. Set the ownership if it doesn't match the specified ownership.
>=20
> Is this for checkpath? Steps (a) and (b) would need to happen at the
> same time. Is there a way to determine if a file descriptor is for a
> hard link? There are likely some small ways that we could still improve
> checkpath, but the main issue I'm trying to solve by jumping through all
> these hoops is the hard link race condition.
You mean steps 1 (a) and (b)? They would happen in the sequence shown.
The only call that gives you a file descriptor is open() which is not
used to create a directory or a fifo.
The link status is available via fstat() or stat().
An example of checking it is in line 146 of checkpath.c. We refuse to
chmod a file that has more than one hard link to it.
>=20
>=20
> >> Risk #2: Instead consider a four-component path /run/foo/bar/baz. If y=
ou
> >> start creating those directories with owner "foo", then when you get to
> >> creating "baz", it's possible that "bar" has been replaced by a symlink
> >> somewhere else.
> > =20
> > It is possible, sure, but the question I would ask is, could this also
> > be a legit situation where a user would want /run/foo/bar to be a
> > symlink to some other location? If it is, there's no way to tell the
> > difference.
>=20
> The init script author can use the real path instead of the one
> involving the symlink if he needs to. So maybe he wants /run/foo/bar to
> be a symlink to /herp/derp, but then instead of doing
>=20
> newpath /run/foo/bar/baz
>=20
> he could do
>=20
> newpath /herp/derp/baz
>=20
> and then there are no symlinks involved.
Let me think about this... :-)
William
--vkogqOf2sHV7VnPd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iF0EARECAB0WIQTVeuxEZo4uUHOkQAluVBb0MMRlOAUCWmKX0gAKCRBuVBb0MMRl
ONSqAKCw384J9gPIf9eb8pL5CgNaJ61xcACgs4wutYdnzmJpMBSLJXNQ26SL+3s=
=FMjg
-----END PGP SIGNATURE-----
--vkogqOf2sHV7VnPd--