On 1110T1147, Conrad Meyer wrote: > Hi, > > Response inline below. > > On Sun, Nov 10, 2019 at 08:08 Edward Tomasz Napierala <tr...@freebsd.org> > wrote: > > > On 1109T2049, Alexander Leidinger wrote: > > > Quoting Edward Tomasz Napierala <tr...@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". [..] _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
