From nobody Fri Dec 02 01:21:49 2022 X-Original-To: freebsd-current@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 4NNZt11HtDz4jvxC for ; Fri, 2 Dec 2022 01:22:01 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NNZt05Gmdz47DD; Fri, 2 Dec 2022 01:22:00 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x435.google.com with SMTP id x66so3548157pfx.3; Thu, 01 Dec 2022 17:22:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=y1MLVTwCOnMo/Usq1NJtLYtShrZc0jy080rFYGRlj6g=; b=MxQkxcWJvMUOQpHY2Qr4fhaAPcfyZqIjtIqM0Vj79u0PLfz3Jf2F1/i7hMdWSipqcj 6D2IQKre1NUKjYSSLeLoamGyFLAPuHcd/MEwiiqZAXxbYV5UWtj2TwvsPcDM1ZCs5Zb/ jIxobcbxKiLMzebZS0kVd6d5atLJ06LcfDaTJFZaXFxl8mOavcxN8qKDt80p4KxUGgGY prCUBJS1X+yW7qs18udNP4Diu68uot0rx1T2tkHmmVpmsQHE8O/bUksr0oiNvyxdS6Hu 65QeSrEHrC3DkjO23Pdhzd+WQ+ceI0l0JDX4kUd4v3v+qSFkC+YgWGKU8SFrcu6deRzB lt2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=y1MLVTwCOnMo/Usq1NJtLYtShrZc0jy080rFYGRlj6g=; b=cEH7zUsYtv7diZRDxJUITXp2TTjHogOT+p3uXMXxQWWClOaDhH6Ft9mFkF1+ZXCCJv /RXgoNVvQMWODBrqnD10RpR+jb/JcQfGSU0oipX4MkkwJ+1BdVZhnZE36rp9IgEDxO6j iHe+UYOPlKXIOTp1+JuzG/2x2DG9SXnUQxq7eislfBNAd+9xrl++EiotaxVFr3zPYySb xwlxV/n5vRNLOX0kJTLFiGzIExEamw3puYPJLBCsVljwWcRdEVySCDj38RsdqmErZUzN Dl9/0eqvO/UQXMajM7mTuyKcpOCJr/W8qqi+FDzXbNGN03lXofqMFSeEcHV2VdFrxz4e RCaQ== X-Gm-Message-State: ANoB5plv5j7dPFXGs3qd5b0u4e3qC2iJJGrwg+ffxAGq3uiWEVhMkDtG oWxe+jLfYpaBcHSZc18kI3uLhmBbr62nW90RXw== X-Google-Smtp-Source: AA0mqf40MJe7nXlQKJRDZ5ajFgHKiPHszPtTbnDu2VMM+0imPnooFHp+NlQmPMAVw0We34runBgTDVAziTEzU988xfc= X-Received: by 2002:a63:4944:0:b0:44e:466f:4759 with SMTP id y4-20020a634944000000b0044e466f4759mr43517180pgk.194.1669944119534; Thu, 01 Dec 2022 17:21:59 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <82103A1E-9D39-47B0-9520-205583C8B680@lysator.liu.se> <20221201102925.Horde.uAC-87YyIRDDnqJTmvsFwNm@webmail.leidinger.net> <20221201110137.08b2b68c@zeta.dino.sk> In-Reply-To: <20221201110137.08b2b68c@zeta.dino.sk> From: Rick Macklem Date: Thu, 1 Dec 2022 17:21:49 -0800 Message-ID: Subject: Re: RFC: nfsd in a vnet jail To: Milan Obuch Cc: freebsd-current@freebsd.org, Alexander Leidinger , Alan Somers , Peter Eriksson , bz@freebsd.org Content-Type: multipart/alternative; boundary="0000000000000a2a9805eece2a5f" X-Rspamd-Queue-Id: 4NNZt05Gmdz47DD X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000000a2a9805eece2a5f Content-Type: text/plain; charset="UTF-8" On Thu, Dec 1, 2022 at 2:01 AM Milan Obuch wrote: > On Thu, 01 Dec 2022 10:29:25 +0100 > Alexander Leidinger wrote: > > > Quoting Alan Somers (from Tue, 29 Nov 2022 > > 17:28:10 -0700): > > > > > On Tue, Nov 29, 2022 at 5:21 PM Rick Macklem > > > wrote: > > > > >> So, what do others think of enforcing the requirement that each > > >> jail have its own file systems for this? > > > > > > I think that's a totally reasonable requirement. Especially so for > > > ZFS users, who already create a filesystem per jail for other > > > reasons. > > > > While I agree that it is a reasonable requirement, just a note that > > we can not assume that every existing jail resides on its own file > > system. The base system jail infrastructure doesn't check this, and > > the ezjail port doesn't either. The iocage port does it. > > > > My position would be 'recommended, but not forced-to' one. I have > various installations with jails sharing parts of filesystem (like > ports or src tree for development, or even local git repository), or > even running with exactly the same directory as root of number of > jails. Probably not a common scenario for sure, but still useful. > Others indicate they want mountd to run inside the jail. To get that to work, the jail needs to be in a separate file system, since it is the file system(s) mount point(s) that the export information is attached to in the kernel. It comes down to... #1 - Run mountd outside of the jails and encourage use of separate file systems. (Also, since the exports information would be applied to the file system(s) and not the jails, a malicious NFS client could "guess" a file handle and access files outside of the jail. This seems counter to what a jail should provide.) OR #2 - Require separate file systems and run mountd inside the jail(s). I think that allowing both alternatives would be too confusing and it seems that most want mountd to run within the jail(s). As such, unless others prefer #1, I think #2 is the way to go. rick > > Regards, > Milan > --0000000000000a2a9805eece2a5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Dec 1, 2022 at 2:01 AM Milan Obuch &l= t;freebsd-current@dino.sk>= ; wrote:
On Thu,= 01 Dec 2022 10:29:25 +0100
Alexander Leidinger <Alexander@leidinger.net> wrote:

> Quoting Alan Somers <asomers@freebsd.org> (from Tue, 29 Nov 2022=C2=A0
> 17:28:10 -0700):
>
> > On Tue, Nov 29, 2022 at 5:21 PM Rick Macklem
> > <r= ick.macklem@gmail.com> wrote:=C2=A0
>
> >> So, what do others think of enforcing the requirement that ea= ch
> >> jail have its own file systems for this?=C2=A0
> >
> > I think that's a totally reasonable requirement.=C2=A0 Especi= ally so for
> > ZFS users, who already create a filesystem per jail for other
> > reasons.=C2=A0
>
> While I agree that it is a reasonable requirement, just a note that > we can not assume that every existing jail resides on its own file=C2= =A0
> system. The base system jail infrastructure doesn't check this, an= d=C2=A0
> the ezjail port doesn't either. The iocage port does it.
>

My position would be 'recommended, but not forced-to' one. I have various installations with jails sharing parts of filesystem (like
ports or src tree for development, or even local git repository), or
even running with exactly the same directory as root of number of
jails. Probably not a common scenario for sure, but still useful.
O= thers indicate they want mountd to run inside the jail.
To get that to = work, the jail needs to be in a separate file
system, since it is the = file system(s) mount point(s) that the
export information is attached t= o in the kernel.

It comes down to...
#1 - Run mountd outsi= de of the jails and encourage use of separate
=C2=A0 file systems.
=C2=A0 (Also, since the exports information would be applied to the file
=C2=A0 =C2=A0system(s) and not the jails, a malicious NFS client could
=C2=A0 =C2=A0"guess" a file handle and access files outside of= the jail.
=C2=A0 =C2=A0This seems counter to what a jail should provid= e.)
OR
#2 - Require separate file systems and run mountd inside the= jail(s).

I think that allowing both alternatives would be too= confusing
and it seems that most want mountd to run within the jail(s)= .
As such, unless others prefer #1, I think #2 is the way to go.=
rick=C2=A0

Regards,
Milan
--0000000000000a2a9805eece2a5f--