Support: podman-compose rootless setup leads to `PUID=0` being passed, and ArchiveBox refuses to start as root

[sodamouse]

Support: podman-compose rootless setup leads to `PUID=0` being passed, and ArchiveBox refuses to start as root

[sodamouse]

Hi, the issue is that this setup is not managed by me. It's managed by a provider, so unfortunately i can't provide you info beyond guesswork. All I can say is that I am not adding PUID=$(id -u) myself, and that I believe podman is indeed being run inside docker.

[pirate]

You have these flags -e PUID=0 -e PGID=0 above in the podman command you shared (which supersede any values set in docker-compose.yml).

Can you try again without those flags?

[sodamouse]

You have these flags -e PUID=0 -e PGID=0 above in the podman command you shared (which supersede any values set in docker-compose.yml).

Can you try again without those flags?

I'm not the one who is inserting those. That command is what is generated when I run docker-compose up.

[pirate]

Whatever is generating that command is your culprit, it's not controlled by archivebox and is definitely not what's run by standard docker compose up.

I haven't used podman much, but it looks like it could probably be a podman thing modifying the default docker compose setup?

[sodamouse]

It's possible but i don't have any control over it. Podman is rootless, so anything that get executed is not actually being run as root, but having PUID=0 in the container throws off archivebox i suppose.

[pirate]

ArchiveBox always tries to drop down to a non-privileged user, as we don't allow running it as root for security reasons. There's just too many 3rd-party dependencies used and too much shell execution->downloading->parsing RCE escalation risk to allow running extractors as root, even inside a container.

If you pass PUID=0 it will refuse to run because that's not a non-privileged user.

If you pass a valid, non-root PUID (ideally >500, lower UIDs may behave strangely), it will set the archivebox user use that uid and drop down to that user to run the archiving processes.

https://github.com/ArchiveBox/ArchiveBox/wiki/Security-Overview#do-not-run-as-root

[sodamouse]

You reasoning is sound and i understand it, however this makes the docker solution unusable in my environment. I will look into how to disable this check.

This is what's happening -> docker invokes podman, podman runs everything in a rootless environment (where the user has the PUID=0, but has no actual system-level root access). This trips up the check in archivebox.

Anyways, this is only a "bug" in so far as PUID=0 doesn't always mean root. If it's out of scope, please close this ticket.

[pirate]

As a workaround you can use docker exec instead of docker run / modify the entry point to not run ./bin/docker_entrypoint.sh (which is where the PUID/PGID enforcement checks live).

You'll need to add --user=archivebox to any docker run commands manually or do something like this in docker-compose.yml to make sure ArchiveBox still runs as a non-root user:

services:
    archivebox:
        ...
        entrypoint: /bin/bash
        user: archivebox

[pirate]

I can't find any reference to PUID/PGID tampering in the podman-compose codebase, are you adding this part yourself PUID=$(id -u) anywhere?

https://github.com/search?q=repo%3Acontainers%2Fpodman-compose+puid&type=code

This is what's happening -> docker invokes podman, podman runs everything in a rootless environment (where the user has the PUID=0, but has no actual system-level root access

But how are the explicit 3331 values you put in docker-compose.yml getting replaced with $(id -u), what part of the stack would make such a bold change to a user-provided config value?

PUID/PGID are just a convention started by linuxserver.io, they're not even part of any real OCI/Docker spec that would imply they're safe to tamper with at the hypervisor/orchestrator level. It would be very surprising to learn either Docker or Podman have hardcoded in behavior that forcibly edits these env vars.

Also not sure I understand how Docker ends up triggering podman commands, are you running podman inside docker? If so I'd love to learn more about your experiences doing that, because I might be interested in packaging parts of ArchiveBox as podman sub-containers within a main all-batteries-included container (to avoid needing Kubernetes as we grow).

---

I'm going to close this for now since it's not really a problem with ArchiveBox per-se, but I do love devops spelunking and I am still curious, so if you're willing to share more about your setup I'd be happy to keep investigating and help find a solution in the comments here.