Date: Thu, 22 Mar 2018 19:37:18 +0000 From: "Philip M. Gollucci" <pgollucci@p6m7g8.com> To: James Gritton <jamie@freebsd.org> Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, freebsd-jail@freebsd.org Subject: Re: Time for those old global jail sysctls to go Message-ID: <CACM2dAbOESdP16FZY10NO4fMw_WizA3vMhWMafmJZ-q0ab3TGQ@mail.gmail.com> In-Reply-To: <70fa76bee491a2c8a3de8a861c39ad9a@freebsd.org> References: <129ec9ac36d1e1d690924dba62d6c095@freebsd.org> <0073E940-4256-4EE7-BA26-2CE134595A26@lists.zabbadoz.net> <70fa76bee491a2c8a3de8a861c39ad9a@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jamie@freebsd.org> 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=E2=80=99d 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-unsubscribe@freebsd.org" > --=20 ---------------------------------------------------------------------------= ------ 4096R/D21D2752 <http://pgp.mit.edu/pks/lookup?op=3Dget&search=3D0xF699A450D21D2752>; ECDF B= 597 B54B 7F92 753E E0EA F699 A450 D21D 2752 Philip M. Gollucci (pgollucci@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACM2dAbOESdP16FZY10NO4fMw_WizA3vMhWMafmJZ-q0ab3TGQ>