From owner-svn-src-all@freebsd.org Mon Dec 17 16:01:56 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B0A313444FF for ; Mon, 17 Dec 2018 16:01:56 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8424674EB9 for ; Mon, 17 Dec 2018 16:01:55 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f194.google.com with SMTP id s5-v6so11431227ljd.12 for ; Mon, 17 Dec 2018 08:01:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc:content-transfer-encoding; bh=ft9QIizwhaHTH76rfHMzEMYXBU64Xu5+N7TDF/IN9Rc=; b=tkeoi4KXFzHzSkJ9ayU2piCTPGbZeX4H8wTPLadoIsK4oUi1+zT2gzlgFUjBvd4yEd Hhzer24df5e8PxLt1+xZTZt/yKKxWM1dVBskggb9IET+/XnJjvou9TMCnOmuQYvg0Ul0 ae/za/bfBhUtuTmtvAAEg24iy6c4WRtrTZ90p0AjrsoUUx46yjc1/LWz+uPSsLJkhxX3 JddPKvwAw+6ON2hODXfQi36YMkDNC0GfRuCRc4r/lU3Lq+FiLoMpWRlIr6Z5wPmAUCLd JcI6Hmk1g2GOXYWDRLpDPRQ9zq3c2dFjpx8ikROUy/5cdigeIdk0faWbKDRTDNbIMQlc 4JsQ== X-Gm-Message-State: AA+aEWZjnvrDZcYfehxH3DfOp7/LXJzUZTSWWBjsMhOSm/djCXq5g5B5 CLNN8oSZv4vc+tBPIklLLnCzl0m2BcIgUFMTO/c= X-Received: by 2002:a2e:9e95:: with SMTP id f21-v6mt8865584ljk.128.1545062506787; Mon, 17 Dec 2018 08:01:46 -0800 (PST) MIME-Version: 1.0 References: <201805042054.w44KsRtc038808@repo.freebsd.org> In-Reply-To: From: Alan Somers Date: Mon, 17 Dec 2018 09:01:34 -0700 Message-ID: Subject: Re: svn commit: r333263 - in head: lib/libjail sys/cddl/contrib/opensolaris/uts/common/fs/zfs sys/compat/linprocfs sys/compat/linsysfs sys/fs/devfs sys/fs/fdescfs sys/fs/nullfs sys/fs/procfs sys/fs/pse... Cc: jamie@freebsd.org, src-committers , svn-src-all , svn-src-head , Ross Williams Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 8424674EB9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.194 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-1.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.90)[-0.897,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-0.90)[-0.895,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-all@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_FIVE(0.00)[5]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.89)[-0.889,0]; RCVD_IN_DNSWL_NONE(0.00)[194.208.85.209.list.dnswl.org : 127.0.5.0]; MISSING_TO(2.00)[]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[194.208.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; IP_SCORE(-1.01)[ipnet: 209.85.128.0/17(-3.60), asn: 15169(-1.36), country: US(-0.08)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 16:01:56 -0000 On Mon, Nov 19, 2018 at 10:26 AM Alan Somers wrote: > > On Fri, Nov 16, 2018 at 7:16 PM James Gritton wrote: >> >> On 2018-11-16 16:30, Alan Somers wrote: >> >> On Fri, Nov 16, 2018 at 2:28 PM James Gritton wrote: >>> >>> On 2018-11-16 10:34, Alan Somers wrote: >>> >>> On Fri, May 4, 2018 at 2:54 PM Jamie Gritton wrote: >>>> >>>> Author: jamie >>>> Date: Fri May 4 20:54:27 2018 >>>> New Revision: 333263 >>>> URL: https://svnweb.freebsd.org/changeset/base/333263 >>>> >>>> Log: >>>> Make it easier for filesystems to count themselves as jail-enabled, >>>> by doing most of the work in a new function prison_add_vfs in kern_j= ail.c >>>> Now a jail-enabled filesystem need only mark itself with VFCF_JAIL, = and >>>> the rest is taken care of. This includes adding a jail parameter li= ke >>>> allow.mount.foofs, and a sysctl like security.jail.mount_foofs_allow= ed. >>>> Both of these used to be a static list of known filesystems, with >>>> predefined permission bits. >>>> >>>> Reviewed by: kib >>>> Differential Revision: D14681 >>>> >>>> Modified: >>>> head/lib/libjail/jail.c >>>> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c >>>> head/sys/compat/linprocfs/linprocfs.c >>>> head/sys/compat/linsysfs/linsysfs.c >>>> head/sys/fs/devfs/devfs_vfsops.c >>>> head/sys/fs/fdescfs/fdesc_vfsops.c >>>> head/sys/fs/nullfs/null_vfsops.c >>>> head/sys/fs/procfs/procfs.c >>>> head/sys/fs/pseudofs/pseudofs.h >>>> head/sys/fs/tmpfs/tmpfs_vfsops.c >>>> head/sys/kern/kern_jail.c >>>> head/sys/kern/vfs_init.c >>>> head/sys/kern/vfs_mount.c >>>> head/sys/kern/vfs_subr.c >>>> head/sys/sys/jail.h >>>> head/sys/sys/mount.h >>>> head/usr.sbin/jail/jail.8 >>>> >>>> Modified: head/lib/libjail/jail.c >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>> --- head/lib/libjail/jail.c Fri May 4 20:38:26 2018 (r3332= 62) >>>> +++ head/lib/libjail/jail.c Fri May 4 20:54:27 2018 (r3332= 63) >>>> @@ -1048,7 +1048,13 @@ kldload_param(const char *name) >>>> else if (strcmp(name, "sysvmsg") =3D=3D 0 || strcmp(name, "sys= vsem") =3D=3D 0 || >>>> strcmp(name, "sysvshm") =3D=3D 0) >>>> kl =3D kldload(name); >>>> - else { >>>> + else if (strncmp(name, "allow.mount.", 12) =3D=3D 0) { >>>> + /* Load the matching filesystem */ >>>> + kl =3D kldload(name + 12); >>>> + if (kl < 0 && errno =3D=3D ENOENT && >>>> + strncmp(name + 12, "no", 2) =3D=3D 0) >>>> + kl =3D kldload(name + 14); >>>> + } else { >>>> errno =3D ENOENT; >>>> return (-1); >>>> } >>> >>> I'm curious about this part of the change. Why is it necessary to load= the module in the "allow.mount.noXXXfs" case, when the jail is forbidden t= o mount the filesystem? It seems like that would just load modules that are= n't going to be used. >>> Additional discussion at https://github.com/iocage/iocage/issues/689 . >>> -Alan >>> >>> Presumably such a parameter would be included in some jails in conjunct= ion with the positive being included in others (perhaps as a default). The= truth is I never really considered whether the "no" option would be used, = I just always treat these option as pairs. >>> It may be reasonable (at least in the allow.mount.* case) to silently d= isregard a "no" option that doesn't exist, but I don't know how many places= would need to be modified for that to go smoothly. Though I don't expect = that there would be too many people who bother to include a jail parameter = about a filesystem which they're not planning to use. >>> - Jamie >> >> >> Well, many people use the "no" option because one of the most popular ja= il managers, iocage, uses it under the hood. But since "no" is the default= , its presence on the command line is a noop. Are there any situations in = which the "no" option has an effect? The only two possibilities I could th= ink of were: >> >> 1) Somebody puts both the positive and negative options on the same comm= and line. From experiment, it seems like the last option takes effect. In= this case, the presence of the positive option would cause the kld to be l= oaded, regardless of the presence of the negative option. >> 2) When using hierarchical jails, it might make sense to use the positiv= e option for the outer jail and the negative option for the inner jail. Bu= t this would only be important if the inner jail inherited the outer jail's= parameters, which doesn't seem to be the case. >> >> So I can't think of any reason to continue to mount the kld for "no" opt= ions. Can you? >> >> >> 3) There's allow.mount.foofs as a global parameter, with some jails over= riding that with a jail-specific allow.mount.nofoofs. In that case, KLD lo= ading shouldn't be a problem as global parameters typically come first. >> >> It makes sense not to load a KLD for a "no" option, as long as that opti= on is then silently ignored. I wouldn't want it to error out with "unknown= parameter". > > > See also https://github.com/iocage/iocage/issues/689 This issue should be fixed, for iocage at least, by https://github.com/iocage/iocage/commit/3c38801335ed7c67505f0000b70c4b3febc= ddbc1 . -Alan