From owner-svn-src-head@freebsd.org Sun Nov 10 20:25:12 2019 Return-Path: Delivered-To: svn-src-head@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 27902178F74; Sun, 10 Nov 2019 20:25:12 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47B5940BB7z4LPY; Sun, 10 Nov 2019 20:25:11 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wr1-x42b.google.com with SMTP id w9so5628384wrr.0; Sun, 10 Nov 2019 12:25:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=9oAiSq1XKacZhKlvqCSPtd2Wo3LGMTJX66SPbxW3OL4=; b=m2aizYPffqQKtzQkJf32/r0mWq+ITkoPtKGFhJ58RU9D6n3Z8o/JEflQ2TWCkORNPH aHl+8Lj+HFt9lndIP7z2945GBblpSIZX6WwHcU6fjNuGQSq0Q97rSWIOMTXlYRsAEIdG IdzKbmB6wL0dHXYMRvB8EqZxeR7z7CeBUjksO21hanOwlqvwYnnBCkUKA0JeLQdShi3K GH00d319NjJbgPBnAe6vtDBFJVXWwyKBWa/ugXJ6BwZGp3wX9UEc08XKUtV8fjJZl+do VMxWEQ8FwtbPdNSHDQseIU/ZeoClQqKzhR1A/y0aNV3ds6N/JKk8vv0GTU8CW5gxq+ao GEew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=9oAiSq1XKacZhKlvqCSPtd2Wo3LGMTJX66SPbxW3OL4=; b=oqgr/sVg3vgr27OqCUzuL0kd2WzYPjHzgSKWUi8kDf4DImupYq09WLcu9KyWFC+gua RL45x5/SX/hWW+1VdKHjhQtQfeyBbMSILbEPfkd11zHYnwnhDy0bI7RhzUI6nUO4AuCh phLp/dinlCSmqwV1YhTYSV9WObgm7dsp+fazK/7SsB3eXEJVi8J+3VGC3NstLvuqrbQy nkoxwgfY1mu5OBxLaCcBdX1tBBdLKyIl4rgbmAGhbAUBXbLVIu2PZSxsNL/sKVEy9OpG PU2qZa25QJ70Ozur1++KWU6pDKqcxLinuq6zVI/qxXNJ739nQjPdfgwis4q13omXgY9Y nCuQ== X-Gm-Message-State: APjAAAU+3DH2PpMdvKJZsOwJlLJCJyX1bTTmIpduce1YS1scT/KOgyGk z6akg+sYy4YttGqar+RTQoh+el2P X-Google-Smtp-Source: APXvYqzeS0buJ1PGA+pLDsZ89btq9vQRjmofgp0OSe7J0Rfy+EKVZ0DgsjPFp3337cQZvLODJHtS3A== X-Received: by 2002:a5d:5411:: with SMTP id g17mr14152141wrv.360.1573417508856; Sun, 10 Nov 2019 12:25:08 -0800 (PST) Received: from brick (cpc92302-cmbg19-2-0-cust461.5-4.cable.virginm.net. [82.1.209.206]) by smtp.gmail.com with ESMTPSA id w132sm21483647wma.6.2019.11.10.12.25.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 10 Nov 2019 12:25:07 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sun, 10 Nov 2019 20:25:04 +0000 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Conrad Meyer Cc: svn-src-head@freebsd.org, src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r354458 - head/libexec/rc/rc.d Message-ID: <20191110202504.GA1070@brick> Mail-Followup-To: Conrad Meyer , svn-src-head@freebsd.org, src-committers@freebsd.org, svn-src-all@freebsd.org References: <201911071815.xA7IFOhI070066@repo.freebsd.org> <20191109204958.Horde.B0ynnS_aur1OZimnDNObsAt@webmail.leidinger.net> <20191110160819.GA1095@brick> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47B5940BB7z4LPY X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2019 20:25:12 -0000 On 1110T1147, Conrad Meyer wrote: > Hi, > > Response inline below. > > On Sun, Nov 10, 2019 at 08:08 Edward Tomasz Napierala > wrote: > > > On 1109T2049, Alexander Leidinger wrote: > > > Quoting Edward Tomasz Napierala (from Thu, 7 Nov > > > 2019 18:15:24 +0000 (UTC)): > > > > > > > Author: trasz > > > > Date: Thu Nov 7 18:15:24 2019 > > > > New Revision: 354458 > > > > URL: https://svnweb.freebsd.org/changeset/base/354458 > > > > > > > > Log: > > > > Extend the linux rc script to mount the neccessary file systems, > > > > set ELF fallback brand, and load pty(4). > > > > > > We never did something like that. We have it documented everywhere > > > that it needs to be done manually. So this is at least a POLA > > > violation. It is great that the nocover option is used in the mount, > > > but it's still some kind of layering violation (I may want to have > > > only a subset mounted, or nothing at all). > > > > It is kind of a POLA violation, but previously the linux_enable > > knob didn't do much apart from loading the linux{,64}.ko kernel > > module and doing something weird with ldconfig, which I'm not > > even sure is actually useful. In other words, the old behaviour > > can be restored by just not using linux_enable, and instead > > loading the kernel modules the same way all the others are loaded. > > > > Could you give me some use case why someone would want only a subset > > of the filesystems? > > > They’re an additional attack surface. If your few linux applications get > by with fewer vfs, you might want to avoid the others. I’m not particularly > attached to this reason. And imo, linux64.ko kind of dwarf that attack > surface concern, so it’s maybe a silly point. Yeah. Imho it's kind of like removing parts of kernel itself - you can do that, if you really wanted to, but we don't provide separate knobs to make it particularly easy. > Another problem with the current code is (and I may be mistaken here) I > think that it ignores mount options configured in the admin’s /etc/fstab. > Eg I configure my /tmp with a hard limit on memory use and if I were to > mount a compat shm tmpfs, I’d also want its memory use bounded. “Nocover” > protects from covering any existing “auto“ mounts, but one can imagine > specifying the linux compat mount “noauto”. > > I am on board with making this stuff more “batteries included” and usable > by default, but just echoing the request for configurable knobs (I don’t > care about the defaults). My point is... well, there are two. First is, it's configurable already: you can comment out parts of the rc script you don't want, or you can not set linux_enable in the first place and do things it would otherwise do for you by in the usual manner - add the modules to loader.conf, add a line to sysctl.conf etc. The script simply provides a shortcut to match what 90% of users want. Second, in order to implement something properly, I need to understand how it's going to be used. I guess I worded it quite badly in the previous mail; it's wasn't supposed to sound like "Can you give me some use case because I think you're wrong", but rather a "Can you give me some use case, because without it I have no idea how to design it to fit it". [..]