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  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 
> >> 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
> ___
> freebsd-jail@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-jail
> To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
>
-- 
-
4096R/D21D2752
 ECDF B597
B54B 7F92 753E  E0EA F699 A450 D21D 2752
Philip M. Gollucci (pgollu...@p6m7g8.com) 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.
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"

Re: Time for those old global jail sysctls to go

[James Gritton]

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  
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
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"

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  
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
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"