Skip to content

Conversation

@cpuguy83
Copy link
Member

@cpuguy83 cpuguy83 commented Jan 14, 2022

This makes our compiled version of runc work on rhel7 and other releases
with older versions of libseccomp.

Fixes #6209 #6091

This makes our compiled version of runc work on rhel7 and other releases
with older versions of libseccomp.

Signed-off-by: Brian Goff <[email protected]>
@theopenlab-ci
Copy link

theopenlab-ci bot commented Jan 14, 2022

Build succeeded.

Copy link
Member

@AkihiroSuda AkihiroSuda left a comment

Choose a reason for hiding this comment

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

Can we just statically compile runc with the latest libseccomp?

Copy link
Member

@mikebrow mikebrow left a comment

Choose a reason for hiding this comment

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

I get that this is in a container, just pointing out that downgrading seccomp will break systemd in ubuntu 20.

FYI: for local development only running make install-deps builds/installs:
https://github.com/containerd/containerd/blob/main/script/setup/install-seccomp#L25

Noting at least one reason runc moved up:
opencontainers/runc#2682

if we are going to continue distributing runc then we may have to consider building versions for specific distros, or at least document which ones this runc is for.

@cpuguy83
Copy link
Member Author

I would say I am ultimately not a fan of statically compiling runc due to libseccomp being a fairly important and potential security risk and we never update our release tarballs.
That said, statically compiling it would fix the issue in question.
I have seen some other issues like statically compiled runc segfaulting on raspbian.

@mikebrow 😭

@cpuguy83
Copy link
Member Author

I will say, this change unbreaks the current builds and should likely be backported and we can decide to target libseccomp 2.5 for >= 1.6

@crosbymichael
Copy link
Member

What do we use this runc for? we don't distribute it as part of our release.

@cpuguy83
Copy link
Member Author

It's in the cri bundles.

@AkihiroSuda
Copy link
Member

I'd still prefer to use the latest libseccomp so that we can have the latest syscall table, which is hardcoded in libseccomp
https://github.com/seccomp/libseccomp/blob/main/src/syscalls.csv

@crosbymichael
Copy link
Member

Yes, we should stay with the latest seccomp like @AkihiroSuda said and the real fix is that we don't public runc, it shouldn't be our responsibility to do this or it is something we want to maintain as a project.

@cpuguy83
Copy link
Member Author

cpuguy83 commented Feb 3, 2022

Consensus seems to be we would prefer to use the latest seccomp, and also that it's best that people use distro builds to begin with.
There is also the statically compiled runc from the opencontainers/runc repo.

@cpuguy83 cpuguy83 closed this Feb 3, 2022
@relyt0925
Copy link

It still isn't clear to me what is the path forward here: Right now the instructions in containerd for installing are wrong then:
Are we saying we are going to produce new tar balls that do not have runc in them? And then in the case of rhel 7 we would install runc out of band?

@AkihiroSuda
Copy link
Member

Are we saying we are going to produce new tar balls that do not have runc in them?

No, at least until vNextNext (v1.7? v2.0?).

And then in the case of rhel 7 we would install runc out of band?

Yes. We will have to update the docs.

@AkihiroSuda
Copy link
Member

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

RHEL 7 installation regression on 1.5.7: runc: symbol lookup error: runc: undefined symbol: seccomp_api_get

5 participants