© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
513534c
demo site
(Get the code!)
[Availability]
runc is in universe (https:/
amd64, arm64, armhf, i386, ppc64el and s390x.
[Rationale]
This package is a requirement for the containerd MIR (bug-to-be-filed). Both packages
are necessary for OCF (Open Container Format) support, from the OCI (Open Containers Initiative, https:/
[Security]
runc has currently 3 CVEs:
http://
runc through 1.0-rc6, as used in Docker before 18.09.2 and other products,
allows attackers to overwrite the host runc binary (and consequently obtain
host root access) by leveraging the ability to execute a command as root within
one of these types of containers: (1) a new container with an
attacker-controlled image, or (2) an existing container, to which the attacker
previously had write access, that can be attached with docker exec. This occurs
because of file-descriptor mishandling, related to /proc/self/exe.
http://
RunC allowed additional container processes via 'runc exec' to be ptraced by
the pid 1 of the container. This allows the main processes of the container, if
running as root, to gain access to file-descriptors of these new processes
during the initialization and can lead to container escapes or modification of
runC state before the process is fully placed inside the container.
http://
libcontainer/
1.11.2, improperly treats a numeric UID as a potential username, which allows
local users to gain privileges via a numeric username in the password file in a
container.
There are no suid/sgid binaries, and all executables are in /usr/sbin.
There are no services or daemons in this packages (sysv, upstart or systemd).
There are no open privileged or otherwise ports.
It is used by container software like docker.
[Quality assurance]
After installing the package it must be possible to make it working with a
reasonable effort of configuration and documentation reading.
- the upstream site (https:/
tutorial that boils down to this, and it works:
# create the top most bundle directory
mkdir /mycontainer
cd /mycontainer
# create the rootfs directory
mkdir rootfs
# export busybox via Docker into the rootfs directory
docker export $(docker create busybox) | tar -C rootfs -xvf -
# create a default config.json file
runc spec
# run it (no changes to config.json necessary)
runc run mycontainerid
/ # id
uid=0(root) gid=0(root)
/ # ps
PID USER TIME COMMAND
1 root 0:00 sh
7 root 0:00 ps
The package must not ask debconf questions higher than medium if it is going to
be installed by default. The debconf questions must have reasonable defaults.
- no debconf questions
There are no long-term outstanding bugs which affect the usability of the
program to a major degree. To support a package, we must be reasonably
convinced that upstream supports and cares for the package.
- there are currently no open bugs in Ubuntu:
https:/
- open bugs in debian:
- https:/
failed without criu" Depending on how important the "checkpoint" feature
is, we might have to pull in criu via a Recommends or Depends, and criu
will require its own MIR. criu might be a problem because it seems to be
python2, and has other deps that will need a MIR of its own. For now, we
could add criu as a suggests.
- https:/
CVE-2019-5736
- upstream bugs: https:/
open, 399 closed)
- upstream pull requests: https:/
(currently 70 open, 1364 closed)
The package is maintained well in Debian/Ubuntu (check out the Debian PTS)
- debian pts for runc: https:/
- package is scheduled for removal by March 27th, 2019, because of
CVE-2019-5736 (bug #922050) That being said, there is a new package in the
queue which fixes that bug already (1.0.0~
- the package has DEP8 tests
- many uploads per year
The package should not deal with exotic hardware which we cannot support.
- no exotic hardware involved
If the package ships a test suite, and there is no obvious reason why it cannot
work during build (e. g. it needs root privileges or network access), it should
be run during package build, and a failing test suite should fail the build.
- tests are run at package build time. Example run, search for "dh_auto_test":
https:/
- the package also has DEP8 tests
The package uses a debian/watch file whenever possible. In cases where this is
not possible (e. g. native packages), the package should either provide a
debian/
clear instructions on how to generate the source tar file.
- there is a debian/watch file and it uses https
It is often useful to run lintian --pedantic on the package to spot the most
common packaging issues in advance
- these are the lintian issues in runc-1.
$ lintian --pedantic -I --show-overrides
P: runc source: package-
I: runc source: out-of-
I: runc source: unused-override source-
W: golang-
W: runc: manpage-
W: runc: manpage-
W: runc: manpage-
W: runc: manpage-
W: runc: binary-
I: runc: unused-override spelling-
- the runc binary package ships one lintian override:
runc: spelling-
The missing manpage for recvtty could be created somewhat easily via the recvtty --help output,
which looks very much like a manpage already.
The package should not rely on obsolete or about to be demoted packages. That
currently includes package dependencies on Python2 (without providing Python3
packages), and packages depending on GTK2.
- the package has many golang build dependencies that come from Universe. The
MIR team currently seems to have an understanding
(https:/
to a case-by-case analysis to avoid populating main with too many packages
like this.
- the package gets extended funcionality if criu
(https:/
installed. There is a Debian bug requesting that criu is added as a
Recommends. That would trigger another MIR in Ubuntu, and in the meantime we
could add that package as a Suggests. The funcionality that is added by that
package is snapshots of containers.
- there are no python{2,3} or GTK2 dependencies
- there is a build-depends on protobuf-compiler, but that doesn't seem to
introduce runtime dependencies related to that.
[UI standards] (generally only for user-facing applications)
- there is no internationaliz
case for runc is to be consumed/used by other tools, instead of directly.
Unless one wants to get to the lower level where runc is used, maybe for
troubleshooting.
[Dependencies]
- currently all dependencies, including Recommends, are in mind, with the note
about golang packages from Universe that are pulled in during build and
linked with statically. There is a Debian bug asking to add criu as a
Recommends, already mentioned earlier, and that would break this check.
Either we MIR criu, or add it as a suggests for the time being.
[Standards compliance]
The package should meet the FHS and Debian Policy standards. Major violations
should be documented and justified. Also, the source packaging should be
reasonably easy to understand and maintain.
- FHS compliance looks fine. The package ships just 34 files: manpages are at
the proper location, so are binaries and /usr/share/doc files.
- debian policy is a bit less than one year old: ships with 4.1.4 (released
2018-04-05), current one is 4.3.0
- I didn't spot major violations of the policy. I didn't check d/copyright to
see if it's up-to-date
[Maintenance]
All packages must have a designated "owning" team, regardless of complexity,
which is set as a package bug contact.
- at some point, the Ubuntu Server manager should comment on the bug accepting
maintenance of this package
The runc tool by itself has simple usage, but is used by more complex packages like
docker, containerd and others.
[Background information]
None at this time.