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