Note that this has been accidentally chilling in a local branch for about four years, but at a brief glance over more recent changes I didn't see anything that might remedy this.

Would privileges actually work, I have no objections. But right now this change makes the very useful feature (at least for me), only available to root. I do often use 'jail -u <me> / something 127.0.0.1 /bin/sh', and have the jailed processes only bound to localhost, otherwise they are normal (can be debugged etc).

It would be pity to loose the ability. Can we have at least a knob to re-enable the current behavior?

In D51645#1179733, @kib wrote:

Would privileges actually work, I have no objections. But right now this change makes the very useful feature (at least for me), only available to root. I do often use 'jail -u <me> / something 127.0.0.1 /bin/sh', and have the jailed processes only bound to localhost, otherwise they are normal (can be debugged etc).

It would be pity to loose the ability. Can we have at least a knob to re-enable the current behavior?

I'd be happy to add a knob- I'd like to get some input from Jails folks on whether to default enable or disable, but my feeling here is that most jail deployments these days treat non-system users as distinct between jails and system.

Note that security.bsd.see_jail_proc can be used for similar effects,
but does not prevent a user from learning the pid of a jailed process
with matching creds and signalling it or rescheduling it (e.g., cpuset).

Well, that hasn't been true since commit 5817169bc4a0 ("Fix 'security.bsd.see_jail_proc' by using cr_bsd_visible()"; 2023/09/28), whose purpose was precisely to fix the flaw that, even if you couldn't see sub-jail processes because of security.bsd.see_jail_proc, you could attempt to blindly signal them or change their scheduling parameters (by guessing the PID or obtaining it through other means). (In passing, I'll note that security.bsd.see_jail_proc is a misnomer, it should have been something like security.bsd.see_sub_jail_proc.)

The change here has the value of forbidding to act on processes with same user ID in strict sub-jails, as by default these are expected to be independent, if seeing these has not been disabled with security.bsd.see_sub_jail_proc. I support enabling that new restriction by default, not so much based on the most probable scenarios but rather on security grounds, as the ability to be able to interact with a user in a sub-jail could be quite surprising to people that are not aware of our jails' details. Then, a knob is needed to support kib@'s case, and potentially others leveraging the user ID conflation that people have come up with.

In D51645#1179812, @olce wrote:

Note that security.bsd.see_jail_proc can be used for similar effects,
but does not prevent a user from learning the pid of a jailed process
with matching creds and signalling it or rescheduling it (e.g., cpuset).

Well, that hasn't been true since commit 5817169bc4a0 ("Fix 'security.bsd.see_jail_proc' by using cr_bsd_visible()"; 2023/09/28), whose purpose was precisely to fix the flaw that, even if you couldn't see sub-jail processes because of security.bsd.see_jail_proc, you could attempt to blindly signal them or change their scheduling parameters (by guessing the PID or obtaining it through other means). (In passing, I'll note that security.bsd.see_jail_proc is a misnomer, it should have been something like security.bsd.see_sub_jail_proc.)

I had kind of suspected this was the case, but hadn't yet found time to verify -- thanks, will revise.

In D51645#1179733, @kib wrote:

Would privileges actually work, I have no objections. But right now this change makes the very useful feature (at least for me), only available to root. I do often use 'jail -u <me> / something 127.0.0.1 /bin/sh', and have the jailed processes only bound to localhost, otherwise they are normal (can be debugged etc).

It would be pity to loose the ability. Can we have at least a knob to re-enable the current behavior?

An idea we've been kicking around is non-root jails, tied to the cred of the user that created them. That's definitely for later, given that not a line of code has been written and security will have to be fully thought through. But it's for just the kind of thing you're doing here.

In the meantime (and long-term), a knob makes sense - preferably in the form of a jail allow.* parameter rather than a global sysctl.

In D51645#1182984, @jamie wrote:

True, there's no real need for the PR_ALLOW_PRISON0 change, but since you went to the effort to make that macro anyway, it's a good place to showcase it.

Yeah, fair enough- though I also don't have any objection dropping that change entirely. OTOH, I think there's some benefit still in keeping the distinction between static flags and prison0 defaults clear in case we do add some allow flag that we wouldn't want on prison0 by default.

I'm planning to commit this within the next day or so, with the following note added to the commit message:

For development setups that involve regularly debugging jailed processes from outside the jail, consider adding `allow.unprivileged_parent_tampering;` to /etc/jail.conf.

My main concern here is heading off complaints from folks that just create ad-hoc jails with jail(8) and don't really use /etc/jail.conf otherwise. They probably already realize they can configure global parameters like this, but maybe not.