I think the current situation should be sufficient, where the only
mention of the parameter sysctls are the note that you can see them via
"sysctl -d security.jail.param".
The move toward jail parameters is also a move away from using sysctl
variables for the same purpose. In this new jail order, the only useful
jail-related sysctls are security.jail.jailed and
security.jail.max_af_ips, which are both mentioned in the "Sysctl MIB
Entries" section of the man page. I don't want to worry about the
sysctls that have been obsoleted by jail parameters.
On 05/26/10 11:48, Glen Barber wrote:
Thanks for the explanation. Would there be opposition about a patch for
jail(8) noting which sysctls are tunable by sysctl(8) and which are not?
On 5/26/10 12:57 PM, Jamie Gritton wrote:
On 05/25/10 11:54, Glen Barber wrote:
The jail(8) man page has an entry under 'allow.*', allow.socket_af,
states to allow access to protocol stacks that have not had jail
added to them.
Is this sysctl missing, or is it not a tunable?
The sysctls that describe available jail parameters don't always have a
type that sysctl(8) understands. In particular, the boolean parameters
are given a sysctl type of "B", and sysctl(8) will ignore them.
These aren't useful sysctls in any normal way - they never have a
meaningful value. The exist only so their types and sizes can be
determined by jail(8) and jail(3).
As per the jail(8) man page, you can use "sysctl -d" to show sysctl
descriptions without the value. Since it's only the values that
sysctl(8) doesn't understand, such parameters as allow.sock_af will then
Or, in a short answer to your last question: this isn't a tunable in the
normal sysctl way, just a jail parameter.