mirror of
https://github.com/ArchiveBox/ArchiveBox.git
synced 2026-04-26 01:26:00 +03:00
[GH-ISSUE #1379] Support: podman-compose rootless setup leads to PUID=0 being passed, and ArchiveBox refuses to start as root #2351
Labels
No labels
expected: maybe someday
expected: next release
expected: release after next
expected: unlikely unless contributed
good first ticket
help wanted
pull-request
scope: all users
scope: windows users
size: easy
size: hard
size: medium
size: medium
status: backlog
status: blocked
status: done
status: idea-phase
status: needs followup
status: wip
status: wontfix
touches: API/CLI/Spec
touches: configuration
touches: data/schema/architecture
touches: dependencies/packaging
touches: docs
touches: js
touches: views/replayers/html/css
why: correctness
why: functionality
why: performance
why: security
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ArchiveBox#2351
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @sodamouse on GitHub (Mar 13, 2024).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/1379
Describe the bug
When using the default docker-compose.yml file with docker-compose or podman-compose (rootless), the environment variables for PUID and GUID are not honored and installation exits complaining about being run as root.
Steps to reproduce
Screenshots or log output
compose file:
error:
ArchiveBox version
@pirate commented on GitHub (Mar 14, 2024):
You have these flags
-e PUID=0 -e PGID=0above in the podman command you shared (which supersede any values set indocker-compose.yml).Can you try again without those flags?
@sodamouse commented on GitHub (Mar 14, 2024):
I'm not the one who is inserting those. That command is what is generated when I run docker-compose up.
@pirate commented on GitHub (Mar 14, 2024):
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 commented on GitHub (Mar 14, 2024):
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 commented on GitHub (Mar 14, 2024):
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=0it 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 thearchiveboxuser 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 commented on GitHub (Mar 16, 2024):
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 commented on GitHub (Mar 17, 2024):
As a workaround you can use
docker execinstead ofdocker run/ modify the entry point to not run./bin/docker_entrypoint.sh(which is where thePUID/PGIDenforcement checks live).You'll need to add
--user=archiveboxto anydocker runcommands manually or do something like this indocker-compose.ymlto make sure ArchiveBox still runs as a non-root user:@pirate commented on GitHub (Mar 21, 2024):
I can't find any reference to
PUID/PGIDtampering in thepodman-composecodebase, are you adding this part yourselfPUID=$(id -u)anywhere?https://github.com/search?q=repo%3Acontainers%2Fpodman-compose+puid&type=code
But how are the explicit
3331values you put indocker-compose.ymlgetting replaced with$(id -u), what part of the stack would make such a bold change to a user-provided config value?PUID/PGIDare 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.
@sodamouse commented on GitHub (Mar 21, 2024):
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.