Page MenuHomeFreeBSD

kern_jail: add security.jail.children.max and .cur sysctl
ClosedPublic

Authored by igoro on Jan 23 2024, 10:46 PM.
Tags
None
Referenced Files
F102806413: D43565.diff
Sun, Nov 17, 10:34 AM
Unknown Object (File)
Sun, Oct 20, 10:33 PM
Unknown Object (File)
Sun, Oct 20, 10:33 PM
Unknown Object (File)
Sun, Oct 20, 10:33 PM
Unknown Object (File)
Oct 13 2024, 11:46 PM
Unknown Object (File)
Oct 2 2024, 7:07 PM
Unknown Object (File)
Oct 2 2024, 1:58 PM
Unknown Object (File)
Oct 1 2024, 2:41 PM
Subscribers

Details

Reviewers
jamie
kevans
Group Reviewers
Jails
Test Plan

kyua test -k /usr/tests/sys/kern/Kyuafile sysctl_security_jail_children

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

The purpose reasoning and initial discussion was in https://reviews.freebsd.org/D43476.

You'll want to add CTLFLAG_PRISON to the sysctl flags.

You'll want to add CTLFLAG_PRISON to the sysctl flags.

The leafs are meant to be read-only (flagged with CTLFLAG_RD), i.e. it looks like we do not need CTLFLAG_PRISON here.

a) Do you mean to add it for possible future upgrades when some leafs could be changed to read-write?
b) Probably, it was meant to add CTLFLAG_PRISON to the children branch node which is marked with CTLFLAG_RW? As I understand it would not make much sense for a branch node.
c) Or something else what I have not spotted yet :)

c) Or something else what I have not spotted yet :)

c) Jamie wasn't thinking and of course you don't need it for read-only.

A little test improvement with additional comment about the magic numbers.

c) Or something else what I have not spotted yet :)

c) Jamie wasn't thinking and of course you don't need it for read-only.

No problem, a usual thing for us, non-robots. Thanks for the confirmation.

I've tested it for AArch64 and AMD64 on my side. Do we need anything else for the patch? Or it's ready to hit the main?

This revision is now accepted and ready to land.Jan 25 2024, 10:28 PM
kevans added a subscriber: kevans.

Is the plan still to use JAIL_MAX in the test work, or to switch to this since tests can be executed started in non-prison0?

Is the plan still to use JAIL_MAX in the test work, or to switch to this since tests can be executed started in non-prison0?

Yes, the idea is to use this approach introduced by this patch.

May I ask for the help? To land the commit itself.