From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4A7F7157480 for ; Mon, 6 May 2024 17:34:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715016869; cv=none; b=YYKCwSkp60RbnYSx6Fu8CHvnTMZCPNbihN/q2UvMVsw4s/2aEv04l0MkNatY08kXGl4vXHOZoLjzMjeSFc4Xapg7Tdlx+419vA2UvlHzeWEobZoU6l3wQtbA2qjTKsw0d4VTldO4xltrJqthB3XvfeCxeipmR3Tx9QF6kKlHXSg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715016869; c=relaxed/simple; bh=N/Cl1VgIzjxIHfpr4FV+iTL6dI3E1P0L0sOAp1/Q/tY=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZQYLjWiNbQtSdDlxmo7pIgdNiMkndcoU22X+2HZwmG9vliZlk9dvTKieEApLZ/YMZeijn/5XoDDWv671zVylL779CalTsDm/g3KKkXrAWDr+oDTo/6lnmWKluBovFq16Kx5xAvi70jlGYlvS6pgaK6ty/ACq6KEbshIvTda+IoU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Q+wdtp9m; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Q+wdtp9m" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F20E8C4DDE9 for ; Mon, 6 May 2024 17:34:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1715016869; bh=N/Cl1VgIzjxIHfpr4FV+iTL6dI3E1P0L0sOAp1/Q/tY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Q+wdtp9mG3+BycV8DzlmzxfA0XcO2ZwNevcJafgO1Pn7Ea5b3AZHWkDpdJ7UQcsre NF9qOYqYy++fw9L6ol4e6nMvlfMbWOFx4bEIVAeAiyx5JSYvaiaEKT3pscSUCUjaRn 5gucDjbsHOl3ffEJuxMhcoE5THO++eGdMxMNDQtFnIf2ivSgl4oeP7iUGnEw7x406N e0hT2qSjV46uG35kxbe95qhz6Vbyk3C8VA/HjeJbSPAPpmwpNGyGjuEBI+4XYjshoc LC4Hh9DziIjRT0sZiFZ5C3q1ByWgeNE5X5SFnNwvlJnpeCR5x9kgmd3RPxcBAbQR31 z/rPQiTJ359sA== Received: by mail-oa1-f46.google.com with SMTP id 586e51a60fabf-23db0b5dd28so1561730fac.2 for ; Mon, 06 May 2024 10:34:28 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXUR9wSpWva2Vg1gLSuXj/QGNnFB5U0ByiCOzVWEbNcLhXfeWMLziMV9rsef5sBpLcf9zv/CoNMC0Xwz6lNvF5yksMRPm4Acwpj X-Gm-Message-State: AOJu0YxmfXqzPEJ+/771LdtG+NBhdk5EM3NncUVtKoG8eRcGqdKbCigb ZsaaU7MisQEyzI8oLOvfa320huAK+hEACc49uX9K/TLI9C72L/92x12eu6AFI9HO0GVp6KuP0x0 +r4eeeGYc0Rz8uLX42jSc9jUKIeqofZkSHEcn X-Google-Smtp-Source: AGHT+IGeEkyd9/ecXTKRvSMEhABoiDcgycle+ebD63V9wpAW6Icf2bUBHPTL3WKDxwW/DA9QnCw2BpuJ/GbXWPX4plE= X-Received: by 2002:a05:6870:1b0a:b0:23b:c31f:ee76 with SMTP id hl10-20020a0568701b0a00b0023bc31fee76mr12950767oab.52.1715016868026; Mon, 06 May 2024 10:34:28 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-api@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240426133310.1159976-1-stsp2@yandex.ru> <20240428.171236-tangy.giblet.idle.helpline-y9LqufL7EAAV@cyphar.com> In-Reply-To: From: Andy Lutomirski Date: Mon, 6 May 2024 10:34:16 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 0/3] implement OA2_CRED_INHERIT flag for openat2() To: Aleksa Sarai Cc: Stas Sergeev , "Serge E. Hallyn" , linux-kernel@vger.kernel.org, Stefan Metzmacher , Eric Biederman , Alexander Viro , Andy Lutomirski , Christian Brauner , Jan Kara , Jeff Layton , Chuck Lever , Alexander Aring , David Laight , linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, Paolo Bonzini , =?UTF-8?Q?Christian_G=C3=B6ttsche?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 6, 2024 at 10:29=E2=80=AFAM Andy Lutomirski wrote: > > Replying to a couple emails at once... > > On Mon, May 6, 2024 at 12:14=E2=80=AFAM Aleksa Sarai = wrote: > > I also find it somewhat amusing that this proposal is to basically give > > up on multi-user permissions for this one directory tree because it's > > too annoying to deal with. In that case, isn't chmod 777 a simpler > > solution? (I'm being a bit flippant, of course there is a difference, > > but the net result is that all users in the container would have the > > same permissions with all of the fun issues that implies.) > > > > In short, AFAICS idmapped mounts pretty much solve this problem (minus > > the ability to collapse users, which I suspect is not a good idea in > > general)? > > > > With my kernel hat on, maybe I agree. But with my *user* hat on, I > think I pretty strongly disagree. Look, idmapis lousy for > unprivileged use: > > $ install -m 0700 -d test_directory > $ echo 'hi there' >test_directory/file > $ podman run -it --rm > --mount=3Dtype=3Dbind,src=3Dtest_directory,dst=3D/tmp,idmap [debian-slim] > # cat /tmp/file > hi there > > <-- Hey, look, this kind of works! > > # setpriv --reuid=3D1 ls /tmp > ls: cannot open directory '/tmp': Permission denied > > <-- Gee, thanks, Linux! I should add: this is lousy even for privileged use. On a normal non-containerized system: $ ls -ld /var/lib/mysql drwxr-xr-x. 3 mysql mysql 4096 Sep 20 2023 /var/lib/mysql This makes perfect sense. But if I want to run mysql in a container in a sane way, my only real choice is either to trust the container manager quite strongly (so it only maps this directory into the correct container) or, if I want to separate out management of this container into its own UID (which is a good practice), then I'm forced to do some kind of fragile hack like making a directory only accessible to the correct UID and then creating a 0777 directory inside it and bind-mounting *that*.