I use the "gogs" self-hosted git service, but I want to change to a more active fork called gitea. The installation instructions say I should create a user (e.g. git) dedicated for use by gitea:

adduser \
  --system \
  --shell /bin/bash \
  --gecos 'Git Version Control' \
  --group \
  --disabled-password \
  --home /home/git \

I currently use gogs in windows, without a special user. Now I want to use gitea in linux, hence my confusion - I assume it's because I might not understand daemons in general.

In windows, when I want to start the service, I run it, and it stays open either in a terminal window or as a background service, until I stop it. In linux I can do the same, so why do I need a dedicated user?

I assume the same practice is used for other services as well, so I need to understand the implications of using / not using a dedicated user for a service.

(I guess this is related to running a service without a user logging on and starting it. But lots of other services are already running and they do not need dedicated users, do they?)


Your confusion stems from the fact that you do not understand what you are doing on Windows. On Windows, actual services are run from the Service Control Manager, and they have had the ability to run under the aegides of dedicated user accounts all along. A proper unprivileged service on Windows employs the username of a dedicated unprivileged user account, which the SCM logs in as in order to create the service process.

What you are doing, in contrast, is not running a service at all. You are running a program in your interactive logon session, in the background. And it isn't a terminal that you are using, it is a console.

The reasons for employing dedicated accounts for services are in fact common to Windows and Linux operating systems. Running services as separate processes under the aegides of dedicated accounts means that the operating system mechanisms that protect users from one another (Windows NT and Linux both being multi-user from the ground up, remember) also protect the service processes from you, an interactive user, and from other services. They likewise protect you and those other services from the service.

The multi-user mechanisms allow find grained access control on files and directories that the service program uses, prevent the services from being sent arbitrary signals by malicious processes, prevent the service processes from being traced using the debug APIs, prevent thread injection, and prevent arbitrary processes from being able to pause and resume threads. And all of these preventions work the other way, too, meaning that the service, should it be compromised, cannot do these things to others.

You are running a service that responds to requests across the network. It is designed to run under the aegis of a dedicated user account for these very reasons. It speaks a complex human-readable protocol that is non-trivial for programs to parse correctly, and could potentially be compromised if there were an error somewhere in that parser. But any attacker that succeeds in compromising it only gains access to your system as that dedicated service user, which you should have ensured has no unnecessary access to, or ownership of, files and directories that are not part of its intended function.

I myself extend this to the logging as well. Individual log services run with only the privileges necessary to access and write to their specific log directories, and are insulated from one another, from interactive users, and even from the (unprivileged) "main" services whose logs they are writing.

In a well-architected system, there should be scant few service processes that run with privileged access. Generally, they will be things that provide some sort of multi-user login, such as SSH or FTP services, where the major part of the service does still in fact run under the aegis of an unprivileged account; but it is simply the case that negotiating which account is an inherent part of the service function.

As such, you should now be thinking whether the gitea instructions are enough. The service account that you are creating is permitted interactive login via SSH, has an interactive shell program as its login program, and owns a home directory, giving a compromised service the ability to put stuff there and grant access to stuff there.

Further reading


Not the answer you're looking for? Browse other questions tagged or ask your own question.