From nobody Mon Feb 26 19:58:06 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TkBJ33B8pz5C4Jx for ; Mon, 26 Feb 2024 19:58:27 +0000 (UTC) (envelope-from igor.ostapenko@pm.me) Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TkBJ22k9Tz43hv; Mon, 26 Feb 2024 19:58:26 +0000 (UTC) (envelope-from igor.ostapenko@pm.me) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=pm.me header.s=protonmail3 header.b=RCXYAyEz; dmarc=pass (policy=quarantine) header.from=pm.me; spf=pass (mx1.freebsd.org: domain of igor.ostapenko@pm.me designates 185.70.40.134 as permitted sender) smtp.mailfrom=igor.ostapenko@pm.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1708977503; x=1709236703; bh=ZMYs8cKCFobhvycmGVMGpq0/jo5s1BT08h1r5G0NFHs=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=RCXYAyEzQ2cf0aprCL7ulJwb9P5ADJ6Z0DuFVJsu2s4eDpjNfhvPf9E5pqzRIFoCP sBVgFqhgX89VE3Ad6XzPHqV2czWJTK48P8bIa6VgnrfByIj8OywDW7SpZ80bES4mro 4rQlDaXLGBsD7o01mBgNvIpuiYrlfxJBUPB1+MCERz3lmNN399y7mFTxBNFY1RT7w5 8hhpOSeOe+nDYmE5T+v5hibiFVrO8wVuumV9nX+qS0gub6SZtL4MMHSC4KUAhtN8bR ynYM9bj2ao2rILK3KOAvxSxII+qumdtBfLdsAosI6lpqEGplQqyMoLNNNmn1ANni4L iT1dilYcqQHEQ== Date: Mon, 26 Feb 2024 19:58:06 +0000 To: Brooks Davis From: Igor Ostapenko Cc: "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: References: <2bjQNp1msrv-_AqyamMun6kY-SCqbgPm3Q7DqVQHAYlqvFkiE1i85svfIT-QQdUG1cg3cKippyTyv8Z-5nbLu4WaMutgZQ7KT-YYo_5Pbro=@pm.me> Feedback-ID: 8300135:user:proton List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[pm.me,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; R_DKIM_ALLOW(-0.20)[pm.me:s=protonmail3]; RWL_MAILSPIKE_VERYGOOD(-0.20)[185.70.40.134:from]; MIME_GOOD(-0.10)[text/plain]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[pm.me:+] X-Rspamd-Queue-Id: 4TkBJ22k9Tz43hv On Friday, February 23rd, 2024 at 6:30 PM, Brooks Davis 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.