svn commit: r354458 - head/libexec/rc/rc.d

[Edward Tomasz Napierała]

On 1110T1147, Conrad Meyer wrote:
> Hi,
> 
> Response inline below.
> 
> On Sun, Nov 10, 2019 at 08:08 Edward Tomasz Napierala <trasz at freebsd.org>
> wrote:
> 
> > On 1109T2049, Alexander Leidinger wrote:
> > > Quoting Edward Tomasz Napierala <trasz at freebsd.org> (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".

[..]