A jail with no userland

If we build a jail, and don't put a userland in it, will it act like a docker container and pull from the host's kernel?
 
I don't know what docker does, but if you have no userland in your jail, it's exactly that--a kernel, and no world to go with it. If you want to make "thin" jails, you can copy in only the files necessary to run whatever you want to within the jail.
 
In the meanwhile, I found this reference to the architecture handbook, which better explained the kernel and userland roles in a jail.

REF: https://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/jail.html


Yes, I had read those man page references and some books on jails over the past few months. However, I found examples of thin jails under-explained. In one book by Lucas, "thick" or "thin" jails had to do with whether or not a ZFS clone was being used for the filesystem. Very confusing, and not relevant to these questions I have had about application jails.

Most examples, like we see in the man pages, mention that a separate copy of the OS does not have to be provided; but, then they go on to do it anyway. If we look at what the archtectural handbook has to say, we can come to a better understanding of what would work and why.
 
Well, you probably should look into how the kernel hands over execution to init and then go from there. in some cases you might even be able to just replace init with whatever program you want to run but usually there will be stuff missing that's usually handled by init and all the scripts started from there. In any case it should be very well possible to cobnstruct a custom minimalistic init tailored to your target task and thereby having less/no reliance on userland/libraries. I think it could also be a good idea to look into busybox/toybox and/or figuring out how to do static builds of your required tools.
 
I looked upon this reply and did not find it helpful. Sending judgmental comments like "RTFM" is not only presumptuous, but misleading. I have referred to those documents many times.
I did not mean to offend you, but instead point to what ekvz wrote above. Since there is little to no use in "running" a bare kernel, I asked what you meant with "pull in" and you did not give an answer.
 
I asked what you meant with "pull in" and you did not give an answer.

Yes, pull in is pretty generic. I don't know what's ment by it in this context either. Maybe docker is intercepting exec/open calls and tries to satisfy those that would result in a 'file not found' error by copying from the host system where possible? I don't know docker well enough to be really sure. In any case doing something like this would seem to me like it's asking for trouble as docker has absolutely no way of knowing what the users intentions are and therefore won't be able to tell what should and what shouldn't be there. Maybe gladiola could clarify a bit what the expected action is when pulling stuff in.

Edit: I guess it would be interesting to write a wrapper around the jail functionality that tries to externally imitate docker and see how close one can get but if that happens it probably won't be me who did it. On one hand i don't really care about docker and on the other are so many ideas with so little time...
 
If we build a jail, and don't put a userland in it, will it act like a docker container and pull from the host's kernel?
I don’t quite understand the question. There is no such thing as the “host’s kernel”. There is only one kernel. And how exactly would you „build“ a jail without userland? And what would you like to pull from where?

Well, a jail does not have to have its own userland. For example, a process can put itself into an empty jail, like /var/empty. It won’t be able to do much because it cannot access any files, but it still might be able to perform certain network services, for example, or communicate with related processes via shared memory. Conversely, a jail may use the same userland as the host, either by starting the jail with the chroot path set to “/”, or by mounting the host’s userland into the jail’s chroot with nullfs(5) or similar. However, I suppose that’s not what you mean.
 
hm, one would need a small init system, like in docker dumb-init or go-init. I have no experience with non-standard init systems under FreeBSD, but maybe/hopefully something like s6 could be used in our land to have an alternative to those great application container solutions out there. Maybe sadaszewski from focker knows more or could explain how focker is handling that
 
hm, one would need a small init system, like in docker dumb-init or go-init. I have no experience with non-standard init systems under FreeBSD, but maybe/hopefully something like s6 could be used in our land to have an alternative to those great application container solutions out there. Maybe sadaszewski from focker knows more or could explain how focker is handling that

As far as minimalistic solutions are concerned i don't see much point to use a real init system (even as simple/dumb/tiny as busybox init) at all. A static /bin/sh and a handful of tools should be able to take care of pretty much anything. Especially in a jailed environment where you don't have to deal with a lot of external factors.

If going after maximum flexibility is the goal i'd argue the choice of init system would not matter much besides it likely being advantageous to use one that has good overall support to begin with and just cutting it down where needed. At least if said init system is appropriately flexible (which being mostly script based should satisfy rather easily).
 
Can you jexec something in a jail that isn't running?
jexec(8) can only be used with an existing jail. A jail exists if either at least one process is running inside it, or if the jail’s persist parameter is set. From the jail(8) manual page:
Code:
persist
             Setting this boolean parameter allows a jail to exist without any
             processes.  Normally, a command is run as part of jail creation,
             and then the jail is destroyed as its last process exits.  [...]
 
Back
Top