Add FreeBSD as a platform #1286
Conversation
dfr
requested review from
AkihiroSuda,
crosbymichael,
cyphar,
dqminh,
giuseppe,
hqhq,
kolyshkin,
mrunalp,
thaJeztah,
tianon and
utam0k
as code owners
|
Cc @samuelkarp |
config.md
Outdated
There was a problem hiding this comment.
features.md needs an update too
There was a problem hiding this comment.
When I originally looked at features.md, it seemed that the only platform-specific features are for Linux. So far, I don't think we have a need for platform features on FreeBSD.
config-freebsd.md
Outdated
|
|
||
| ## <a name="configFreeBSDDevices" />Devices | ||
|
|
||
| Devices in FreeBSD are accessed via the `devfs` filesystem. Typically, each container will have a `devfs` filesystem mounted into it's `/dev` directory. Often, a minimal set of devices is exposed to the container using ruleset 4 from `/etc/defaults/devfs.rules` - the ruleset is specified as a mount option. |
There was a problem hiding this comment.
Typically, each container will have a
devfsfilesystem mounted into it's/devdirectory.
What are the cases where they wouldn't? Does any of what's specified here no longer work in those cases? (Do we need a stronger requirement here, or is the status quo fine?)
There was a problem hiding this comment.
This seems fine to me.
devfs includes /dev/std{in,out,err} /dev/null and more, optionally /dev/pf for firewall (FreeBSD has a container-enabled virtualised network & firewall stack), and /dev/zfs filesystem functionality is exposed this way, etc.
@dfr s/it's/its/ though?
There was a problem hiding this comment.
Typically, each container will have a
devfsfilesystem mounted into it's/devdirectory.What are the cases where they wouldn't? Does any of what's specified here no longer work in those cases? (Do we need a stronger requirement here, or is the status quo fine?)
In theory, you could do without /dev for very simple workloads which don't need /dev/null, /dev/zero, good random numbers etc. but in practice, the suggested devfs ruleset for jails (look for ruleset 4 in /etc/defaults/devfs.conf on a FreeBSD host) is sufficient for most workloads. Container engines such as Podman, containerd etc. all add a /dev mount point using ruleset 4.
| "devices": [ | ||
| { | ||
| "path": "pf", | ||
| "mode": "0700" |
There was a problem hiding this comment.
I guess it has to be a string because JSON representation of an octal "0700" as a number would be 448 in decimalised JSON...
There was a problem hiding this comment.
This is a string which is interpreted as in chmod(1) which supports octal numeric modes as well as symbolic. I will fix the text to make this a little clearer.
| ] | ||
| ``` | ||
|
|
||
| ## <a name="configFreeBSDJail" />Jail |
There was a problem hiding this comment.
This section feels to me more like documentation for an existing implementation than specification from which a new compatible implementation could be implemented. 🤔
Are there specific features of FreeBSD that could be explicitly named here to help connect these things more strongly? Are there any places here where SHOULD or MUST language would be appropriate?
There was a problem hiding this comment.
This section is informational and is intended as a guide for readers familiar with FreeBSD jails to help them understand the mapping from the FreeBSD OCI config settings to the corresponding jail.
Since this proposal only covers the use of FreeBSD jails to implement OCI containers, there is very little freedom for implementors. The text following the table would benefit from using SHOULD/MUST language.
config-freebsd.md
Outdated
|
|
||
| ### Mapping from jail(8) config file | ||
|
|
||
| This table shows how to map settings from a typical `jail(8)` config file to the container configuration: |
There was a problem hiding this comment.
Is this advisory/suggestion, or prescriptive? (It currently reads as the former)
There was a problem hiding this comment.
Good point, I think we can say This tables defines the mappings from a typical here. Does that read better?
config-freebsd.md
Outdated
| | `allow.suser` | `freebsd.jail.allow.suser` | | ||
| | `allow.mount.*` | see below | | ||
|
|
||
| The jail name is set to the create command's `container-id` argument. |
There was a problem hiding this comment.
"is", SHOULD, or MUST? (Another place that feels like documentation, not spec)
There was a problem hiding this comment.
Unless there is another mechanism to (externally from the runtime) link jail name with container-id this should be MUST.
There was a problem hiding this comment.
for the whole table, I'm not sure. If any of these parameters are used, the mappy is prescriptive. Is that MUST or SHOULD?
There was a problem hiding this comment.
My current draft has SHOULD for the jail name - the use case is to facilitate higher-level software which needs to be able to access the jail, e.g. to monitor resource metrics. Perhaps MUST would be better here.
config-freebsd.md
Outdated
| Optionally, additional devices can be exposed to the container using an array of entries inside the `devices` root field: | ||
|
|
||
| * **`path`** _(string, REQUIRED)_ - the device path relative to `/dev` | ||
| * **`mode`** _(integer, OPTIONAL)_ - device permissions as an integer which is interpreted as in `chmod(1)`. |
There was a problem hiding this comment.
Yes.. should mode be annotated as string here?
What about:
"device permissions as an exact string representation of permissions expressed in octal, with leading "0" as in chmod(1), for example "0700".
Maybe more precise, but feels clumsy to me. Suggestions?
There was a problem hiding this comment.
I'm comfortable just referring to chmod(1) for definitive definitions. I'll try to make this link to the FreeBSD man page.
This uses FreeBSD jails to implement container isolation. Signed-off-by: Doug Rabson <[email protected]>
|
Fixed the type of FreeBSDDevice.Mode and fixed a typo in the json mapping for FreeBSDJail.SysVShm. |
This uses FreeBSD jails to implement container isolation.