Defining proposal A for FreeBSD jail configuration #8
Conversation
|
I added a table showing the mapping from traditional jail config parameters to the runtime spec. |
|
FreeBSD-specific section and container configuration links not working |
This started as a branch in opencontainers/runtime-spec and I made the links relative. I have made them absolute for now - they can change back if this (or something like it) gets merged to runtime-spec. |
dfr
force-pushed
the
simple-jail
branch
5 times, most recently
from
d5315f6
to
adc1db4
Compare
|
Fixed lint |
docs/proposals/PROPOSAL_A.md
Outdated
|
|
||
| The jail name is set to the create command's `container-id` argument. | ||
|
|
||
| The `devfs_ruleset` parameter is only required for jails which create new `devfs` mounts - typically OCI runtimes will mount `devfs` on the host. |
There was a problem hiding this comment.
How would the ruleset itself be specified? Can that be defined through the config?
There was a problem hiding this comment.
For the container jail's devfs, which is mounted by the host, the ruleset is set as a mount option and defaults to ruleset 4. I'm not sure how useful the devfs_ruleset parameter is for container jails, possibly for nesting? I wasn't going to try to map this one to the json config, at least until we have a use-case which needs it.
There was a problem hiding this comment.
I think just having this as numbers requires that whatever higher-level tool is creating the OCI bundle is aware of the existing devfs rulesets on the host. Even if we don't want to provide a mechanism to author rulesets from within a bundle, we should call this out as a requirement for the higher-level tool.
There was a problem hiding this comment.
The main use-case for this is probably nesting containers - in that case, perhaps we could use the container's ruleset number as a default for devfs_ruleset?
| The following parameters can be specified for for the container jail: | ||
|
|
||
| - **`parent`** _(string, OPTIONAL)_ - parent jail. | ||
| The value is the name of a jail which should be this container's parent (defaults to none). |
There was a problem hiding this comment.
In ocijail currently, only name but it wouldn't be hard to support both. On the other hand, this interface is not intended for humans and need not be 'user-friendly'. The caller should know the name of the parent.
| - **`host`** _(string, OPTIONAL)_ - allow overriding hostname, domainname, hostuuid and hostid. | ||
| The value can be "new" which allows these values to be overridding in the container or "inherit" to use the host values. If set to "new", the values for hostname and domainname are taken from the base config, if present. | ||
| - **`ip4`** _(string, OPTIONAL)_ - control the availability of IPv4 addresses. | ||
| The value can be "new" which allows the addresses listed in **`ip4Addr`** to be used, "inherit" which allows all addresses in the jail's vnet or "disable" to stop use of IPv4 entirely. |
There was a problem hiding this comment.
In the case of a child jail of a parent with "new", I would assume "inherit" means to allow all addresses that are part of the parent's vnet rather than all addresses of the host. Is that correct?
There was a problem hiding this comment.
That is a good question. This isn't well documented but the kernel implementation will return EINVAL if vnet is set to "new" and ip4 or ip6 is set at all. In my testing, the way to share host or parent addresses is to leave vnet unset and set both ip4 and ip6 to "inherit". To create a new network namespace for the container, set vnet to "new" and leave ip4 and up6 unset.
| | allow.mount.* | see below | | ||
| | securelevel | - | | ||
|
|
||
| The jail name is set to the create command's `container-id` argument. |
There was a problem hiding this comment.
Do we want to require this? I can imagine a runtime wanting to manipulate the name to some degree, such as a prefix or suffix.
There was a problem hiding this comment.
At the moment, I need to be able to locate the jail outside the runtime - this is needed to read metrics from the container using netstat and rctl. The spec states that id MUST be unique across all containers on the host so I don't see any downside to use the id for consistently naming the jails.
docs/proposals/PROPOSAL_A.md
Outdated
|
|
||
| The jail name is set to the create command's `container-id` argument. | ||
|
|
||
| The `devfs_ruleset` parameter is only required for jails which create new `devfs` mounts - typically OCI runtimes will mount `devfs` on the host. |
There was a problem hiding this comment.
I think just having this as numbers requires that whatever higher-level tool is creating the OCI bundle is aware of the existing devfs rulesets on the host. Even if we don't want to provide a mechanism to author rulesets from within a bundle, we should call this out as a requirement for the higher-level tool.
dfr
force-pushed
the
simple-jail
branch
4 times, most recently
from
062262a
to
b85eda4
Compare
Signed-off-by: Doug Rabson <[email protected]>
This is intended to be a one-to-one mapping from the runtime configuration to the kernel's jail parameters. This keeps the runtime as simple as possible, moving all policy decisions to the container engine (e.g. podman, containerd, cri-o).