-
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
Images that use gosu
don't work in my rootless environment
#6816
Comments
With podman 2.0 redis works fine for me
|
Both
Worked fine on Fedora 32.
|
Yesterday I tried one of your semanage incantations from a different issue @rhatdan , since I noticed that the SELinux labels on my graphroot seemed wrong (a lot of Any tips on what I might be able to do to debug further on my machine? It's been a nagging issue and my alternative is to blow away my laptop and see if a fresh install ends up being happier. |
What AVCs are you seeing? |
Looks like none, which is a bit surprising. I've got a few more observations which might be relevant:
More info on the path to now:
So it's obviously some bizarre user misconfiguration on my main account which I can't spot. I think my plan will be to just pivot to a new account and steal my homedir back. I'll keep the original account in case there's anything else you think I can check out. |
Well this was certainly a fun adventure. It turns out this is all due to my use of extended ACLs to restrict permissions in my home dircetory. Essentially, I mask everything with I just had to |
Worked for me. Thanks! |
Ok..so this worked for me as well...but I don't really understand this
|
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
A while ago, I had some issues with a container image I was sending changes to which the maintainer wasn't able to repro on his machine. We were both running rootless podman, but I would consistently get EPERM errors when starting the container. At the time I was on Fedora 31. I was able to mostly work around the issue with bizarre combinations of
--cap-add=DAC_OVERRIDE
and edits to the entrypoint (which I can't find anymore ): )Today, I pulled down the redis and rabbitmq docker images and hit similar seeming issues. When I dug into it, it appears that their use of
gosu
to setuid/setgid to an unprivileged user in the container is being denied by something. I figured it might be selinux denying some transition, but there don't appear to be any denied entries in myaudit.log
. Adding the SETUID and SETGID caps don't help either (in fact adding ALL doesn't help).My understanding is that docker containers sometimes not working isn't unknown, but most of the issues are documented as being related to cgroups2 and manifest differently. This feels like something seccomp-y or selinuxy is getting in the way.
Steps to reproduce the issue:
podman run -t redis:debug
-> should work normally nowpodman run -ti --user redis --cap-add=DAC_OVERRIDE redis
also works but this trick doesn't work for rabbitmqDescribe the results you received:
Unmodified redis image fails to run
Describe the results you expected:
It would be nice if these containers Just Worked (TM)
Additional information you deem important (e.g. issue happens only occasionally):
SELinux labels on my
${GRAPHROOT}/storage/
Trying to run rabbitmq with
--user
:Output of
podman version
:Using my distro podman at the moment:
Output of
podman info --debug
:Package info (e.g. output of
rpm -q podman
orapt list podman
):Additional environment details (AWS, VirtualBox, physical, etc.):
Physical host
The text was updated successfully, but these errors were encountered: