Reevaluate usage of user "nobody"
This affects at least the systemd service file for the snmp_exporter.
According to https://wiki.ubuntu.com/nobody the 'nobody' user should only be used for nfs and daemons should not use this user, as multiple daemons with this user could affect each other.
Against nobody:
https://en.wikipedia.org/wiki/Nobody_(username)
Answers from Platforms like askbuntu unix.stackexchange etc.
Systemd logs the following message: /etc/systemd/system/snmp_exporter.service:8: Special user nobody configured, this is not safe!
"For" nobody: https://wiki.debian.org/SystemGroups#Groups_with_an_associated_user
Alternatives:
- create a real user (without home etc.) and set it in the service file
- use systemd's dynamicuser=yes feature, which allocates a new user on service start for the duration of the service
- https://www.freedesktop.org/software/systemd/man/systemd.exec.html#DynamicUser=
- should be usable as the service does not seem to need any filesystem access, except for the globally readable config file
- dynamicuser implies protectsystem=strict which prohibits nearly all access to the filesystem
- does not create a new entry for the user in the /etc/groups and /etc/passwd files
- less/no traces left after uninstalling, except for maybe the config file
- At least available since Systemd 232: https://0pointer.net/blog/dynamic-users-with-systemd.html
- "works on my system" without any problems so far (Raspberry Pi 4B, latest Raspberry Pi OS, based on Debian 11)
- caveats:
- not tested for all systems
- ?
My current systemd file looks like this
[Unit]
Description=Prometheus SNMP Exporter
After=network-online.target
StartLimitInterval=0
[Service]
Type=simple
DynamicUser=yes
ExecReload=/bin/kill -HUP $MAINPID
ExecStart=/usr/local/bin/snmp_exporter \
--web.listen-address=127.0.0.1:9116 \
--log.level=info \
--config.file=/etc/snmp_exporter/snmp.yml
KillMode=process
SyslogIdentifier=snmp_exporter
Restart=always
RestartSec=1
[Install]
WantedBy=multi-user.target
Yes, we make users for the other roles. This one needs cleanup.
Should be persistent across the board now #425