The current behavior is that if the jail block opens with a number instead of a string the number is bound to the jid parameter and the name parameter is left unbound. This means there're probably existing configurations in someone's production that use this way to set the jid and assign the name inside the jail block e.g. 42 { name = "my_jail"; } instead of my_jail { jid = 42; }. Changing this long standing, but underdocumented behaviour would break those jail configurations. :-/

"When the descriptor closes, do will the attached jail" should probably read "... so will the attached jail".

In D43696#1179550, @jamie wrote:

The big addition is kevent support. A jail descriptor can pass four notes:

The way descriptors were passed to/from jail_set and jail_get has been updated with new flag bits, instead of the old hacky method of checking of checking whether the passed number is -1. The descriptor number is still passed via the "desc" parameter, but now the flag bits control how it's used. I've updated the summary to describe these bits.

One new use of the descriptor is the flag JAIL_AT_DESC, which uses the described jail as the current/parent prison, in place of the caller's prison. This allowed child jails to be manipulated using a descriptor, in the spirit of the "fooat" family of file system calls.

I've added file access permissions, via the mode bits on the descriptor, settable via fchmod. By default the read bits are on (as anyone can call jail_get) and the write and execute bits are on for the user and only if it has the associated privileges (jail_set for write, jail_attach for execute). I also use the sticky bit the make the jail go away when the descriptor closes, similar to the way a process is killed when its process descriptor closes.

libjail has been updated to be aware of the desc parameter and flags, since it needs to know when to pass it to jail_get and retrieve it from jail_set.

Document new -x flag in jail(8).

Put the executable jail.conf(5) behind the -x option (as chicken bit).

Creating a review for a patch from 2011 in a PR that didn't get resolved in time doesn't make sense. The patch is against the old FreeBSD ZFS fork. FreeBSD has since replaced this branch of ZFS with OpenZFS.

In D50371#1158405, @markj wrote:

In D50371#1158401, @crest_freebsd_rlwinm.de wrote:

As brought up in OpenBSD the cleaner design would be to require the user to set a sticky O_BELOW flag on the file description with fcntl() to allow cross jail fd passing instead of hacking it into the file descriptor.

Well, I am not thrilled to introduce new name lookup semantics just to solve this problem. We could however make a sticky O_RESOLVE_BENEATH flag set in the file description with F_SETFL, and require it to be set when cross jail boundaries. That would be cleaner to implement since it doesn't require modification to the fget* interface. It is not as good with respect to compatibility, since it requires application changes, and then the file description referenced by the sender will also change (unnecessarily).

It's a nice example of how easy example how to use Capsicum by opening all resources before entering capability mode, but would better to call cap_enter() instead of caph_enter()?

As brought up in OpenBSD the cleaner design would be to require the user to set a sticky O_BELOW flag on the file description with fcntl() to allow cross jail fd passing instead of hacking it into the file descriptor.

Either that, or skip the element, reducing the length of the message.

Shouldn't such a feature allow setting the read/write permission per FIB instead of a single all or nothing flag?

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.