Received-SPF: pass (google.com: domain of linux-kernel+bounces-87058-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240222160915.315255-1-aleksandr.mikhalitsyn@canonical.com>
 <20240222160915.315255-3-aleksandr.mikhalitsyn@canonical.com>
 <Zdd8MAJJD3M11yeR@tycho.pizza> <20240223-kantholz-knallen-558beba46c62@brauner>
 <ZdoEavHorDs3IlF5@tycho.pizza> <20240226-gestrafft-pastinaken-94ff0e993a51@brauner>
 <Zdyumw6OfWBqQMTj@tycho.pizza> <CAEivzxcVbEZtr+wPL1p+dM4r8+vFNnPoF+E-QvG_nLNHGDYJQg@mail.gmail.com>
In-Reply-To: <CAEivzxcVbEZtr+wPL1p+dM4r8+vFNnPoF+E-QvG_nLNHGDYJQg@mail.gmail.com>
From: Aleksandr Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Date: Thu, 29 Feb 2024 17:11:34 +0100
Message-ID: <CAEivzxfOff_PrEfCmh_pJM4hm0PGVQjna4ucQi9_zKsaJPw42g@mail.gmail.com>
Subject: Re: [PATCH v1 2/2] tests/pid_namespace: add pid_max tests
To: Tycho Andersen <tycho@tycho.pizza>
Cc: Christian Brauner <brauner@kernel.org>, stgraber@stgraber.org, cyphar@cyphar.com, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 29, 2024 at 4:14=E2=80=AFPM Aleksandr Mikhalitsyn
<aleksandr.mikhalitsyn@canonical.com> wrote:
>
> On Mon, Feb 26, 2024 at 4:30=E2=80=AFPM Tycho Andersen <tycho@tycho.pizza=
> wrote:
> >
> > On Mon, Feb 26, 2024 at 09:57:47AM +0100, Christian Brauner wrote:
> > > > > > A small quibble, but I wonder about the semantics here. "You ca=
n write
> > > > > > whatever you want to this file, but we'll ignore it sometimes" =
seems
> > > > > > weird to me. What if someone (CRIU) wants to spawn a pid number=
ed 450
> > > > > > in this case? I suppose they read pid_max first, they'll be abl=
e to
> > > > > > tell it's impossible and can exit(1), but returning E2BIG from =
write()
> > > > > > might be more useful.
> > > > >
> > > > > That's a good idea. But it's a bit tricky. The straightforward th=
ing is
> > > > > to walk upwards through all ancestor pid namespaces and use the l=
owest
> > > > > pid_max value as the upper bound for the current pid namespace. T=
his
> > > > > will guarantee that you get an error when you try to write a valu=
e that
> > > > > you would't be able to create. The same logic should probably app=
ly to
> > > > > ns_last_pid as well.
> > > > >
> > > > > However, that still leaves cases where the current pid namespace =
writes
> > > > > a pid_max limit that is allowed (IOW, all ancestor pid namespaces=
 are
> > > > > above that limit.). But then immediately afterwards an ancestor p=
id
> > > > > namespace lowers the pid_max limit. So you can always end up in a
> > > > > scenario like this.
> > > >
> > > > I wonder if we can push edits down too? Or an render .effective fil=
e, like
> > >
> > > I don't think that works in the current design? The pid_max value is =
per
> > > struct pid_namespace. And while there is a 1:1 relationship between a
> > > child pid namespace to all of its ancestor pid namespaces there's a 1=
 to
> > > many relationship between a pid namespace and it's child pid namespac=
es.
> > > IOW, if you change pid_max in pidns_level_1 then you'd have to go
> > > through each of the child pid namespaces on pidns_level_2 which could=
 be
> > > thousands. So you could only do this lazily. IOW, compare and possibl=
y
> > > update the pid_max value of the child pid namespace everytime it's re=
ad
> > > or written. Maybe that .effective is the way to go; not sure right no=
w.
>
> Hi Tycho!
>
> >
> > I wonder then, does it make sense to implement this as a cgroup thing
> > instead, which is used to doing this kind of traversal?
> >
> > Or I suppose not, since the idea is to get legacy software that's
> > writing to pid_max to work?
>
> Yes, this is mostly for legacy software that expects host-like
> behavior in the container.
> I know that folks who work on running Android inside the container are
> very-very interested in this.

My colleague, Simon Fels, shared with me:
https://android.googlesource.com/platform/bionic.git/+/refs/heads/main/docs=
/32-bit-abi.md#is-too-small-for-large-pids

>
> Kind regards,
> Alex
>
> >
> > Tycho