From owner-freebsd-jail@freebsd.org Tue Nov 17 18:40:38 2020 Return-Path: Delivered-To: freebsd-jail@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7956B46C686 for ; Tue, 17 Nov 2020 18:40:38 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CbFBG34dfz3HtD for ; Tue, 17 Nov 2020 18:40:38 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 5C52FFBDF for ; Tue, 17 Nov 2020 18:40:38 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f179.google.com with SMTP id i12so16540386qtj.0 for ; Tue, 17 Nov 2020 10:40:38 -0800 (PST) X-Gm-Message-State: AOAM533qqZBf3w+9I/g4MkzXVB7CcZfNXn6+CWHDwsxvV5YqeA8oA2YV hraXC5glLBwEOGocLCTsYnCZkwjBH4/1voELbO0= X-Google-Smtp-Source: ABdhPJzQ7Q9A4wqixgSew8s/Mc700YS1l8dvjOy9zYES1iYjtbcUZ9z9f06tSvgcBGzhdnYyslp+mTIyaRoxEIX4N7o= X-Received: by 2002:ac8:3805:: with SMTP id q5mr1072747qtb.53.1605638437893; Tue, 17 Nov 2020 10:40:37 -0800 (PST) MIME-Version: 1.0 From: Kyle Evans Date: Tue, 17 Nov 2020 12:40:24 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: cpuset/jail creation To: freebsd-jail Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 18:40:38 -0000 Hello! I've done some work to try and make qemu-user-static honor cpuset and advertise a fake hw.ncpu to emulated processes based on the number of cpus actually available to it. In doing so, I discovered that created jail's inherit the parent jail's cpuset mask, rather than the creating process. This is OK for persistent jails, as one can create the jail, cpuset(1), then jexec whatever tasks they want to do; but jails that would otherwise not be persistent have to either deal with racy cpuset(1) after creation or settle for instead creating a persistent jail because they need a specific cpuset. I've got this patch that I'd like to propose[0], but it's unclear if it's really OK to do or if anyone else cares about this. I can't see any theoretical problem with it off-hand, as the creating thread should be guaranteed to have a cpuset that's valid as a child of the parent prison's cpuset. The patch creates a new poorly-named cpuset_create_root_td KPI to inherit the cpuset from the creating thread, and leaves the previous KPI intact in case something else is using it or to leave the door open to adding an option to go either way with this (inherit from parent jail vs. inherit from thread). >From a MAC perspective, I think it makes a lot of sense to inherit from the thread by default. e.g. a non-root user could be granted PRIV_JAIL_SET, then they're freely able to create jails using the parent jail's root cpuset even if they've been limited themselves via login.conf(5) restriction. For most existing use-cases, it should effectively be a nop unless they were cpuset(1)ing a process not expecting the created jail to inherit that. Thoughts? Thanks, Kyle Evans [0] https://people.freebsd.org/~kevans/jail-cpuset.diff