Runc: What is CAP_AUDIT_READ?

[jadekler]

When using concourse which uses cf guardian which uses runc (holy cow), I get this cryptic error:

runc start: exit status 1: unknown capability "CAP_AUDIT_READ"

Any ideas what this means?

[marcosnils]

man capabilities

sent from mobile
On Jun 19, 2016 7:50 PM, "Jean de Klerk" [email protected] wrote:

When using concourse https://github.com/concourse which uses cf guardian
https://github.com/cloudfoundry-incubator/guardian which uses runc
(holy cow), I get this cryptic error:

runc start: exit status 1: unknown capability "CAP_AUDIT_READ"

Any ideas what this means?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/opencontainers/runc/issues/924, or mute the thread
https://github.com/notifications/unsubscribe/ABgV2m94OPeqzO_VTuLPno82nAOuyS6Yks5qNceYgaJpZM4I5RRE
.

[cyphar]

@jadekler man 7 capabilities. My man page says that capability was added in Linux 3.16 -- if you're using an older kernel then it won't be available for you.

[jadekler]

This is very strange. I get that error on a Ubuntu 14.04 LTS machine, which AFAIK uses linux kernel 4.2. Any ideas whats going on here?

The ubuntu machine is the stock EC2 AMI, btw.

edit - verified on the box, definitely not there:

ubuntu@ip-172-31-18-217:~$ man 7 capabilities | grep CAP_AUDIT_READ
ubuntu@ip-172-31-18-217:~$

[jadekler]

Possibly related bug. Seems it might be a libcap2 thing? So over my head right now haha.

[jadekler]

There does seem to be CAP_AUDIT_CONTROL and CAP_AUDIT_WRITE:

ubuntu@ip-172-31-18-217:~$ man capabilities | grep CAP_AUDIT -a2
       CAP_AUDIT_CONTROL (since Linux 2.6.11)
              Enable  and  disable  kernel auditing; change auditing filter rules; retrieve auditing
              status and filtering rules.

       CAP_AUDIT_WRITE (since Linux 2.6.11)
              Write records to kernel auditing log.

Are these sufficient? Would it be reasonable to remove CAP_AUDIT_READ as a requirement for runc?

[julz]

hi @jadekler fwiw I don't think this is a runc problem. Guardian has a static list of capabilities it asks runC to grant to privileged containers which includes CAP_AUDIT_READ. Runc is doing the right thing by exploding when it can't grant a capability guardian is requesting. We have a story in the public guardian tracker that should fix the problem, but feel free to open a separate issue in our github about this.

[jadekler]

Ah! You're completely right. Thanks @julz. I'll take this over to those guys.

[DenisIzmaylov]

I have the same problem. man 7 capabilities | grep CAP_AUDIT_READ is empty too.

[wking]

On Sun, Jun 26, 2016 at 03:13:05PM -0700, Denis Izmaylov wrote:

I have the same problem. man 7 capabilities | grep CAP_AUDIT_READ
is empty too.

Not having it in your local man pages just means you have old man
pages. It's in the current man pages 1 since man-pages v3.71 (2014)
2. Guardian asking runC to provide it [3,4] is independent of
whether it's listed in your man pages ;).

[cyphar]

@wking But your distribution should have up-to-date man pages (for your kernel). If your kernel is too old then it doesn't support that capability Checking your man pages is an easy way to check that.

[wking]

On Sun, Jun 26, 2016 at 09:05:27PM -0700, Aleksa Sarai wrote:

@wking But your distribution should have up-to-date man pages (for
your kernel).

My distribution doesn't manage my kernel (although it does manage my
headers, so it has at least a minimum version). It should be easy
enough to check the kernel directly. I'd guess something like:

$ zgrep CONFIG_MULTIUSER /proc/config.gz
CONFIG_MULTIUSER=y
$ uname -r
4.3.0

would do it (to see if the reported version is ≥ 3.16). Although I'm
not sure if new capabilities are backported to older stable kernels or
such.

[DenisIzmaylov]

May is it relevant? https://bugs.launchpad.net/ubuntu/+source/libcap2/+bug/1451601

[wking]

On Mon, Jun 27, 2016 at 04:27:43PM -0700, Denis Izmaylov wrote:

May is it related? https://bugs.launchpad.net/ubuntu/+source/libcap2/+bug/1451601

I don't think so. RunC uses gocapability 1, and they've defined
their own CAP_AUDIT_READ constant since syndtr/gocapability#3. So
libcap2 doesn't come into it for runC.

[DenisIzmaylov]

So what else can be happened?

It's just clean installation of Ubuntu 14.04.4 LTS with Concourse running in docker compose:

• https://github.com/MeteoGroup/concourse-ci

[wking]

On Mon, Jun 27, 2016 at 05:45:26PM -0700, Denis Izmaylov wrote:

It's just clean installation of Ubuntu 14.04.4 LTS…

It appears that 14.04.04 uses 4.2 kernels 1. 14.04 in general has
had a whole range of kernels 2. Can you ‘uname -r’ or ‘cat
/proc/sys/kernel/cap_last_cap’? libcontainer has supported
CAP_AUDIT_READ (when your kernel does) since 00abcf89 (Linux has added
a new capability audit_read, 2015-02-24, docker/libcontainer#383),
which predates runC.

[DenisIzmaylov]

@wking Yes! Of course:

$ uname -r
3.13.0-88-generic
$ cat /proc/sys/kernel/cap_last_cap
36
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="14.04.4 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.4 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"

The same values in the worker container.

[LK4D4]

So, concourse generates config with CAP_AUDIT_READ; it doesn't support by older kernels. I'm pretty sure that runc shouldn't make guesses about kernel in this case.

[wking]

On Tue, Jun 28, 2016 at 09:05:46AM -0700, Alexander Morozov wrote:

So, concourse generates config with CAP_AUDIT_READ; it doesn't
support by older kernels. I'm pretty sure that runc shouldn't make
guesses about kernel in this case.

I don't think runC is guessing about the kernel. It's saying the
capability is unknown, based on checking the kernel's
/proc/sys/kernel/cap_last_cap 1. The right fix (as @julz pointed
out 2), is to have Guardian not ask for that capability if it's
running on a host that doesn't support it (assuming that running
without that capability is the best old-kernel approximation for
whatever Guardian is trying to do).

[wking]

On Tue, Jun 28, 2016 at 08:13:52AM -0700, Denis Izmaylov wrote:

$ uname -r
3.13.0-88-generic
$ cat /proc/sys/kernel/cap_last_cap
36

This kernel is older than CAP_AUDIT_READ, which landed as capability
37 in 3.16 1.

[julz]

Concourse (and guardian) requires a 3.19+ kernel, so I think that explains this issue @wking.

[wking]

On Tue, Jun 28, 2016 at 09:58:35AM -0700, Julian Friedman wrote:

Concourse (and guardian) requires a 3.19+ kernel, so I think that
explains this issue @wking.

It may be worth checking for that an erroring out earlier, to avoid
confusion like this in the future ;).

[DenisIzmaylov]

So I've googled how to update kernel right and found some solution on askubuntu which has not been working. So then I found official solution and tried to update the kernel by:

sudo apt-get install --install-recommends linux-generic-lts-wily 

After reboot everything is working! Thank you very much! @LK4D4 @wking and especially @julz!

[jadekler]

Thanks for that note @DenisIzmaylov !

[vikas027]

Well, I am seeing this even in latest kernel

root@box66:~/concourse-tutorial/tutorials/basic/task-hello-world# fly -t tutorial execute -c task_hello_world.yml
executing build 5 at https://concourse.<my-domain>/builds/5
initializing
runc run: exit status 1: container_linux.go:348: starting container process caused "unknown capability \"CAP_AUDIT_READ\""

errored
root@box66:~/concourse-tutorial/tutorials/basic/task-hello-world# uname -r
4.16.3-1.el7.elrepo.x86_64
root@box66:~/concourse-tutorial/tutorials/basic/task-hello-world#

[walidshaari]

for RHEL it is raised as a bug and they seem to be working on backporting to the kernel 3.10 supplied

https://access.redhat.com/solutions/2834391

https://bugzilla.redhat.com/show_bug.cgi?id=1546155