jail(8) allow.socket_af, unknown oid

[Jamie Gritton]

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.

- Jamie


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,
>>> which
>>> states to allow access to protocol stacks that have not had jail
>>> functionality
>>> added to them.
>>>
>>> [snip]
>>>
>>> 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
>> show up.
>>
>> Or, in a short answer to your last question: this isn't a tunable in the
>> normal sysctl way, just a jail parameter.