Time for those old global jail sysctls to go
James Gritton
jamie at freebsd.org
Thu Mar 22 14:44:16 UTC 2018
On 2018-03-22 02:56, Bjoern A. Zeeb wrote:
> On 22 Mar 2018, at 4:13, James Gritton wrote:
>
>> I've got a revision in the works <https://reviews.freebsd.org/D14791>
>> to
>> remove the security.jail.foo_allowed sysctls:
>>
>>> The old jail system had sysctls to set jail permissions for all jails
>>> (e.g. security.jail.mount_allowed), which were superseded by per-jail
>>> permissions (e.g. allow.mount). These old sysctls remain a constant
>>> source of confusion to users, who expect that setting the sysctl will
>>> change the behavior of existing jails. That the sysctl value at the
>>> time
>>> a jail is created may matter is a backward-compatibility hack that
>>> does
>>> little or nothing to relieve the confusion. So it's time for them to
>>> go.
>>
>>> Also, jail(2) has been replaced by jail_set(2) for a number of years
>>> now, and it really ought to retire - at least into the COMPAT world.
>>
>> This may be of interest to anyone who works with jails. My hope is
>> that
>> no current software relies on these old sysctls, and they can be
>> removed
>> with little trouble. But removing old things never seems to go that
>> easy.
>
> I think #1 action item is to put them under BURN_BRIDGES or however it
> was spelt if you really want to remove them.
> Then for the next major version they could go away ( I’d be all up for
> removing them immediately (incl. from the man pages ) but I remember
> there used to be 2-3 ports which used the jail v1 stuff; might be
> worth checking that they were updated or are gone?
BURN_BRIDGES indeed. I keep learning new things about this project!
Yes, the hard part of testing this will be going through ports which use
the jail stuff. The few places in the core code which still relied on
jail(2) weren't placed I'd think to look if I hadn't checked all of src,
and I imagine ports are a similar case.
- Jamie
More information about the freebsd-jail
mailing list