# A jail with no userland



## gladiola (Sep 16, 2020)

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?


----------



## `Orum (Sep 16, 2020)

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.


----------



## Mjölnir (Sep 16, 2020)

gladiola said:


> 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?


Pull _what_?

RTFM init(8) & search for "jail".
RTFM jail(8) & jail.conf(5) & search for "persist".


----------



## gladiola (Sep 16, 2020)

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.


----------



## gladiola (Sep 16, 2020)

mjollnir said:


> Pull _what_?
> 
> RTFM init(8) & search for "jail".
> RTFM jail(8) & jail.conf(5) & search for "persist".


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.


----------



## ekvz (Sep 16, 2020)

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.


----------



## Mjölnir (Sep 16, 2020)

gladiola said:


> 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.


----------



## ekvz (Sep 16, 2020)

mjollnir said:


> 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...


----------



## olli@ (Sep 16, 2020)

gladiola said:


> 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.


----------



## rootbert (Sep 16, 2020)

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


----------



## ekvz (Sep 16, 2020)

rootbert said:


> 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).


----------



## unitrunker (Sep 16, 2020)

Can you jexec something in a jail that isn't running?


----------



## ekvz (Sep 16, 2020)

unitrunker said:


> Can you jexec something in a jail that isn't running?



Is this question directed at me?


----------



## olli@ (Sep 16, 2020)

unitrunker said:


> 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:

```
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.  [...]
```


----------

