From nobody Sun Nov 27 19:13:31 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 4NKytp4tbxz4jWyT for ; Sun, 27 Nov 2022 19:13:38 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NKytp4L9sz4GQw; Sun, 27 Nov 2022 19:13:38 +0000 (UTC) (envelope-from bz@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669576418; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LAN5rLUs4XaFAMPaW9ldAnSiG72q7MMG/lvqP18GXjk=; b=e8N2BUSJ+GvLVWFNROhzUt04mF5MtnkCCOrY+ySmBh+CoPUAaHNOeZToYrFC+Li4H6MpNH 2I0jTT6k7VnyWAgEdH0/2N/lIwh8MBXOQsytPiBUuzbRA8XagGkS1o9ZubWQhBE1PD+OJz 8ikYkpnHiCjtKLOC+y/Sq+rP4d8RRKTk5Tm/PYuEJup3KIVDv+1lib7dh6O0LuF7rGLtxy rTvuoE0JWx/87vWIheLmiR50fKSs5VXYoQNUBWy2JUBMtnDzGCA48TlWRzlCs68swFtZ2n ghIY0d591VZyYjHULwRSm3N473cuQtESvI34DrY6ATaMV5o/Crauj2DpUydIjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669576418; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LAN5rLUs4XaFAMPaW9ldAnSiG72q7MMG/lvqP18GXjk=; b=isoPFsdPJITvMxNXbiMQHjBRGxcpC+lvxqtJatjg5jtG1V+PLsnLzazrvPnFfWGl1LxAIL uBJ2cXyINVUAqiS0Lxhd5NC7azp47Ay0ZCbmhB2Z4btdEwolU//81ZLRLXr5z62eurlxHS wsGPWtVPNh/NjsXxeAwNIHsmFFTOCt5XLGjM8tFVqrQvKBhw0O9mQ8HkCIGUKExDTV0HaT 41eKTHfGi/S2W4hNbyw1loCNl/0WqgblWkiETuKttcafG+PARrDn+9iilFGlAypFvGcUEz buNtCur5j5kfzKV47WlUdqds1GBykheSOgqU5z4Hhq9aW86ynGdM0SmKjK3AZQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669576418; a=rsa-sha256; cv=none; b=Lzfk2K6X6j86uSSzILo9tJLH84ezN3j/ycoVkNuPQKD3kvbATlrnOQ3ao/ukHgA6OQrIH2 NW0exe3/uHUb1vgwtTmi94tFI31/OVpo8OVHrhUKHZJwMq96/E18vS2nNIO9l6ZPabZda3 MLlfkiw9ZslcimW0DEq006E20xtmO1i83IOoBquGM4K6EdrUtLyL/jfrolbepspZS4UT/2 FKkRjTYSVGNfTxn5LaiXhJ8BJqhkWTnk9A8nzLuUy0sWftIZTtM966Jfe3IazW3Z9nwCMj ozw3/CHhGoSTR+XCESLuQjihGmYmHd6VpXka7Iu2RUCaTM42kNMNVM7bB0UjAQ== Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NKytp1mYfzlqN; Sun, 27 Nov 2022 19:13:38 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 713CC8D4A17E; Sun, 27 Nov 2022 19:13:35 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A1FBE5C3A833; Sun, 27 Nov 2022 19:13:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id 5jesvg1o_ZVo; Sun, 27 Nov 2022 19:13:32 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id A388E5C3A830; Sun, 27 Nov 2022 19:13:32 +0000 (UTC) Date: Sun, 27 Nov 2022 19:13:31 +0000 (UTC) From: "Bjoern A. Zeeb" To: James Gritton cc: freebsd-current@freebsd.org, Rick Macklem Subject: Re: RFC: nfsd in a vnet jail In-Reply-To: Message-ID: <5244s3o-p9q6-qp97-2623-onso786os643@serrofq.bet> References: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 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 Content-Type: text/plain; charset=US-ASCII; format=flowed X-ThisMailContainsUnwantedMimeParts: N On Sun, 27 Nov 2022, James Gritton wrote: > 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. Not a POLA. The sysctl (names) don't change. Just the values are duplicated per-jail. >> 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. I think the call is: everything that if changed in a vnet jail that could cause the entire system to be DoSed by changing the setting in the jail defintitvely stays global. Everything which needs to be writeable on a per-instance base probably needs to be virtualised. My main concern with virtualising the variables will be early boot and and NFSROOT szenarios that will need access to them early on before the virtual network stacks are properly initialized; I can help sorting that out if my concerns become real. Most probably was sorted before for NFSROOT with the IP stack so it's likely an okay job now. Also given I have once done it before for another subsystem; we could think of a V_FS bit (and I write it that way to not confuse it with VFS). Now NFS sits somewhere between FS and NET so I am not surt where it should belong should we ponder that route as yet another option (and if we think that VNETs will be way too big one day? -- there's probably a lot other fish still to fry though some of that has been burnt in the past already). I think I have another email or two on the subject (possibly privately); sorry Rick that I haven't gotten to them more timely. I'll have a look later tonight. /bz -- Bjoern A. Zeeb r15:7