Date: Fri, 30 Mar 2018 19:50:20 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 226931] Deprecating jail(2) and related sysctls Message-ID: <bug-226931-13-ToqJPEADXB@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-226931-13@https.bugs.freebsd.org/bugzilla/> References: <bug-226931-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D226931 --- Comment #7 from Bryan Drewery <bdrewery@FreeBSD.org> --- (In reply to Jamie Gritton from comment #6) > (In reply to Bryan Drewery from comment #5) > The idea will be to have "jls -j 0" to report on the current jail (if > jailed). This would allow any jail parameter to be examined (with some > exclusions for security), instead of just that static list. >=20 I'm not fond of this as now I'll need 2 different lookups supported and the idea of running 'jls' from a jail but with -j0 to find out the current jail= 's parameters feels really wrong since it is not jail 0.=20 > The problem I have with the sysctls isn't the situation around reading th= em, > but that there's a long-standing and incorrect perception that setting th= em > affects current jails. I would keep them around read-only, but their very > existence would continue that confusion. IMHO removing them (and not even setting read-only for a release or two) violates POLA and may break a lot of other scripts. Especially given this is securi= ty related I think they need to remain read-only for at least 1 release. I do= n't see the harm in having the read-only sysctls. It's not like you can set other read-only sysctls, like hw.ncpus, from the host or jail and yet people don't expect it to work. If they are not read-only now then yes that's a b= ug that needs to be fixed. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-226931-13-ToqJPEADXB>