In D47668#1088649, @igoro wrote:

It seems there is an agreement to split it onto two buffers per jail: both are readable by parent jail, while only one is readable by a jail itself. The updated patch reflects this concept. For now metaext and metaint naming is used as external/internal concept. The naming is open for discussion.

In D47668#1087217, @jamie wrote:

In D47668#1087001, @igoro wrote:

• The current state of the patch allows reading meta by any user within a jail. Do we want to disable it by default and add something like allow.read_meta or allow.metadata parameter to control it per jail?

I see a use case for both. Per-jail metadata just for the jail manager, and per-jail environment that the jail itself can see. If both exist, there's no need to set permissions.

In D47668#1087166, @kevans wrote:

Just tossing in a general +1, I haven't taken any time to review this at the moment; I've thought about a similar notion in the past (jail tags) to be able to do some role-based querying of jails.

If I understand the code correctly security.jail.meta_maxbufsize is the upper limit of the amount of additional kernel memory the jail can tie down with this feature. If a jail is allowed to create sub-jails should each of them be able to allocate metadata up to the global limit or should each of them get its own limit and the allocation be counted (recursively) against the parent limits?

I can see the appeal of this to jail managers, but having just a single meta sysctl per jail implies that it has to be "owned" by a single writer. This requires everything wanting to make use of this new feature to be tightly coupled to the writer. A flat list of key=value pairs (instead of a single value) would allow multiple users of this feature per jail e.g. multiple helper commands preparing just one aspect of a jail e.g. dynamic devfs ruleset loading, network setup/teardown, storage provisioning.

Address style feedback.

Using this /etc/jail.conf:

.include "/usr/local/etc/jail[.]conf";
.include "/etc/jail.d/*.conf";
.include "/usr/local/etc/jail.d/*.conf";

The __specialfd() system call is good to know about, but on its own doesn't provide a way to atomically create a configured jail with its lifetime tied to the file descriptor unlike passing a negative integer as "desc" argument to jail_set. There would either be a window where the jail would exist without a file descriptor associated with it which would reintroduce races and resource leak or the file descriptor has to start out unattached to a jail and be passed to the jail_set(JAIL_CREATE) call. The later design choice would get rid of the awkwardness of (ab-)using negative file descriptor numbers to request a file descriptor via an in-out parameter.

In D43696#996669, @dvl wrote:

I read the description, but I'm still not sure how a jail descriptor would be used. How about some pseudo-code, to illustrate the concept please?

In D41318#980524, @pauamma_gundo.com wrote:

No manual page to review, yet manpages is a group reviewer. Did a file get accidentally left out?

Is there enough space in the message to help users by giving them a reference to the new interface to express the same configuration and what form of reference would work well for this?

Good catch.

The interface name restriction function is a judgment call restricting users from creating problematic (for shell scripts) interface names. Applying the same restrictions to existing services like netif and routing could break (partly) working configurations.

In D40377#922101, @nyan_myuji.xyz wrote:

In D40377#922083, @crest_freebsd_rlwinm.de wrote:

The jail_name variable must be initialised to NULL. This should be done through an explicit char * jail_name = NULL; in line 101 of route.c.

Static storage are always initialized to 0/NULL by C standard.

The jail_name variable must be initialised to NULL. This should be done through an explicit char * jail_name = NULL; in line 101 of route.c.

It reads to me like initialising jail_name to NULL and replacing if (usejail) with if (jail_name != NULL) would make the usejail variable superfluous. Splitting a pointer and its validity into two variables like this (jail_name and usejail) introduces the potential for contradiction if only one of the two is updated. If this split is required for something I would like to see them stored together in a struct { char *, bool } instead of destructured into two variables.

Just a small nitpick: I would prefer a macro #define MAX_INCLUDE_DEPTH 32 or constant static const unsigned int max_include_depth = 32; somewhere above the include_config() in config.c instead of the literal to improve readability.

The jail(8) man page needs to be updated to reflect the new -F flag.

What is gained by having PID 1 acquire sub-reaper status given that it's the reaper? What are the expected semantics for proctl(PROC_REAP_ACQUIRE) in PID 1? Would it be enough to wrap the procctl(…) call with if ( getpid() != 1 ) { … } or is there more to this?

This change has been blamed to cause kernel panics on the FreeBSD current mailing list: https://lists.freebsd.org/archives/freebsd-current/2023-March/003381.html. It's been reported that reverting commit 0b56641cfcda30d06243223f37781ccc18455bef allows starting jails without triggering the observed kernel panic.

In D28199#636696, @rew wrote:

bhyve/ipc: use SOCK_DGRAM

• use SOCK_DGRAM instead of SOCK_STREAM
• have bhyvectl(8) share ipc.h from bhyve(8)
• fix naming semantics of MAX_SNAPSHOT_VMNAME, now called MAX_SNAPSHOT_FILENAME.

Previously, snapshot.h and bhyvectl.c each had their own
#define MAX_VMNAME 100, this is now shared at vmmapi.h - the
value has also been changed to 89. It's a limitation for the
unix domain socket path as constrained by SUNPATHLEN (104).
The prefix for the socket path is BHYVE_RUN_DIR, which by default
is '/var/run/bhyve/' (15). 104-15 = 89.