Skip to content

Bump runc binary v1.0.0-rc93#41994

Merged
thaJeztah merged 1 commit intomoby:masterfrom
thaJeztah:bump_runc_binary
Feb 12, 2021
Merged

Bump runc binary v1.0.0-rc93#41994
thaJeztah merged 1 commit intomoby:masterfrom
thaJeztah:bump_runc_binary

Conversation

@thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented Feb 6, 2021

update runc binary to v1.0.0-rc93

full diff: opencontainers/runc@v1.0.0-rc92...v1.0.0-rc93
release notes: https://github.com/opencontainers/runc/releases/tag/v1.0.0-rc93

Release notes for runc v1.0.0-rc93

This is the last feature-rich RC release and we are in a feature-freeze until
1.0. 1.0.0~rc94 will be released in a few weeks with minimal bug fixes only,
and 1.0.0 will be released soon afterwards.

  • runc's cgroupv2 support is no longer considered experimental. It is now
    believed to be fully ready for production deployments. In addition, runc's
    cgroup code has been improved:

    • The systemd cgroup driver has been improved to be more resilient and
      handle more systemd properties correctly.
    • We now make use of openat2(2) when possible to improve the security of
      cgroup operations (in future runc will be wholesale ported to libpathrs to
      get this protection in all codepaths).
  • runc's mountinfo parsing code has been reworked significantly, making
    container startup times significantly faster and less wasteful in general.

  • runc now has special handling for seccomp profiles to avoid making new
    syscalls unusable for glibc. This is done by installing a custom prefix to
    all seccomp filters which returns -ENOSYS for syscalls that are newer than
    any syscall in the profile (meaning they have a larger syscall number).

    This should not cause any regressions (because previously users would simply
    get -EPERM rather than -ENOSYS, and the rule applied above is the most
    conservative rule possible) but please report any regressions you find as a
    result of this change -- in particular, programs which have special fallback
    code that is only run in the case of -EPERM.

  • runc now supports the following new runtime-spec features:

    • The umask of a container can now be specified.
    • The new Linux 5.9 capabilities (CAP_PERFMON, CAP_BPF, and
      CAP_CHECKPOINT_RESTORE) are now supported.
    • The "unified" cgroup configuration option, which allows users to explicitly
      specify the limits based on the cgroup file names rather than abstracting
      them through OCI configuration. This is currently limited in scope to
      cgroupv2.
  • Various rootless containers improvements:

    • runc will no longer cause conflicts if a user specifies a custom device
      which conflicts with a user-configured device -- the user device takes
      precedence.
    • runc no longer panics if /sys/fs/cgroup is missing in rootless mode.
  • runc --root is now always treated as local to the current working directory.

  • The --no-pivot-root hardening was improved to handle nested mounts properly
    (please note that we still strongly recommend that users do not use
    --no-pivot-root -- it is still an insecure option).

  • A large number of code cleanliness and other various cleanups, including
    fairly large changes to our tests and CI to make them all run more
    efficiently.

For packagers the following changes have been made which will have impact on
your packaging of runc:

  • The "selinux" and "apparmor" buildtags have been removed, and now all runc
    builds will have SELinux and AppArmor support enabled. Note that "seccomp"
    is still optional (though we very highly recommend you enable it).
  • make install DESTDIR= now functions correctly.

Revert "Temporarily disable CAP_PERFMON, CAP_BPF, and CAP_CHECKPOINT_RESTORE"

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

Comment on lines 26 to 28
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One possible alternative could be to only exclude these from CAP_ALL, but still allow users to manually set them; in that case --privileged would "work" (but not really have "all" capabilities), and users that have an up-to-date runc can manually specify these caps (which would fail on older runc versions)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should wait for containerd/containerd#5017 and use the function from containerd. Otherwise Docker21-in-Docker20 won't work.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually was thinking of creating a PR to move the go capabilities package (with git history) to github.com/opencontainers/runtime-spec), so that both containerd, moby, and runc (possibly cri-o) can use of the same package WDYT?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean moving https://github.com/syndtr/gocapability to the runtime-spec repo? I think that should be discussed with the author of the package. Anyway, I'm not sure the runtime-spec repo can contain non-spec codes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

think that should be discussed with the author of the package

For sure.

Anyway, I'm not sure the runtime-spec repo can contain non-spec codes.

Ah, yes, I thought there were some utility functions in the repo, but looks like there aren't.

The constants themselves could perhaps make sense, similar to SCMP_ARCH arches are defined there. idk. Basically, I think it'd be good if there was a central place for code like this (could also still be in the https://github.com/syndtr/gocapability repository)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussing in the maintainers meeting; let's split this one into two separate PRs, and start with just updating runc

@thaJeztah
Copy link
Member Author

Scenarios to test;

  • use CAP_ALL against older runc?
  • use CAP_ALL in a container with not all capabilites?

@thaJeztah
Copy link
Member Author

/cc @tiborvass

full diff: opencontainers/runc@v1.0.0-rc92...v1.0.0-rc93
release notes: https://github.com/opencontainers/runc/releases/tag/v1.0.0-rc93

Release notes for runc v1.0.0-rc93
-------------------------------------------------

This is the last feature-rich RC release and we are in a feature-freeze until
1.0. 1.0.0~rc94 will be released in a few weeks with minimal bug fixes only,
and 1.0.0 will be released soon afterwards.

- runc's cgroupv2 support is no longer considered experimental. It is now
  believed to be fully ready for production deployments. In addition, runc's
  cgroup code has been improved:
    - The systemd cgroup driver has been improved to be more resilient and
      handle more systemd properties correctly.
    - We now make use of openat2(2) when possible to improve the security of
      cgroup operations (in future runc will be wholesale ported to libpathrs to
      get this protection in all codepaths).
- runc's mountinfo parsing code has been reworked significantly, making
  container startup times significantly faster and less wasteful in general.
- runc now has special handling for seccomp profiles to avoid making new
  syscalls unusable for glibc. This is done by installing a custom prefix to
  all seccomp filters which returns -ENOSYS for syscalls that are newer than
  any syscall in the profile (meaning they have a larger syscall number).

  This should not cause any regressions (because previously users would simply
  get -EPERM rather than -ENOSYS, and the rule applied above is the most
  conservative rule possible) but please report any regressions you find as a
  result of this change -- in particular, programs which have special fallback
  code that is only run in the case of -EPERM.
- runc now supports the following new runtime-spec features:
    - The umask of a container can now be specified.
    - The new Linux 5.9 capabilities (CAP_PERFMON, CAP_BPF, and
      CAP_CHECKPOINT_RESTORE) are now supported.
    - The "unified" cgroup configuration option, which allows users to explicitly
      specify the limits based on the cgroup file names rather than abstracting
      them through OCI configuration. This is currently limited in scope to
      cgroupv2.
- Various rootless containers improvements:
    - runc will no longer cause conflicts if a user specifies a custom device
      which conflicts with a user-configured device -- the user device takes
      precedence.
    - runc no longer panics if /sys/fs/cgroup is missing in rootless mode.
- runc --root is now always treated as local to the current working directory.
- The --no-pivot-root hardening was improved to handle nested mounts properly
  (please note that we still strongly recommend that users do not use
  --no-pivot-root -- it is still an insecure option).
- A large number of code cleanliness and other various cleanups, including
  fairly large changes to our tests and CI to make them all run more
  efficiently.

For packagers the following changes have been made which will have impact on
your packaging of runc:

- The "selinux" and "apparmor" buildtags have been removed, and now all runc
  builds will have SELinux and AppArmor support enabled. Note that "seccomp"
  is still optional (though we very highly recommend you enable it).
- make install DESTDIR= now functions correctly.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah thaJeztah changed the title Bump runc binary v1.0.0-rc93, re-enable CAP_PERFMON, CAP_BPF, and CAP_CHECKPOINT_RESTORE Bump runc binary v1.0.0-rc93 Feb 11, 2021
@thaJeztah thaJeztah added this to the 21.xx milestone Feb 11, 2021
@thaJeztah
Copy link
Member Author

@tiborvass updated; removed the second commit (moved to #42011)

@thaJeztah
Copy link
Member Author

s390x failure is unrelated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants