In D35198#797902, @dchagin wrote:

In D35198#797888, @jamie wrote:

Wow, that has been there for an embarrassingly long time!

Well, it's not a bug)) because the rpr cannot be NULL AFAIR, or Im missed something?

Wow, that has been there for an embarrassingly long time!

In D33339#756945, @glebius wrote:

@jamie I actually got one more question about this code. The code that checks for IP addresses clashing, in the old code under comment that starts "Check for conflicting IP addresses", in the new code separated into function prison_ip_conflict_check(), it would not allow to create a child that has IP address of a parent if parent has multiple addresses
...
So my patch doesn't change this behavior, but it seems counter-intuitive to me. And the comment actually says it is intended:

If there is a duplicate on a jail with more than one IP stop checking and return error.

Why so?

I take it this is for what we're seeing in Bug 260335.

This presupposes that a jail that isn't marked to persist isn't going to stick around for some other reason. A jail could be started for example to start a long-running daemon, or to be a parent of other jails. Automatically going away when its task is done is a feature of such a jail.

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.