Mount docker.sock #6015
Comments
openshift-ci-robot
added
the
kind/bug
|
This should be expected, right? Podman doesn't run a daemon like docker does, so there's no docker.sock to mount (unless you're also running docker in parallel on the same host?). |
|
Yes I have docker running on the host as I cannot complete replace it with podman as some of the projects I'm building with Jenklins do require to access docker through APIs (i.e. testcontainers that uses the docker-java library under the hood) |
|
Gotcha. Can you add the output of |
|
pod: host: |
|
Note that my user is part of the |
|
It seems like this might be that the bind-mounted socket isn't being put into the user namespace for your container (since "root" / uid 0 in the podman pod is not the same as "root" on the outside). |
|
We automatically drop supplemental groups when entering rootless containers for security reasons, which is why your access to the |
|
If you are using the That may allow you to access the Docker socket, but I will strongly emphasize that you remove any and all security benefits of rootless Podman by mounting a root-owned Docker socket into it (this will enable trivial privesc from the container onto the host). |
|
So I think it won't be too different from running Jenkins directly on the host |
|
SELinux will block this access also. giving a process access to the docker.sock is the most dangerous thing you can do. You should really run in --privileged mode if you are going to do this, so people would understand that the container has root root access on your system and no confinement. Have you looked into using buildah to build while running inside of a container? |
I know but what other options do we have ? i.e. is there an docker api emulation layer that uses podman under the hoods ?
here it is not about build container but to spawn container as part of the test process of some libraries. |
There is (
You'll likely need to disable SELinux confinement for the container ( |
|
@mheon is it possible to run what I'm thinking is to create a pod in which I have one container that runs jenkins and another one that runs |
|
@rhatdan I know we have Podman-in-Podman working for root containers, but what about rootless ones? |
|
Theoretically this would work for rootless containers, but might be difficult to setup. To get full functionality you need to run the initial container as --privileged, most likely. |
|
before trying to run podman system service in a container I gave it a try running it on my host against something that emulate what a pipeline would do. So what I did is:
The step 3. works without any issue so I'm able to see the mongo:40 image by using docker or podman: The running my demo code I see the following error: |
|
Is Alpine ever explicitly pulled? |
|
No, the java code references only mongo:4.0 |
|
That last InternalServerException seems to indicate it was looking for alpine, but the errors further in the stack do seem to indicate mongo:4.0. Any chance you can add |
|
Here you have: |
|
can you provide the json that is embedded as part of the body on the create call? |
|
I'm trying to get it but in the meantime I found out that the library does also try to download alpine:3.5 as part of the process bootstrap |
|
This is the entire "conversation": |
|
when using docker the flow is the following one: |
|
My understanding is that the call is not properly handled by podman as it does not apply the given filter |
|
A friendly reminder that this issue had no activity for 30 days. |
|
@lburgazzoli Is this still an issue, I believe this is fixed in the current release. At this point I am not sure what this issue is covering? |
|
Possibly fixed by #6878 (currently merged only to the master branch) |
|
Closing as I believe this is fixed. |
|
Sorry to necro this ticket, but this seems like the most relevant discussion I've seen.
Is I'm looking to be able to run https://github.com/nginx-proxy/nginx-proxy with I think it would involve a systemd service which invokes something like |
|
No there is nothing safe about giving a container access to the docker.socket on the Host Period. https://danwalsh.livejournal.com/78373.html? I believe access to the docker.socket with docker running as root or Podman.socket with Podman runing as root are two of the most dangerous things you can do on a Linux system. Worse then giving a process SUDO without root. |
|
Thank you for putting it clearly, and those links are very helpful. They both touch on where I was going with my second question, "I'm looking to be able to run https://github.com/nginx-proxy/nginx-proxy with podman. Shouldn't it be possible to do this in a safe way?"
and in the second
I was trying to figure out how safe this is with docker, and whether the severe danger comes only when using podman. Given the above, I have an question in addition to that—is read-only access just as dangerous? If not it seems that should be all that is needed, no? Forgive me for ignorance if that doesn't make sense, I am not very familiar with SELinux or podman (yet). |
|
With Podman you could potentially -volume /var/lib/containers:/var/lib/containers:ro, and be able to do listing of containers. podman run --security-opt label=disable -v /var/lib/containers:/var/lib/containers:ro quay.io/podman/stable podman ps -aError: error opening database /var/lib/containers/storage/libpod/bolt_state.db: open /var/lib/containers/storage/libpod/bolt_state.db: read-only file system Looks like we would need to do more work, to make this possible. |
|
@flouthoc WDYT Where is the upper layer of the overlay mounted? Should we move this to a tmpfs /dev/shm? |
|
@giuseppe WDYT? |
|
Why
Thank you, this is hopefully what many of us need. Should I file a new ticket or would you like to since you have a better grasp on the needs/scope/limitation? |
|
Yes create an issue asking for read/only access to container storage. I think there is potential to give you this with overlay mounts |
This is a loop we already create overlay in storage. The reason is to make easier to maintain and common cleanup for all the overlays. I think we could add a |
I did my best, thanks for all the guidance and explanations |
|
I would be fine with that, But we would be limiting the size of the overlay. |
now we can specify |
github-actions
bot
added
the
locked - please file new issue/PR
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
I'm switch a jenkins installation from running with docker to podman and one of the requisite is to be able to access the docker daemon on the host to run containerized builds but mounting the docker socket does not seem to work as expected with podman:
Steps to reproduce the issue:
Run the onesysadmin/jenkins-docker-executors with docker and check docker:
Run the onesysadmin/jenkins-docker-executors with podman and check docker:
Output of
podman version:Output of
podman info --debug:Package info (e.g. output of
rpm -q podmanorapt list podman):The text was updated successfully, but these errors were encountered: