Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Feb 2024 19:58:06 +0000
From:      Igor Ostapenko <igor.ostapenko@pm.me>
To:        Brooks Davis <brooks@freebsd.org>
Cc:        "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: Add jail execution environment support to the FreeBSD test suite
Message-ID:  <8OSrqDr54xqBgG5cQG_M2Puk2zSxQUletfKhYUElMb8PNnydh6xTDuPgX4HzICWQO6VbC3q27yAOWstIdJ8iZsfN03gJBf9-l03D_qwYcH8=@pm.me>
In-Reply-To: <ZdjIHZFy8rF-PDxB@spindle.one-eyed-alien.net>
References:  <2bjQNp1msrv-_AqyamMun6kY-SCqbgPm3Q7DqVQHAYlqvFkiE1i85svfIT-QQdUG1cg3cKippyTyv8Z-5nbLu4WaMutgZQ7KT-YYo_5Pbro=@pm.me> <ZdjIHZFy8rF-PDxB@spindle.one-eyed-alien.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, February 23rd, 2024 at 6:30 PM, Brooks Davis <brooks@freebsd.org=
> wrote:
>=20
> > 2 The Idea
> >=20
> > The idea is not new. A test could be running in a jail -- it provides t=
he
> > required isolation with minimum or zero effort from a test.
>=20
>=20
> This generally sounds good. One minor concern I have is how this would
> interact with the ability to run the test suite in a jail. This is
> imperfectly supported today (IIRC ~350 failures on amd64), but it's
> quite userful for testing sweeping userspace-only tests like libsys and
> I'd love to see support expanded and improved (failures fixed or tests
> skipped, poudriere jail support, etc).
>=20

Thanks for your consideration.

As I understand it's a question to the specific tests, which needs revising
and tuning for a non-prison0 case. I saw such issues with existing tests,
frequently it was about jail restrictions. And by design, a root within a j=
ail
cannot alter restrictions of its parent jail, i.e. it's up to the creator o=
f
such jail. In contrast, execenv=3Djail asks Kyua to create a temporary jail=
 for
a test execution, and Kyua can be asked to configure it for the needs of a
test via execenv_jail. But when Kyua itself is running within an existing j=
ail
then expectations of the test suite should be lifted a level above,
especially for usual execenv=3Dhost based tests. Thus, it's out of Kyua's
control to help with that. And this proposal does not change or improve thi=
s
case.

Just a quick idea here. Probably, the test suite could help a creator of su=
ch
jail above Kyua itself with its metadata. For example, a test is not intend=
ed
to be run within a jail and it works fine if Kyua runs within prison0, but =
if
Kyua itself runs in a jail it starts failing due to missing, for instance,
allow.mlock allowence, see jail(8). A test could define
execenv_jail=3D"allow.mlock" metadata without asking for execenv=3Djail, i.=
e. it's
like a hint for a non-prison0 case. And Kyua could aggregate and provide su=
ch
information to ease creation of a jail above the Kyua itself.

On the other end of the spectrum, we could think of a new feature of jail(8=
)
to be able to ask it for a jail with maximum possible set of allowed things=
.
Just thinking out loud.

I hope I've got the topic right.


Best regards, Igor.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8OSrqDr54xqBgG5cQG_M2Puk2zSxQUletfKhYUElMb8PNnydh6xTDuPgX4HzICWQO6VbC3q27yAOWstIdJ8iZsfN03gJBf9-l03D_qwYcH8=>