Don't run docker image as root

[ibotty]

It would be great for security to let gitea run as non-root, preferably even with an auto-generated uid.
See https://docs.openshift.org/latest/creating_images/guidelines.html#openshift-origin-specific-guidelines

for a rationale and on how to achieve that.

The drawback is, that the container won't be able to bind to port 22.

I have an old gogs container (that is still running in production though) on
https://github.com/ibotty/openshift-gogs

[metalmatze]

If you start gitea and go through the install page it asks you what user you want to run with. git is the default user.

[ibotty]

The docker image is still run as root.

[tboerger]

And how do you chown the data volume for a new installation?

[ibotty]

You don't. You assume you can write in that dir. Why do you need to chown the data volume?

I think I don't understand what you mean, what problems you solve with explicit chmod.

[ibotty]

@lunny, how is that a question? For environments not allowing docker images to be run as root (e.g. openshift origin and also it's hosted variant) it's a showstopper.

[lunny]

@ibotty any label suggested?

[twang2218]

@ibotty I'm actually in the opposite position, I actually hope the gitea process can run as root, as I want gitea web can listen on port 80, which is quite important when using gitea with drone inside docker.

Currently, the gitea process is actually run as git user in Docker image.

# /etc/s6/gitea/run
#!/bin/bash
[[ -f ./setup ]] && source ./setup

pushd /app/gitea > /dev/null
    exec su-exec git /app/gitea/gitea web
popd

The ssh service will run as root, so it can listen at port 22 without problem.

[ibotty]

Docker can do port mappings without problems. Why enlarge your attack surface without any reason? Also, some environments just don't allow running docker containers as root.

[twang2218]

Docker can do port mapping for accessing from outside of the docker network, not inside the docker network.

In the case of running gitea and drone inside the docker, the drone container will try to connect the gitea via docker internal network. The port mapping is not working here.

Say, we have a gitea running at port 3000:

[server]
APP_DATA_PATH    = /data/gitea
SSH_DOMAIN       = dev.lab99.org
HTTP_PORT        = 3000
ROOT_URL         = http://dev.lab99.org/
DISABLE_SSH      = false
SSH_PORT         = 2222
LFS_START_SERVER = false
OFFLINE_MODE     = false

And we DO port mapping -p 80:3000 on the docker, so people can visit the server via http://dev.lab99.org/, no problem. However, when linking drone, things getting some tricky here.

drone container can be configured as:

    drone-server:
        image: drone/drone:0.5
        ports:
            - "8000:8000"
        depends_on: [ database ]
        environment:
            DRONE_OPEN: 'false'
            DRONE_GOGS: 'true'
            DRONE_GOGS_URL: http://gitea:3000

The drone can access gitea API, as we told drone to connect http://gitea:3000, however, during the CI execution, the drone will try to clone from http://dev.lab99.org/myuser/project/..., as the ROOT_URL in the gitea settings are point to http://dev.lab99.org/, so it's gitea told drone access me via http://dev.lab99.org/xxxx.

I can set an alias and let drone resolve dev.lab99.org's IP to gitea's IP address, so the DNS is not the problem.

The problem is that the port of http://dev.lab99.org/ is 80, and my gitea container is listening on port 3000, and if drone try to clone from http://dev.lab99.org/ it will fail, as no one is listening at port 80 there.

Running process as root inside a container is not that dangerous, because it's not like real root on the host, the capabilities has been dropped, and the root in the container might even mapping to a normal user in the host if --userns-remap is enabled, so the real UID might not be 0 on the host.

However, I understand minimizing the trusted domain is always the best practise for security. So, I'm thinking a way can make all of us happy. Such as using CAP_NET_BIND_SERVICE, I will test for that.

[lunny]

@twang2218 For docker, run as git let's we has git@xxxx.com SSH address but not root@xxxx.com.

[tboerger]

We are using openSSH with the standard port, so it won't be possible to run Gitea without the root user.

[twang2218]

Let's try CAP_NET_BIND_SERVICE, I tried setcap CAP_NET_BIND_SERVICE=+ep on /app/gitea/gitea, #2183, and it can bind port below 1024 now, even it's still run as git. I will try it on SSH as well later.

[sapk]

@twang2218 for your specific problem it must be that dev.lab99.org point to internal ip inside your container. If you point it to the public ip where docker publish you shouldn't have any problem.