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.

[twang2218]

Yes, the dev.lab9.org point to the internal IP, as both gitea and drone are on the same docker internal network, and they should only communicate with each other through the internal network.

[sapk]

If gitea is publicly accessible, you should use your public ip from drone also or use a proxy.

[twang2218]

Why? as I said before, both gitea and drone are running on the SAME docker internal network, the shouldn't communicate via public IP and go through all the NAT/routing stuff, which is neither efficient nor necessary. They should communicate directly.

[moritzheiber]

Sidetracking a little here .. but the only service expecting Gitea to run on port 80 is Drone? Why can't it access Gitea on another port?

I'd have to agree with @sapk on this one, running any service on a power lower than 1024 and thus requiring other capabilities is not considered best practice.

I'd even go as far as to say that Drone should be accessing Gitea the same way any other client does (probably a HTTPS enabled endpoint?).

[sapk]

If you want but that not a problem with docker but with gitea that will use ROOT_URL for displaying links wich is public in your case. One of the good solution could be to allow an internal ROOT_URL.

[twang2218]

Don't forget we already given ssh process running as root, which is much worse than given gitea a limited capability. If we so concern of the security capability here, we should run ssh, syslog and s6 as a normal user with specific capability as well, just like what I proposed for gitea process, given a specific process a limited capability, rather than run it as root.

About the drone, of course, I hope drone can fetch the data through port 3000, however, as I said, because the ROOT_URL is the url for external users, and the address after port mapping, and this is the address gitea told drone where to pull. So, drone will only access gitea through port 80, rather than port 3000.

[sapk]

@twang2218 For process running as root, I totally agree with you on that and that is the main problem on this issue. We could use internal ssh (listening on non-priviliged port) in place of openssh alongside.

[pittar]

@twang2218 We use OpenShift with the default security settings. There's no way our security team will let us downgrade security to run Gitea. I guess it's Gogs or Gitlab for us.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[sapk]

We should keep this opened.

[alexanderadam]

I'm a bit confused: is the rootless image still planned? I see #4749 is closed?

Are the improvements needed for internal SSH server tracked somewhere?

[sapk]

@alexanderadam still a wip but I reopen it #7129

[BastiOfBerlin]

I agree with those who say that we need to run as non-root user. It looks like there is no other light-weight git server out there that can be run in an OpenShift cluster (except for the trivial built-in mechanics). Thus, making gitea able to fill this vacuum would make it the number one choice if gitlab is not wanted for its complexity.

This issue is open for more than three years now. Any chance that this will happen soon?

[livelace]

2020 and things are still the same. init is overcomplicated, root user :(

[sapk]

Fixed by #10154