does anyone use these any more?

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

does anyone use these any more?

Michael W. Lucas-2
Hi,

Context: I'm writing a book on jails on FreeBSD.

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?

allow.dying - it's not dying very long, why make changes?
persist - why keep it around?

exec.jail_user, exec.system_user -lots of permissions problems

exec.system_jail_user - use a system uid inside the jail, why?

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...
_______________________________________________
[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: does anyone use these any more?

Milan Obuch-5
On Thu, 13 Sep 2018 09:11:08 -0400
"Michael W. Lucas" <[hidden email]> wrote:

> Hi,
>
> Context: I'm writing a book on jails on FreeBSD.
>
> 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?
>
> allow.dying - it's not dying very long, why make changes?

> persist - why keep it around?

I think this is usefull for vnet jails, aka VIMAGE.

Milan

> exec.jail_user, exec.system_user -lots of permissions problems
>
> exec.system_jail_user - use a system uid inside the jail, why?
>
> Thanks,
> ==ml
>

_______________________________________________
[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: does anyone use these any more?

Isaac (.ike) Levy-2
In reply to this post by Michael W. Lucas-2
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...
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-jail
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[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: does anyone use these any more?

Oleg Ginzburg
In reply to this post by Michael W. Lucas-2
Hi,

(sorry, I am not a member of freebsd-jails ML)

mwlucas > https://lists.freebsd.org/pipermail/freebsd-jail/2018-September/003619.html
mwlucas > persist - why keep it around?

One case of persist in CBSD (as example) for many years is ability to
ZFS attach and interface renaming for vnet-based jails without
'post-execution' script:

https://github.com/cbsd/cbsd/blob/11.2.1/tools/makejconf#L95

Without persist mode, jail was created and execute <exec_start> script
atomically and without interruption (you can not insert between
creating a container and /etc/rc start sentience anything that you
need, for example: 'zfs attach' or rename epairXXX to eth0 )

With persist mode, CBSD created jail in follow scenario:

1) jail -c (create jail) in persist mode ( with empty exec.start script )
2) exec inside jail something  (zfs attach, /sbin/ifconfig ... ), what
you need to do before launching /etc/rc -> /etc/rc.d/*
3) execute normal /etc/rc sequence

in this way, /etc/rc.d/zfs can mount ZFS on 'start' stage without
execution from CBSD wrapper 'late' commands after jail start, e.g (
jexec X /sbin/zfs mount + restart all services ))

Perhaps because of a misunderstanding of this option, exec.created
hook was created in FreeBSD 12-HEAD ;-):

https://lists.freebsd.org/pipermail/freebsd-jail/2018-August/003616.html

With exec.create, the 'persist' option is no longer so relevant as before.
_______________________________________________
[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: does anyone use these any more?

Kristof Provost
In reply to this post by Michael W. Lucas-2
On 13 Sep 2018, at 15:11, Michael W. Lucas wrote:

> Context: I'm writing a book on jails on FreeBSD.
>
> 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?
>
> allow.dying - it's not dying very long, why make changes?
> persist - why keep it around?
>
The pf tests (/usr/src/tests/sys/netpfil/pf) use persisted vnet jails to
test pf.
They set up jails with varying configurations and throw traffic at them.
There’s no need for any process to be running in the jail. The
relevant part is the network configuration.

Regards,
Kristof
_______________________________________________
[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: does anyone use these any more?

Alexander Leidinger
In reply to this post by Oleg Ginzburg
Quoting Oleg Ginzburg <[hidden email]> (from Thu, 13 Sep 2018  
18:45:51 +0300):

> With persist mode, CBSD created jail in follow scenario:
>
> 1) jail -c (create jail) in persist mode ( with empty exec.start script )
> 2) exec inside jail something  (zfs attach, /sbin/ifconfig ... ), what
> you need to do before launching /etc/rc -> /etc/rc.d/*
> 3) execute normal /etc/rc sequence
>
> in this way, /etc/rc.d/zfs can mount ZFS on 'start' stage without
> execution from CBSD wrapper 'late' commands after jail start, e.g (
> jexec X /sbin/zfs mount + restart all services ))
>
> Perhaps because of a misunderstanding of this option, exec.created
> hook was created in FreeBSD 12-HEAD ;-):

You could also call exec.created to be a much cleaner solution to this  
problem which also allows to do something like this with the base  
system only without the need for replacements for the jail rc scripts  
(additionally it makes it more easy for 3rd party jail management  
tools).

> https://lists.freebsd.org/pipermail/freebsd-jail/2018-August/003616.html

Note, the MFC to 11 of this is on my TODO list.

Bye,
Alexander.

--
http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[hidden email]"