Skip to content
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

Permission denied on mkdir /rundir/libpod during startup #5414

Closed
stanosamek opened this issue Sep 23, 2021 · 6 comments · Fixed by #5430
Closed

Permission denied on mkdir /rundir/libpod during startup #5414

stanosamek opened this issue Sep 23, 2021 · 6 comments · Fixed by #5430
Labels
bug Something isn't working

Comments

@stanosamek
Copy link

We are running Collector on Openshift container platform (version 4.7). This platform is running containers on podman with some specific security context. This security context are using automatically generating uid for containers.

We are trying to use Collector in version 0.36.0. Problem is that in Dockerfile is specific userId which is not correct way from security perspective.

So, during startup, Collector isn't able to start because of error time="2021-09-23T09:04:32Z" level=error msg="mkdir /rundir/libpod: permission denied"

@stanosamek stanosamek added the bug Something isn't working label Sep 23, 2021
@owais
Copy link
Contributor

owais commented Sep 23, 2021

Thanks for reporting this. Moving away from the podman library (#5244) should solve such issues permanently.

@stanosamek
Copy link
Author

Do you know when can be this fixed?

@owais
Copy link
Contributor

owais commented Sep 23, 2021

I think it'll take time to implement a solution for #5244

We can try to figure out a temporary solution for now. Could you share the security context you are using in OpenShift so we can test it locally?

Could you please also share all of the log messages from the collector before it crashes?

Does this only happen when you enable the podman receiver or does it always crash?

If it only happens when podman reciever is enabled, perhaps we can handle these errors and not start actual podman monitoring without crashing the collector as a temporary measure.

Another possibility is that we can move the creation of tmp and rundir directories to runtime by providing an entrypoint script that provisions the environment and then starts the collector. This would allow the container to use a UID specified at runtime instead of a hard coded one. Do you think this would solve the issue?

@stanosamek
Copy link
Author

Of course. I'm using nonroot security context. Below is description of that security context.

Name: nonroot
Priority:
Access:
Users: system:serviceaccount:opentelemetry:otel-collector
Groups:
Settings:
Allow Privileged: false
Allow Privilege Escalation: true
Default Add Capabilities:
Required Drop Capabilities: KILL,MKNOD,SETUID,SETGID
Allowed Capabilities:
Allowed Seccomp Profiles:
Allowed Volume Types: configMap,downwardAPI,emptyDir,persistentVolumeClaim,projected,secret
Allowed Flexvolumes:
Allowed Unsafe Sysctls:
Forbidden Sysctls:
Allow Host Network: false
Allow Host Ports: false
Allow Host PID: false
Allow Host IPC: false
Read Only Root Filesystem: false
Run As User Strategy: MustRunAsNonRoot
UID:
UID Range Min:
UID Range Max:
SELinux Context Strategy: MustRunAs
User:
Role:
Type:
Level:
FSGroup Strategy: RunAsAny
Ranges:
Supplemental Groups Strategy: RunAsAny
Ranges:

Collector always crash during startup because of problem to make dir in rundir. As you wrote, moving creation of environment by script in entrypoint could resolve this issue but it will be great to test it.

@owais
Copy link
Contributor

owais commented Sep 24, 2021

@stanosamek do you have a way to test if this change solves the problem: #5430

@stanosamek
Copy link
Author

@owais Yes, no problem

bogdandrutu pushed a commit that referenced this issue Sep 27, 2021
podmanreceiver uses the official Go podman bindings but the bindings
pull in all of the podman codebase and it's dependencies. We are
essentially embedding podman into the collector. This causes a number of
problems both at compile and run time.

This commit ditches the podman library and uses net/http to consume the
podman v3 REST API instead.

Fixes #5244
Fixes #5414
Fixes #5241
Fixes #5245
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants