I'm not thrilled at the redundant call to vfs_flagopt(), which shouldn't be necessary because kern_jail_set has already looked for allow.novmm and set the permission bit accordingly. But by the time vmmdev_prison_set() is called, the old value of the permission bit is forgotten. So you're left with

In D29659#665126, @me_igalic.co wrote:

there are other candidates that return (0) or a single error that is always the same, but here we would need modifying the call-site :

• prison_check_af() 0/EAFNOSUPPORT
• prison_canseemount() 0/ENOENT
• prison_check() 0/ESRCH

Yeah, I'd been meaning to get around to that ;-).

This would work well with jexec -l, which is already somewhat like su -l but misses the parts you mention. In fact, I would recommend making clean (-l) the deciding factor instead of pwd (-u/U). And I don't see a reason why the same directory change shouldn't be done regardless of whether it's for a command or a shell.

Looks good - nothing to add.

In D28952#648403, @kevans wrote:

This is still a necessary change, it's just not the only one we need; I suspect both jail(8) and jexec(8) should try to switch to their root's id before running commands in a jail, so that administratively spawned stuff ends up with the jail's full mask.

In D28952#648403, @kevans wrote:

I suspect both jail(8) and jexec(8) should try to switch to their root's id before running commands in a jail, so that administratively spawned stuff ends up with the jail's full mask.

(edit) e.g., https://people.freebsd.org/~kevans//jail-cpuset.diff which accomplishes this for jail(8) on start/stop.

In D28952#648302, @kevans wrote:

In D28952#648283, @jamie wrote:

But how about this: first at least try using the intersection of the current and jail sets (whether or not currently jailed), and only as a EDEADLK fallback punt to just using the jailed set.

Yeah, I think that makes sense -- we're talking about EDEADLK fallback if the priv is also set, so that it naturally gets cpuset down if it can?

In D28952#648262, @jamie wrote:

This might be a reason to keep PRIV_JAIL_CPUSET, and have it generally be available to virtual as well as real root.

In D28952#648258, @me_igalic.co wrote:

how does this, or the current approach apply to jails in jails (which are under a specific CPU set?

Might PRIV_SCHED_CPUSET be sufficient for this? If a process has the ability to explicitly expand the current cpu list, it makes sense for it to be able to implicitly do so when attaching to a jail.

In D24570#616031, @netchild wrote:

Would it make sense to be able to override the path (BTW: /etc/jail.conf.d would be my preference), in the sense of having it as a variable in /etc/defaults/rc.conf (would this help in the netboot case)?
Would it make sense to make this a list,, so that I could do e.g. jail_conf_dir="/etc/jail.conf.d /usr/local/etc/jail.conf.d"?

In D28150#647893, @kevans wrote:

So, I'm going to ask a stupid question here; what all *actually* breaks if we end up with duplicate jids?

All previous work has been committed now (not without hiccups). This is the final-ish patch that only handles the main intent of the project.

Sorry I took so long - I confused your note that it should be reverted with a note that it *had been* reverted.

Updated for cc7b73065302 and d4380c0cdd05.

Updated for cc7b73065302 and d4380c0cdd05.

Updated for cc7b73065302 and d4380c0cdd05.

Updated for cc7b73065302 and d4380c0cdd05.

Updated for cc7b73065302 and d4380c0cdd05.

Updated for cc7b73065302 and d4380c0cdd05.

This is now the culmination of D28419, D27876, D28458, D28473, and D28515. The only thing remaining in this patch is the part that doesn't resurrect dying jails via jail_set, and instead renumbers the dying jails as necessary, and the userspace/man changes from before.

Fix up prison_deref_kill, which had some typos in which prison it was acting on. Also move prisons off of their parent's child lists along with the loop instead of all at the end.

A new version, built on top of D28419, and updated with other recent jail changes. With the addition of prison_isvalid() and prison_isalive(), the changes are significantly reduced.

Update for c050ea803eaa and add suggested mtx_assert.

In D28150#634852, @bz wrote:

I am not sure I like the idea of making jid's a first-class citizen just because our mgmt interface once did and we kept it for historic purpose and backward compat and habits are hard to change.

I am also not entirely opposed to the idea.

Update for various changes recently checked in to kern_jail.c.

It doesn't really make sense for this to be a separate revision, considering it's part of D28150 which overwrites much of the change here. So I'm rolling it all into a single revision instead.

Add full context to diffs

Add full context diff for kern_jail.c