Date: Thu, 13 Sep 2018 10:35:02 -0400 From: "Isaac (.ike) Levy" <ike@blackskyresearch.net> To: freebsd-jail@freebsd.org Subject: Re: does anyone use these any more? Message-ID: <1536849302.1027204.1506933680.463B23E5@webmail.messagingengine.com> In-Reply-To: <20180913131108.GA899@mail.michaelwlucas.com> References: <20180913131108.GA899@mail.michaelwlucas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi MWL, On Thu, Sep 13, 2018, at 9:11 AM, Michael W. Lucas wrote: > Hi, > > Context: I'm writing a book on jails on FreeBSD. CAN'T WAIT. > > There's a few options that I can't figure out why anyone would use > them. Does anyone use any of these any more, or are they leftovers > from the primordial jail era? > > If you do use any of these on FreeBSD 11+, would you mind saying why > and how? I'm answering based on much use/abuse of jail(8) over the years, but big caveat: I've never *used* the features you're asking about in any meaningful way. > > allow.dying - it's not dying very long, why make changes? > persist - why keep it around? So use for this is somewhat nuanced, IMHO. When running hosts with many jailed systems, or jailed processes which are hogging/pegging the system, or hardware which is flaky or nondetermistically performant, jails can take their sweet time time to start or stop. (I mean long time even without large exec.stop or exec.poststop or exec.prestop or exec.clean etc...). The system may simply be busy. Now, real world problem I've had: - large scale jailed host with active healthy jailed systems doing stuff - I go to kill a jail running a web server (and for whatever reason, I want it to stop serving http asap) - The jail takes it's sweet time and appears hung, (it's not), as it comes down slow- STILL SERVING THE http) In this case, because the jailed process tree is in the process of being torn down, killing that http server can get, um, *messy*. Messy like: - Do I really want to kill the jailed pid straight from the host? (What if I make a mistake and kill some other jail's httpd?) - Do I have some security context whereby I do not want to even manipulate the jailed process directly? (e.g. risk of jailed process causing harm by running kill(1) from the jailing host) So, I'd assume, "allow.dying" lets us jexec into the jail after the process tree is in the process of being destroyed, so we can cleanly do stuff to the jail as it dies. Real world: I've never even thought to use this "allow.dying" feature, but I do certainly it's intent as useful. > > exec.jail_user, exec.system_user -lots of permissions problems Not sure, I've frankly never understood these, they seem antithetical to everything I find powerful about jailing, (combining with base utilities which everyone cares about maintaining- not features that "jail people" care about). Using su(1) in the jailed process tree is frankly something I trust, (shouldn't we all?) I'd love to hear a good case for these, (or love to see them go away). > > exec.system_jail_user - use a system uid inside the jail, why? Bigsigh. So this gets into more "but jail, but not jail" stuff which I don't really understand (or like). Yet, I think I know why it happened: chroot(2) doesn't have the great socket/other process features which jail(2) has, and jail(8) can certainly be used much like one would use chroot. So, for that person who *really* wants chroot(8), but wants some feature from jail(2), they can jail(8) and use host system users (in assumed absence of any /etc/passwd in the jail). To me, this stuff which crosses the line between host and jail, totally goes against what I love about the simplicity in isolation of jailed systems, but I'm certain someone out there has an excellent and powerful mastery of using jail(8) to replace their uses of chroot(8) to some great effect. Hope my rambling here is useful- Best, .ike > > Thanks, > ==ml > > -- > Michael W. Lucas https://mwl.io/ > author of: Absolute OpenBSD, SSH Mastery, git commit murder, > Immortal Clay, PGP & GPG, Absolute FreeBSD, etc, etc, etc... > _______________________________________________ > 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1536849302.1027204.1506933680.463B23E5>