Time for those old global jail sysctls to go

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Time for those old global jail sysctls to go

James Gritton-2
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.

- Jamie
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Time for those old global jail sysctls to go

Bjoern A. Zeeb
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?


/bz
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Time for those old global jail sysctls to go

James Gritton-2
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Time for those old global jail sysctls to go

Philip M. Gollucci
Trying to catch runtime is a loosing batter for this in ports but exp rum
worthy

On Thu, Mar 22, 2018 at 10:44 AM James Gritton <[hidden email]> wrote:

> 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
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-jail
> To unsubscribe, send any mail to "[hidden email]"
>
--
---------------------------------------------------------------------------------
4096R/D21D2752
<http://pgp.mit.edu/pks/lookup?op=get&search=0xF699A450D21D2752> ECDF B597
B54B 7F92 753E  E0EA F699 A450 D21D 2752
Philip M. Gollucci ([hidden email]) c: 703.336.9354
Member,                           Apache Software Foundation
Committer,                        FreeBSD Foundation
Consultant,                       P6M7G8 Inc.
Director Cloud Technology,        Capital One

What doesn't kill us can only make us stronger;
Except it almost kills you.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[hidden email]"