-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rootless: can't install httpd into a Fedora container because of capabilities #5364
Comments
Adding the needed capability seems to work. I was fighting with the same for iputils. Not sure if this is the correct way to do it. buildah bud --cap-add="CAP_SETFCAP" . |
A friendly reminder that this issue had no activity for 30 days. |
So ping then. This is pretty serious, we should be able to install packages |
@rhatdan Does this sound like expected behavior? I don't think this is fuse-overlay related, since adding the capability fixes this. |
Well, I tried again today, and it works again. With the following list of packages
I don't know, perhaps it was fixed. Or it is not always reproducible. |
The default list of capabilities to run containers is: AUDIT_WRITE,CHOWN,DAC_OVERRIDE,FOWNER,FSETID,KILL,MKNOD,NET_BIND_SERVICE,NET_RAW,SETFCAP,SETGID,SETPCAP,SETUID,SYS_CHROOT So the buildah container should havv SETFCAP by default. No idea why this is working and then not working. |
I don't believe this issue still exists. Closing, reopen if I am mistaken. |
I can not reopen this, but the problem regressed back, freshly after upgrade to Fedora 33:
|
I mean, there's no "reopen" button in this issue. Perhaps I should fill a new one? |
Thanks! @rhatdan is on it :) |
FTR, I also removed all containers/images, and then did |
I'm not sure it is related, but when I built the image with the mentioned work-around
|
I'm seeing that in several issues right now - I believe it all traces back to some attempts to prune default capabilities by @rhatdan |
Yes if you remove /usr/share/containers/containers.conf it should be fixed. We are attempting to run containers tighter security in Fedora 33. |
Hm, from package installation POV, I don't think we can live without setcap. And it would be a pity
Removing the default config helps. |
This is a problem for us when trying to move Fedora CoreOS to Fedora 33. This is a simple reproducer:
Ends up with:
Those packages are a part of https://bodhi.fedoraproject.org/updates/FEDORA-2020-7b6058fec9 |
Probably rpm (and other systems) should be patched to not try to set file caps if the process doesn't have the capability. |
That said I also kind of question the value of dropping this. File caps are still bounded by user namespaces. I could imagine there is some kernel bug that this could mitigate but it seems unlikely to me. |
Building skopeo 1.2.1-2 which adds in CAP_SETFCAP. |
Thanks @rhatdan - I just tested with skopeo-1.2.0-2.fc33 and that seemed to work great. Can you add that build to the update: https://bodhi.fedoraproject.org/updates/FEDORA-2020-7b6058fec9 |
I think @lsm5 is taking care of this. |
THis is now fixed. |
This happens again on Fedora 34:
Build fails on:
I'm curious if we could install some test case for this somewhere, e.g. to Fedoa CI? |
Now with:
|
|
Please open a new issue on this. On Buildah. I have no idea if this is the same issue as before. |
I do not think that the new | ... cpio: cap_set_file failed - Inappropriate ioctl for device error is capability related. It sounds like a problem with setting these xattr on the overlay filesystem. Does fuse-overlayfs supports them? Perhaps it worked before because rpm ignored these errors when capabilities are missing. Now, capabilities are given and the operation itself fails. |
grep SETFCAP /usr/share/containers/containers.conf |
FYI: containers/buildah#3071 (comment) - try updating your kernel and see if that helps. |
With this dockerfile:
I run
buildah bud .
, and I see:Output of
podman version
:Output of
podman info --debug
:Package info (e.g. output of
rpm -q podman
orapt list podman
):The text was updated successfully, but these errors were encountered: