crun currently allows to specify an empty mapping for [r]idmap, and to
default to the mappings specified for the container user namespace.
Change the specifications to allow such behavior.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Support for kernel-memory limits was deprecated in the kernel, and documented
as "NOT RECOMMENDED" (or "SHOULD NOT" use) in v1.1.0-rc.1 through commit
f02cd4a427.
This patch marks the field as deprecated in the go implementation of the
spec, so that linters and editors produces a warning and consumers get
notified of its status.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Hooks.Prestart was deprecated in c1662686cf
(v1.0.2), but the field did not have a correctly formatted deprecation comment.
This patch updates the field's GoDoc to have a correctly formatted deprecation
comment, which will allow linters and IDEs to detect the deprecation status
of this feature.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Current documentation talks about bind/rbind and various propagation
flags (shared, slave, private, unbindable etc.) as being filesystem-
specific options, and refers to mount(8) section describing
filesystem-specific options.
That is wrong, because bind mounts are a separate class of mounts,
not related to file systems.
Fix the confusion, and link to sharedsubtree.txt kernel document
as it happens to be the best source of information about the topic
(not counting the kernel sources).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
We tried to make runc enforce abs dest path several times, and always
had to revert it due to some tools not yet doing it. The last occurrence
is this one:
https://github.com/opencontainers/runc/issues/3944#issuecomment-1669261383
I don't see any reason to force abs dst paths on Linux, as far as I know
there is no security bug nor anything. Let's just relax the spec
wording, matching all the runtimes behavior when the paths is relative,
and be done with it.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
High level container runtimes sometimes need to know if the OCI runtime
supports idmap mounts or not, as the OCI runtime silently ignores
unknown fields.
This means that if it doesn't support idmap mounts, a container with
userns will be started, without idmap mounts, and the files created on
the volumes will have a "garbage" owner/group. Furthermore, as the
userns mapping is not guaranteed to be stable over time, it will be
completely unusable.
Let's expose idmap support in the features subcommand, so high level
container runtimes use the feature safely.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
The idmapped mounts sections do not make any reference to how the
mapping should be implemented. Add a reference to MOUNT_ATTR_IDMAP since
that is what runtimes are expected to use.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Adding new fields for MOUNT_ATTR_IDMAP had the flaw that users
specifying these fields with older runtimes would result in the fields
being ignored and incorrect mounts being configured. In addition, there
is no text in the specification indicating whether MOUNT_ATTR_IDMAP
should be applied with AT_RECURSIVE (which matters for rbind idmapped
mounts).
In retrospect, the addition of the fields should've included new (dummy)
mount options that would cause errors on older runtimes. Unfortunately,
we have had a runtime-spec release since then so we cannot MUST these
new mount options, but we can SHOULD them.
Fixes: 9d1130dc3b ("IDMapping field for mount point")
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
The "annotations" property in features.md is not expected to
enumerate the possible values of the "annotation" property in config.md.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
