From nobody Sun Nov 27 18:18:51 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 4NKxgm29K2z4jQlp for ; Sun, 27 Nov 2022 18:19:00 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (gritton.org [162.220.209.3]) (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 (2048 bits) client-digest SHA256) (Client CN "gritton.org", Issuer "gritton.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NKxgl1JQ6z495L; Sun, 27 Nov 2022 18:18:59 +0000 (UTC) (envelope-from jamie@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 162.220.209.3 is neither permitted nor denied by domain of jamie@freebsd.org) smtp.mailfrom=jamie@freebsd.org; dmarc=none Received: from gritton.org ([127.0.0.3]) (authenticated bits=0) by gritton.org (8.16.1/8.16.1) with ESMTPA id 2ARIIpcM048840; Sun, 27 Nov 2022 10:18:51 -0800 (PST) (envelope-from jamie@freebsd.org) 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 Date: Sun, 27 Nov 2022 10:18:51 -0800 From: James Gritton To: freebsd-current@freebsd.org Cc: Rick Macklem , bz@freebsd.org Subject: Re: RFC: nfsd in a vnet jail In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.11 Message-ID: X-Sender: jamie@freebsd.org Content-Type: multipart/alternative; boundary="=_d129efa9d504031e718030baf8bed06e" X-Spamd-Result: default: False [-3.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; ASN(0.00)[asn:30247, ipnet:162.220.208.0/22, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[jamie]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NKxgl1JQ6z495L X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --=_d129efa9d504031e718030baf8bed06e Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2022-11-25 15:17, Rick Macklem wrote: > Hi, > > bz@ has encouraged me to fiddle with the nfsd > so that it works in a vnet jail. > I have now basically done so, specifically for > NFSv4, since NFSv3 presents various issues. > > What I have not yet done is put global variables > in the vnet. This needs to be done so that the nfsd > can be run in multiple jail instances and/or in and > outside of a jail. > The problem is that there are 100s of global variables. > > I can see two approaches: > 1 - Move them all into the vnet jail. This would imply > that all the sysctls need to somehow be changed, > which would seem to be a POLA violation. > It also implies a lot of stuff in the vnet. > 2 - Just move the global variables that will always > differ from one nfsd to another (this would make > the sysctls global and apply to all nfsds). > This will keep the number of globals in the vnet > smaller. > > I am currently leaning towards #2, put what do others > think? > > rick > ps: Personally, I don't know what use there is of > running the nfsd inside a vnet jail, but bz@ has > some use case. I would prefer closer to #2, unless you want to support only one jail running nfsd (which is admittedly one of the more likely scenarios). I imagine it's a case-by-case judgement call, as to whether a particular knob should be global or per-jail. - Jamie --=_d129efa9d504031e718030baf8bed06e Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On 2022-11-25 15:17, Rick Macklem wrote:

Hi,
 
bz@ has en= couraged me to fiddle with the nfsd
so that it= works in a vnet jail.
I have now= basically done so, specifically for
NFSv4, sin= ce NFSv3 presents various issues.
 
What I hav= e not yet done is put global variables
in the vne= t. This needs to be done so that the nfsd
can be run= in multiple jail instances and/or in and
outside of= a jail.
The proble= m is that there are 100s of global variables.
 
I can see = two approaches:
1 - Move t= hem all into the vnet jail. This would imply
  &nb= sp; that all the sysctls need to somehow be changed,
  &nb= sp; which would seem to be a POLA violation.
  &nb= sp; It also implies a lot of stuff in the vnet.
2 - Just m= ove the global variables that will always
  &nb= sp; differ from one nfsd to another (this would make
  &nb= sp; the sysctls global and apply to all nfsds).
  &nb= sp; This will keep the number of globals in the vnet
  &nb= sp; smaller.
 
I am curre= ntly leaning towards #2, put what do others
think?
 
rick
ps: Person= ally, I don't know what use there is of
  &nb= sp; running the nfsd inside a vnet jail, but bz@ has
  &nb= sp; some use case.
 
I would pr= efer closer to #2, unless you want to support only one jail running nfsd (w= hich is admittedly one of the more likely scenarios).  I imagine it's = a case-by-case judgement call, as to whether a particular knob should be gl= obal or per-jail.
 
- Jamie --=_d129efa9d504031e718030baf8bed06e--