7 ms·

Rootless podman is my first choice for using containers now, it works fantastically well in my experience. It's so much nicer to have all my container related

Rootless podman is my first choice for using containers now, it works fantastically well in my experience. It's so much nicer to have all my container related stuff like volumes, configs, the control socket, etc. in my home directory and standard user paths vs. scattered all over the system. Permission issues with bind mounts just totally disappear when you go rootless. It's so much easier and better than the root privileged daemon. I really wish rootless podman/docker was the default install now. It's still kind of annoying to setup with reading a smattering of old docs and having to think about your distro setup, cgroups settings, etc. It really should just be a "run this install script and you're done".

pkulak 4y ago
The arch wiki is my go to every time I install Podman, and it’s a little easier every time. It’s down to like two steps now, with no file editing. We’ll get there.
sureglymop 4y ago
What about UID issues? I remember using it years ago and sometimes having permission issues in containers when mounting local files. How is that nowadays? I much prefer running this in a rootless manner also. What about docker compose? Is there an alternative for podman?
- stingraycharles 4y ago
  There’s podman-compose which does what you want, but is a community maintained script. There’s also the ability for podman to run as a system service, and provide an OCI compatible container API. This then integrates seamlessly with the actual docker-compose. See: https://www.redhat.com/sysadmin/podman-docker-compose https://www.redhat.com/sysadmin/podman-docker-compose
  - znpy 4y ago
    You can point the official docker-compose at podman now! I do that! It's 99.999% compatible as the podman people basicaly reimplemented all the docker daemon APIs. It sometimes lags a bit behind, because sometime docker implements new stuff... But for usage with docker-compose it has worked flawlessly for me. EDIT: you can also export the podman unix socket via socat, i also tried it to run a rootless docker runtime in kubernetes (podman daemon running as a pod, to run docker builds in kubernetes) as an experiment. It works but i'd love to see a better integration with Gitlab runner project. Gitlab is supposedly getting podman support any time soon, in 15.1 IIRC ?
    - sureglymop 4y ago
      Wow that sounds amazing! Thanks for the information.
    - lolcat_cowsay 4y ago
      I tried podman compose quite a few months ago with my docker compose file and it failed, what is the difference between doing that and this? So like, you can use docker compose for podman instead of docker, instead of something like podman compose?
      - znpy 4y ago
        The difference is that instead of using podman-compose you use the actual docker-compose. You have to point your $DOCKER_HOST to the podman unix socket or something, but other than that it’s the actual docker-compose experience. Via the env var trick you could even use the actual docker binary. But you could just alias docker to podman and it works the same, by design!
- qbasic_forever 4y ago
  Yeah in my experience with rootless you don't need to worry about UID shenanigans anymore. Containers can do stuff as root (from their perspective at least) all they want but any files you bind mount into the container are still just owned/modified by your user account on the host system (not a root user bleeding through from the container).
  - capableweb 4y ago
    How does that work in practice? Podman is changing the permission bits of files that are synced between the host and the container? If I create a file with certain permission bits in the container, I'd expect the file to be 100% identical when pulling it over to the host, but maybe that's just "legacy" thinking coming from my docker experience? What about copying files directly between containers, would that change the permissions as well?
    - coldtea 4y ago
      >If I create a file with certain permission bits in the container, I'd expect the file to be 100% identical when pulling it over to the host The permission bits are metadata on the fs, the file can still be identical. Plus, how permissions on a file on the container be identical in the host, if e.g. the groups/users are different?
    - lapser 4y ago
      The permissions (rwx) don't change, but the uid/gid is mapped. E.g. uid 0 is the running user outside the container, by uid 1 will be mapped to 100000 (configurable), and say 5000 inside the container is mapped to 105000. I don't remember the exact mapping but it works roughly like that.
      - sureglymop 4y ago
        Oh, that sounds great! Thank you, that was the information i wanted.
- lolcat_cowsay 4y ago
  Nah no good alternative yet, I tried running my docker compose file which works perfectly with docker in podman compose and it failed outright.
the8472 4y ago
The problem with rootless is that you don't get a native network stack since setting up bridges and veth devices still requires some elevated capabilities. But instead of running full root this could be outsourced to a helper executable with some caps set (a narrower version of suid). > Permission issues with bind mounts just totally disappear when you go rootless. Recent kernel versions have gained uid mapping capabilities on mounts. Hopefully future docker will make use of it. Then we can run entire containers as different users.
- phoronixrly 4y ago
  TBH I don't want to expose the native network stack to containers
  - the8472 4y ago
    If your concern is kernel attack surface then I have bad news for you. Inside the container's network namespace it's still using standard syscalls. Only on the host side it takes a detour through userspace. So you get all the downsides, none of the native performance and very few upsides. It only benefits firewalls that still assume a machine has a single network interface without bridging/natting/forwarding.
johnchristopher 4y ago
> Permission issues with bind mounts just totally disappear when you go rootless. I have a problem with mounting a named foo in a container (at /foo) and bindfsing the underlying directory of that volume on ${HOME}/foo with create-for parameters so that when the host user touch files in it they are owned by host 1000:1000 but inside the container it's owned by 33:33. Volume foo really contains only a unix socket. This unix socket is shared between the host and the container for xdebug communication. So, this doesn't work, the container process can't write/read the socket even though it can manipulate other files in the mounted volumes /foo and they appear as owned by 1000:1000 on the host and vice versa. But if I mount the volume directly like that: ${HOME}/foo:/foo then it works and the container can write to the socket and the host and the container can communicate both ways. Would rootless podman allow me to use a named volume ? Why doesn't it work like I think it should, is it because the unix socket lives in the kernel 'or something' ? Maybe it's a question for SO.
- krageon 4y ago
  It probably is a question for SO, where it would be best described with a script that sets up the minimum environment required to reproduce and the situation that you want to achieve. This description doesn't quite get me to an understanding of the problem, but that may be a personal issue.
- dhzhzjsbevs 4y ago
  Change the ids of the user inside the container to match what's needed on the host or take a look at subuid's.
  - johnchristopher 4y ago
    > Change the ids of the user inside the container to match what's needed on the host or take a look at subuid's. Oh, I tried running the process in the container under a different uid but it complained about unprivileged user. Going the other way may do it, thanks. Although it requires more fiddling with stock images.
teekert 4y ago
Are you saying that all files from your containers are owned by you as user? If so I will start investigating right now. It is so super annoying to download something with nzbget for example and then having to go through sudo to get to your downloaded files. It is indeed my major gripe with my docker compose setup atm. Or just messing with a html file in the nginx docker bind mount, ugh! If podman solves that I’m going all in tomorrow.
- lapser 4y ago
  Root inside the container is the same as your user.
  - RyEgswuCsn 4y ago
    No it’s not. File written from inside the container into a mounted volume as root will be owned by root outside the container (uid 0, to be specific; doesn’t matter what the user is named). Edit: I might have misunderstood parent, who might be referring to Podman attempting to manage the uid mapping.
    - weitzj 4y ago
      Last thing I remember you can tweak your /etc/setuid, setgid to properly map between the user inside the container and outside
    - gnfurlong 4y ago
      The parent comment is still talking about rootless podman (and really just user namespaces). Root in the container is absolutely mapped to the user executing podman outside the container. If it mapped to root outside the container, you could just use podman to create setuid scripts owned by root for very trivial privelege escalation.
      - RyEgswuCsn 4y ago
        Yes I think you are right --- I was mistaken. Docker without the rootless operate in the way I described.
forty 4y ago
If you are on Linux, there is the fantastic podman option "--userns keep-id" which will make sure the uid inside the container is the same as your current user uid.
solarkraft 4y ago
I don't know. When I tried it I got a lot of networking issues with components even the existence of which was barely documented online.

pkulak 4y ago

The arch wiki is my go to every time I install Podman, and it’s a little easier every time. It’s down to like two steps now, with no file editing. We’ll get there.

sureglymop 4y ago

What about UID issues? I remember using it years ago and sometimes having permission issues in containers when mounting local files. How is that nowadays? I much prefer running this in a rootless manner also. What about docker compose? Is there an alternative for podman?

stingraycharles 4y ago
There’s podman-compose which does what you want, but is a community maintained script. There’s also the ability for podman to run as a system service, and provide an OCI compatible container API. This then integrates seamlessly with the actual docker-compose. See: https://www.redhat.com/sysadmin/podman-docker-compose https://www.redhat.com/sysadmin/podman-docker-compose
- znpy 4y ago
  You can point the official docker-compose at podman now! I do that! It's 99.999% compatible as the podman people basicaly reimplemented all the docker daemon APIs. It sometimes lags a bit behind, because sometime docker implements new stuff... But for usage with docker-compose it has worked flawlessly for me. EDIT: you can also export the podman unix socket via socat, i also tried it to run a rootless docker runtime in kubernetes (podman daemon running as a pod, to run docker builds in kubernetes) as an experiment. It works but i'd love to see a better integration with Gitlab runner project. Gitlab is supposedly getting podman support any time soon, in 15.1 IIRC ?
  - sureglymop 4y ago
    Wow that sounds amazing! Thanks for the information.
  - lolcat_cowsay 4y ago
    I tried podman compose quite a few months ago with my docker compose file and it failed, what is the difference between doing that and this? So like, you can use docker compose for podman instead of docker, instead of something like podman compose?
    - znpy 4y ago
      The difference is that instead of using podman-compose you use the actual docker-compose. You have to point your $DOCKER_HOST to the podman unix socket or something, but other than that it’s the actual docker-compose experience. Via the env var trick you could even use the actual docker binary. But you could just alias docker to podman and it works the same, by design!
qbasic_forever 4y ago
Yeah in my experience with rootless you don't need to worry about UID shenanigans anymore. Containers can do stuff as root (from their perspective at least) all they want but any files you bind mount into the container are still just owned/modified by your user account on the host system (not a root user bleeding through from the container).
- capableweb 4y ago
  How does that work in practice? Podman is changing the permission bits of files that are synced between the host and the container? If I create a file with certain permission bits in the container, I'd expect the file to be 100% identical when pulling it over to the host, but maybe that's just "legacy" thinking coming from my docker experience? What about copying files directly between containers, would that change the permissions as well?
  - coldtea 4y ago
    >If I create a file with certain permission bits in the container, I'd expect the file to be 100% identical when pulling it over to the host The permission bits are metadata on the fs, the file can still be identical. Plus, how permissions on a file on the container be identical in the host, if e.g. the groups/users are different?
  - lapser 4y ago
    The permissions (rwx) don't change, but the uid/gid is mapped. E.g. uid 0 is the running user outside the container, by uid 1 will be mapped to 100000 (configurable), and say 5000 inside the container is mapped to 105000. I don't remember the exact mapping but it works roughly like that.
    - sureglymop 4y ago
      Oh, that sounds great! Thank you, that was the information i wanted.
lolcat_cowsay 4y ago
Nah no good alternative yet, I tried running my docker compose file which works perfectly with docker in podman compose and it failed outright.

the8472 4y ago

The problem with rootless is that you don't get a native network stack since setting up bridges and veth devices still requires some elevated capabilities. But instead of running full root this could be outsourced to a helper executable with some caps set (a narrower version of suid). > Permission issues with bind mounts just totally disappear when you go rootless. Recent kernel versions have gained uid mapping capabilities on mounts. Hopefully future docker will make use of it. Then we can run entire containers as different users.

phoronixrly 4y ago
TBH I don't want to expose the native network stack to containers
- the8472 4y ago
  If your concern is kernel attack surface then I have bad news for you. Inside the container's network namespace it's still using standard syscalls. Only on the host side it takes a detour through userspace. So you get all the downsides, none of the native performance and very few upsides. It only benefits firewalls that still assume a machine has a single network interface without bridging/natting/forwarding.

johnchristopher 4y ago

> Permission issues with bind mounts just totally disappear when you go rootless. I have a problem with mounting a named foo in a container (at /foo) and bindfsing the underlying directory of that volume on ${HOME}/foo with create-for parameters so that when the host user touch files in it they are owned by host 1000:1000 but inside the container it's owned by 33:33. Volume foo really contains only a unix socket. This unix socket is shared between the host and the container for xdebug communication. So, this doesn't work, the container process can't write/read the socket even though it can manipulate other files in the mounted volumes /foo and they appear as owned by 1000:1000 on the host and vice versa. But if I mount the volume directly like that: ${HOME}/foo:/foo then it works and the container can write to the socket and the host and the container can communicate both ways. Would rootless podman allow me to use a named volume ? Why doesn't it work like I think it should, is it because the unix socket lives in the kernel 'or something' ? Maybe it's a question for SO.

krageon 4y ago
It probably is a question for SO, where it would be best described with a script that sets up the minimum environment required to reproduce and the situation that you want to achieve. This description doesn't quite get me to an understanding of the problem, but that may be a personal issue.
dhzhzjsbevs 4y ago
Change the ids of the user inside the container to match what's needed on the host or take a look at subuid's.
- johnchristopher 4y ago
  > Change the ids of the user inside the container to match what's needed on the host or take a look at subuid's. Oh, I tried running the process in the container under a different uid but it complained about unprivileged user. Going the other way may do it, thanks. Although it requires more fiddling with stock images.

teekert 4y ago

Are you saying that all files from your containers are owned by you as user? If so I will start investigating right now. It is so super annoying to download something with nzbget for example and then having to go through sudo to get to your downloaded files. It is indeed my major gripe with my docker compose setup atm. Or just messing with a html file in the nginx docker bind mount, ugh! If podman solves that I’m going all in tomorrow.

lapser 4y ago
Root inside the container is the same as your user.
- RyEgswuCsn 4y ago
  No it’s not. File written from inside the container into a mounted volume as root will be owned by root outside the container (uid 0, to be specific; doesn’t matter what the user is named). Edit: I might have misunderstood parent, who might be referring to Podman attempting to manage the uid mapping.
  - weitzj 4y ago
    Last thing I remember you can tweak your /etc/setuid, setgid to properly map between the user inside the container and outside
  - gnfurlong 4y ago
    The parent comment is still talking about rootless podman (and really just user namespaces). Root in the container is absolutely mapped to the user executing podman outside the container. If it mapped to root outside the container, you could just use podman to create setuid scripts owned by root for very trivial privelege escalation.
    - RyEgswuCsn 4y ago
      Yes I think you are right --- I was mistaken. Docker without the rootless operate in the way I described.

forty 4y ago

If you are on Linux, there is the fantastic podman option "--userns keep-id" which will make sure the uid inside the container is the same as your current user uid.

solarkraft 4y ago

I don't know. When I tried it I got a lot of networking issues with components even the existence of which was barely documented online.