What was motivation for this? Do you have any use case for that?

me_igalic.co I will created for this separated review.

Changes after markj@ and jamie@ review.

Gotcha, thank you I will refactor the code.

In D27128#606252, @jamie wrote:

In D27128#606198, @oshogbo wrote:

If I understand correctly - the allow.* and the suser has a reverted values. You can disable suser, which by default is enabled. I wanted to made it exactly the same as sysctl on the hosts system, but I don't have strong opinion here.
I'm not sure if I understand. Do you suggest to have allow.suser which allow you to change the suser sysctl?
There should be no possibility to get back the suser priviliged inside the jail.
In the scenario I tested you can give/retrieve the suser from the host.

The semantics of an allow.* bit (at least of one included in JAIL_DEFAULT_ALLOW) are exactly the same as you used in the suser_enabled parameter: enabled by default when a top-level jail is created, set to the parent jail's value by default when child jail is created, and cleared in all child jails whenever it's cleared in an existing parent jail. OK, not exactly - your loop to set the child jails will re-add the bit to children if re-added to a parent jail, which is against the general rule of restrictions cascading while easing those restrictions do not.

When I was talking about getting the suser privilege back, it was in the context of having separate parallel host-imposed and jail-controlled bits, both of which must be enabled to work. But that's clearly a dead end - especially now that I consider that the sysctl to revert security.bsd.suser_enabled is unavailable to a suser-disabled system.

@kevans Thank you for the review. :) I fixed the typo.
@emaste Sorry, fixed.
@jamie
If I understand correctly - the allow.* and the suser has a reverted values. You can disable suser, which by default is enabled. I wanted to made it exactly the same as sysctl on the hosts system, but I don't have strong opinion here.
I'm not sure if I understand. Do you suggest to have allow.suser which allow you to change the suser sysctl?
There should be no possibility to get back the suser priviliged inside the jail.
In the scenario I tested you can give/retrieve the suser from the host.

I created ZFS pull request: https://github.com/openzfs/zfs/pull/11152

I would prefer to commit this version. Sorry for me not responding for a while.

The whole limit infrastructure is missing for capnet,
I think I prefer the cap_netdb for those purpose.
If I recall it we had a few ideas what to add to netdb.

From my understanding, doing work in the user interface functions is the same as doing work in user program, as they are the same process. It won't be allowed if program is in cap mode.

Thats right, cap_exec_init, cap_exec_open, cap_exec_close are done potentialy in the sandboxed process.

I was mistaken we need service like this, we just need to work a little bit more on it.

Ou but I guess you wan't your new process not being in sandbox, right?

Please don't take this an a criticisms I just would like to know the advantages of this approach.

I wonder we can't just use fileargs and fexecve?

Update after emaste, markj and bcr review.

Oh sorry @emaste I some how didn't get the emails from your comments. I will address them ASAP.

In D24920#549047, @tsoome wrote:

In general, it seems nice. I'd like to see more for description; how the checkpoints would appear, what it means to the boot process, would it mean updates for some manual/handbook? It would nice to refer to zpool, not all people do know where to look for information.

Typo pointed by @kevans. Thanks!

Thank you @bcr and @greg_unrelenting.technology

Man pages fixes.

If you want I can commit this for you.

Some more notes.

Oh sorry I miss read the patch.
Then this looks good to me :)

This doesn't break multiple encrypted disks?
If I have 3 disk and only one should be decrypted by the loader?

Like Matt suggested I checked the behavior on Linux as well.

Thank you for working on this!
This doesn't seems like simple peace of code.