Can you describe the dlopen threat model a bit more? My assumption is, a typical Capsicum-aware app wouldn't be setting the rootdir/curdir at all. Or, if it does, it could call cap_enter(2) again before calling dlopen(3), clearing those vnodes.

Fix panic which occured when the PID is specified explictly.
Also handle wait6(2). Add some documentation. Pacify a test.

I agree this should be documented somewhere, but at the moment wait(2) doesn't mention Capsicum at all, and capsicum(4) doesn't mention wait(2). Perhaps a paragraph in pdfork(2), something along the lines of "processes created with pdfork cannot be waited for by a parent running in capsicum(4) mode"?

It appears to be working correctly now. Thank you all :)

I'm not sure what exactly happened here, but I suspect there was something wrong with testing it: while one of previous Kib's commits fixed the instapanic on "automount -c", it still doesn't work, see last few entries at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274992.

Thank you, I think I'm fine with toggling it from "async" to "sync" specifically for msdosfs.

In D42494#969894, @manu wrote:

In D42494#969882, @trasz wrote:

I’m not a huge fan of this one tbh. I seem to remember I had it like this for a while, and it was 1. Unbearably slow and 2. Increased flash wear and tear.

For 1/ yes it will be slower. But safer.

Doesn't this also enable it by default? If so, it might be a good idea to fix the instapanic it's causing first, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274992.

I’m not a huge fan of this one tbh. I seem to remember I had it like this for a while, and it was 1. Unbearably slow and 2. Increased flash wear and tear.

In D41564#950112, @brooks wrote:

I wonder if a chrootat(fd, path) that allows a NULL path would be more general?

Should there be a flags argument?

Implemented in a better way by https://reviews.freebsd.org/D34426.

FWIW, I've been playing with this idea on and off, and I have some patches, some of them not even entirely broken :) In particular I have fchroot(2) working: https://reviews.freebsd.org/D41564

Implemented as https://reviews.freebsd.org/D38933.

In D39507#899652, @dchagin wrote:

well, the part after a dash is not standart, depends on a distributive, so we can put here any information, and it would be nice to print p_osrel of the current process here.
However, I would propose completely remove the pr_osrelease from struct linux_prison as we have pr_osrel and due to the pr_osrelease was intended to map into the vdso page at the Note section. But its not possible due to jails and can be removed now.

In D38933#897702, @mjg wrote:

I strongly suspect the right way is to have linux binaries auto chrooted to /compat/linux or whatever you are looking up against and then have nullfs mounts inside for /home, /tmp and whatever else which makes sense to share. This avoids any suspicious lookups like failing to find a file in Linux because it is missing when it should not and trying to pick up the FreeBSD one. This also avoids adding any complexity to the kernel.

Hah, I've been working on something similar, although from a somewhat different, CHERI-related, angle :)

Only tangentially related, but I wonder if this constant shouldn't be defined for arm64 too?

My first thought about ENODEV was something about GEOM. ENOENT, on the other hand, would make it obvious what's going on: the root device node is simply not there.

I've been burned by this in the past, but I've assumed it's just me. This time, though, there was another person involved, and this made me reconsider. In this case it's not even that it's a remote machine: this is for a homebrew remote management mechanism; essentially we have BeagleBone Blacks hooked up to the actual machines (mechanically they are inside the machines), which provide remote console and virtual media, and halting one of those by mistake - for example when you fail to notice the cu(1) to the "real" machine has been disconnected - results in having to power cycle the whole thing, which is one thing our BBB-based remote management does not provide.

Linux, it’s a Linux core file :-) The easiest way is to use debootstrap port to bootstrap an Ubuntu Bionic userland, then chroot there and do “apt install gdb”. See https://wiki.freebsd.org/LinuxJails.

I’m not opposed to this patch, but isn’t this what core files are for?