[example][systemd] use DynamicUser=yes

[inclyc]

This patch fixes a warning generated by some new version of systemd. Use
"User=nobody" seems to be considered unsafe. So maybe we need to fix it
in our example files.

● ratholec@hitmc.service - Rathole Client Service
     Loaded: loaded (/etc/systemd/system/ratholec@.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2022-09-03 23:38:43 CST; 1h 27min ago
   Main PID: 507903 (rathole)
      Tasks: 14 (limit: 76731)
     Memory: 6.9M
        CPU: 39.908s
     CGroup: /system.slice/system-ratholec.slice/ratholec@hitmc.service
             └─507903 /usr/local/bin/rathole -c /etc/rathole/hitmc.toml

Sep 03 23:38:43 <hostname> systemd[1]: Started Rathole Client Service.
...
Sep 03 23:39:25 <hostname> systemd[1]: /etc/systemd/system/ratholec@.service:7: Special user nobody configured, this is not safe!
                                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969329
Link: trojan-gfw/trojan#612
Link: https://www.vvave.net/archives/fix-the-systemd-error-special-user-nobody-configured-this-is-not-safe.html
CC: @rapiz1

[rapiz1]

Thanks!

[keuin]

IMHO, nither User=nobody nor DynamicUser=yes should be used for rathole's systemd service.
Rathole's config file contains private keys, which shouldn't be accessible by users except the one who starts the rathole process. If you are using nobody, then this file is readable by nobody. This may not be desirable by most users.
The same thing also occurs when using dynamic users without extra configuration, such as copy the config file, which only the root user can read, to a file which is readable only by the temporary user, before the service is started.
I suggest using a fixed user for rathole, and protect the config file from being read by any other user.

[inclyc]

IMHO, nither User=nobody nor DynamicUser=yes should be used for rathole's systemd service. Rathole's config file contains private keys, which shouldn't be accessible by users except the one who starts the rathole process. If you are using nobody, then this file is readable by nobody. This may not be desirable by most users. The same thing also occurs when using dynamic users without extra configuration, such as copy the config file, which only the root user can read, to a file which is readable only by the temporary user, before the service is started. I suggest using a fixed user for rathole, and protect the config file from being read by any other user.

Did you mean systemctl --user? Just create a user-spec service and so others cannot see your private key.

[keuin]

IMHO, nither User=nobody nor DynamicUser=yes should be used for rathole's systemd service. Rathole's config file contains private keys, which shouldn't be accessible by users except the one who starts the rathole process. If you are using nobody, then this file is readable by nobody. This may not be desirable by most users. The same thing also occurs when using dynamic users without extra configuration, such as copy the config file, which only the root user can read, to a file which is readable only by the temporary user, before the service is started. I suggest using a fixed user for rathole, and protect the config file from being read by any other user.

Did you mean systemctl --user? Just create a user-spec service and so others cannot see your private key.

Systemd user services are not designed to solve this problem, and they don't. Actually, only root user can switch UID.
This will work, i.e. starting the rathole process with current UID, and the configuration file belongs to the same user. This behaves exactly the same if we just run rathole as root, and the file is (only) readable by root. But what we want to achieve is to limit the process permission (as much as possible). That's why we are struggling to start rathole with an unprivileged user.
However, the service just won't start if the configuration file does not have rwx permission on other users, because the service process is running under some another unprivileged user, not the task owner. So I suggest clarifying what will happen if the user copies this config and use DynamicUser=yes.

[inclyc]

In-Reply-To @keuin

Systemd user services are not designed to solve this problem, and they don't. Actually, only root user can switch UID.

"they don't"? If you create a user named rathole and write system service under its $HOME, starting this service just satisfy your complain exactly AFAIK.

I think you are throwing away user-service too easily. Could you elaborate or provide further information about this?

Actually, only root user can switch UID.

You must have the root permission if you want to change system-wide services, (e.g. /etc/systemd/system). Is there any difference in comparison to user-services?

However, the service just won't start if the configuration file does not have rwx permission on other users.

Permission wx is not mandatory. I could not image that you need to execute any configuration file.

[keuin]

In-Reply-To @keuin

Systemd user services are not designed to solve this problem, and they don't. Actually, only root user can switch UID.

"they don't"? If you create a user named rathole and write system service under its $HOME, starting this service just satisfy your complain exactly AFAIK.

I think you are throwing away user-service too easily. Could you elaborate or provide further information about this?

Actually, only root user can switch UID.

You must have the root permission if you want to change system-wide services, (e.g. /etc/systemd/system). Is there any difference in comparison to user-services?

However, the service just won't start if the configuration file does not have rwx permission on other users.

Permission wx is not mandatory. I could not image that you need to execute any configuration file.

Yes, they don't. If your user is somebody, then you probably won't want rathole to run as somebody and being accessible to your personal files. Otherwise we are creating a fixed user for rathole, that's what DynamicUser is trying to avoid in your patch. If you are trying to use nobody user, then this simply won't run as well, since only root user can set arbitrary UID. That's what I've stated.

I understand how to make it work as a user systemd service. But, please focus on what we are actually discussing. By setting nobody or a temporary UID, what we are trying to achieve is making the process unprivileged. But this example configuration hasn't fully achieved its goal. I think I've make this clear enough in our previous discussion.

To re-state my suggestion: as an example config, at least a note should be provided. This should be clearified and we can't just put nobody or DynamicUser in the example and let it fail.

(By talking rwx I simply means ripping off all permissions for other users. Seldomly a file is executable but not readable, because most users will know this is simply useless. And I simply put that assumption on my readers. However this is off-topic.)

[inclyc]

To re-state my suggestion: as an example config, at least a note should be provided. This should be clearified and we can't just put nobody or DynamicUser in the example and let it fail.

Agreed

[boenshao]

Stumble across this issue today and I agree DynamicUser=yes should not be set.

A typical use case is storing configurations and tokens under /etc/rathole/xxx.toml with permission set to 0600, that is, only the root user (or owner) can read the file. Preventing arbitrary users on the system from accessing the token.

Yet with DynamicUser=yes the rathole process spawned by systemd won't have the privilege to read the file either. We should at least document the effect/pitfall of setting DynamicUser=yes, I can open a PR, what do you think?

[rapiz1]

@boenshao It will be highly appreciated. Maybe we should provide an example using root and point out the security concerns with possible solutions(using separated users, etc.).