8000 Broken permissions on rootless docker install · Issue #29568 · go-gitea/gitea · GitHub
[go: up one dir, main page]

Skip to content

Broken permissions on rootless docker install #29568

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

Open
danncasey opened this issue Mar 3, 2024 · 6 comments
Open

Broken permissions on rootless docker install #29568

danncasey opened this issue Mar 3, 2024 · 6 comments
Labels

Comments

@danncasey
Copy link

Description

I am having trouble getting the rootless docker install to work. I have a specific user that i need to run gitea as. However it is seemingly not possible.

My environment:
Ubuntu 22.04 lxc guest running on Proxmox with NFS storage.
UID mappings for storage are working as expected.
Username: git
Host UID & GID: 102001
Guest UID & GID: 2001

Everything below is from the guest pov.

git@git-01:/nfs/data0/docker$ dpkg -l |grep docker
ii  docker-compose                1.29.2-1                                all          define and run multi-container Docker applications with YAML
ii  docker.io                     24.0.5-0ubuntu1~22.04.1                 amd64        Linux container runtime
ii  python3-docker                5.0.3-1                                 all          Python 3 wrapper to access docker.io's control socket
ii  python3-dockerpty             0.4.1-2                                 all          Pseudo-tty handler for docker Python client (Python 3.x)

/nfs/data0/docker is mounted and owned by git (2001:2001)

root@git-01:/nfs/data0/docker# su git
git@git-01:/nfs/data0/docker$ id
uid=2001(git) gid=2001(git) groups=2001(git),118(docker)

git@git-01:/nfs/data0/docker$ ls -l | grep git
drwxr-xr-x 3 git    git       4096 Mar  3 23:01 gitea

git@git-01:/nfs/data0/docker$ ls -ln | grep git
drwxr-xr-x 3  2001  2001   4096 Mar  3 23:01 gitea

Setup

# still as git user
cd /nfs/data0/docker/gitea
mkdir -p volume/{data,etc}
cat > docker-compose.yml <<EOF
version: "3"

networks:
  gitea:
    external: false

services:
  server:
    image: gitea/gitea:1.21.7-rootless
    container_name: gitea
    environment:
      - SSH_USER=git
      - USER_UID=2001
      - USER_GID=2001
    restart: unless-stopped
    networks:
      - gitea
    volumes:
      - ./volume/data:/data
      - ./volume/etc:/etc/gitea
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "80:3000"
      - "2222:22"
EOF

docker-compose up -d
docker logs -f gitea
Recreating eaffe357adfc_gitea ... done
/etc/gitea is not writable
docker setup failed
chmod: /etc/gitea: Operation not permitted
/etc/gitea is not writable
docker setup failed
chmod: /etc/gitea: Operation not permitted

Ive tried numerous ways to get this working. They all result in either the data & config not persisting to disk, or failed attempts to mkdir or chown paths. I have tried creating the paths manually before starting. in some cases it gets a little further but still lands on another permission error.

That said, within the docker container, the git user (2001) "can" create,modify, and remove any thing on its mount point(s). root (0) cannot do this. Is there a way to force this to do everything as git?

Gitea Version

1.21.7-rootless

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

N/A

Operating System

Ubuntu 22.02 LXC guest on Proxmox 8.0.3/Debian 12 host

How are you running Gitea?

Docker compose: image: gitea/gitea:1.21.7-rootless
Details in main post

Database

None

@lenderom
Copy link
lenderom commented Mar 4, 2024

I have an similar issue with 1.21.7 . At first I thought I broke my setup, but after hours of trying I used 1.21.6 and everything worked again.
For me gitea hat issues accessing the files with the default setup (USER: git, UID: 1000, GID: 1000) and when I tried a non standard user it complained that it can't run as root (despite the user was non root user).

@BarbarianTarkus
Copy link
BarbarianTarkus commented Apr 10, 2024

Same here:

Running docker compose up with user 1001
docker-compose.yml

services:
  gitea:
    image: gitea/gitea:1.21.6-rootless
    container_name: gitea
    restart: always
    user: "1001:1001"
    network_mode: services
    volumes:
      - ./data:/var/lib/gitea
      - ./config:/etc/gitea
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3002:3000"
      - "2222:22"

Error logs:

$ docker compose up
gitea  | docker setup failed
gitea  | chmod: /var/lib/gitea/git: Operation not permitted
gitea  | /var/lib/gitea/git is not writable

Dir Permissions output

$ ls -lan 
total 20
drwxrwxr-x  4 1001 1001 4096 abr 10 13:08 .
drwxrwxr-x  3 1001 1001 4096 abr 10 12:56 ..
drwxrwxr-x  2 1001 1001 4096 abr 10 12:35 config
drwxrwxr-x 16 1001 1001 4096 abr 10 12:25 data
-rwxr-xr-x  1 1001 1001  392 abr 10 13:04 docker-compose.yml

I'm currently on ARM64:

$ uname -a
Linux orangepi 5.10.160-rockchip #34 SMP Thu Mar 21 16:59:26 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux

$ docker --version
Docker version 26.0.0, build 2ae903e

$ docker compose version
Docker Compose version v2.25.0

@blark
Copy link
blark commented May 11, 2024

I'm having the same issue, using NFS, rootless. Have 10 other containers working fine with this setup and using the same NFS server.

@nirui
Copy link
nirui commented Apr 16, 2025
/etc/gitea is not writable
docker setup failed
chmod: /etc/gitea: Operation not permitted

I guess it took sometime for dudes to learn that an non-root process should not be modifying anything beyond their own home directory, including system stuff under /etc which stores static data/configuration. And BTW, service processes should have their dynamic data stored under /var.

Currently, given how the offending script was written, you maybe able to get around the checking code by providing your own app.ini and specify the GITEA_APP_INI environment variable.

Simply put, you first generate a app.ini on your local machine and store it under ./volume/etc/conf, and then modify the docker-compose.yml that you provided above to something like:

  version: "3"

  networks:
    gitea:
      external: false

  services:
    server:
      image: gitea/gitea:1.21.7-rootless
      container_name: gitea
      environment:
        - SSH_USER=git
        - USER_UID=2001
        - USER_GID=2001
+       - GITEA_APP_INI=/etc/gitea/conf/app.ini
      restart: unless-stopped
      networks:
        - gitea
      volumes:
        - ./volume/data:/data
-       - ./volume/etc:/etc/gitea
+       - ./volume/etc:/etc/gitea:ro
        - /etc/timezone:/etc/timezone:ro
        - /etc/localtime:/etc/localtime:ro
      ports:
        - "80:3000"
        - "2222:22"

This might escape the check, allowing the container to spin up successfully. HOWEVER, all of this was, as I said, a escape, not a root fix. The correct fix should be not writing to /etc/gitea in the first place.

Hope it helped :)

@dresch86
Copy link
dresch86 commented May 4, 2025

I have the exact same problem however the suggestion by @nirui did not work for me. I am also using named volumes for storing the data.

Edit:
I also think it is worth mentioning the Docker implementation, rootless or not, is totally out of whack. If the container is running as root, the gitea process shouldn't be run as git inside the container. I have app.ini on the host and bind mounted inside the container. Root can access it, but git can't. If I chmod 644, sure it works, but the world on the host should not be allowed to access a file with passwords in it!

I'm using podman so I intend to run rootless. Running rootless presents the exact issue above. I think the Docker implementation needs a total rewrite for running securely, if at all.

@nirui
Copy link
nirui commented May 17, 2025

Not sure what went wrong in your case @dresch86. The key is to get around the if [ ! -f ${GITEA_APP_INI} ]; then check defined in the docker-setup.sh file by providing your own valid app.ini to that path, so the follow up check if [ ! -w ${GITEA_APP_INI_DIR} ]; then echo "${GITEA_APP_INI_DIR} is not writable"; exit 1; fi, which is what causes the error, never triggers.

I do agreed that the rootless Docker images for Gitea is really messed up, and desire some major rework.

In addition to that, I really don't understand why Gitea allows both the user and the program itself to modify it's config file (app.ini). It's really confusing for the user and maybe for the program too.

A good rule of thumb is that static setting (db, directory etc) should be user modifiable only, and dynamic setting (site title, themes etc) should be modified through the software.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants
0