Non-world-readable config?

[Klaaktu]

shadowsocks-rust/debian/shadowsocks-rust-server@.service

Line 18 in f23366d

DynamicUser=yes

Currently in order to have access to the config file when it's run as DynamicUser, it's kinda assumed that the config will be readable by anyone. This is uncommon for files that contain secrets (e.g. WG / SSH private keys), in this case the password.
So far I've found 3 solutions.

1. Do nothing. Since the main purpose of SS is circumvention, not sure if it matters if the password is compromised.
2. LoadCredential=. This will copy the config to the private credential store and make it accessible to the DynamicUSer. But this has a 1MB file size limit. And I'm not too confident that this won't break if someone didn't install some component of systemd.

[Service]
LoadCredential=%i.json:/etc/shadowsocks-rust/%i.json
ExecStart=/usr/bin/ssservice server --log-without-time -c ${CREDENTIALS_DIRECTORY}/%i.json

> sudo chown root: /etc/shadowsocks-rust/
> sudo chmod 700 /etc/shadowsocks-rust/

3. A dedicated user, and remove DynamicUser but add back its hardening. This requires downstream packaging to create a dedicated user, and make it more troublesome to use the systemd unit manually (on distros that don't package ss-rust).

[Service]
# DynamicUser=yes
ProtectSystem=strict
ProtectHome=read-only  # yes
PrivateTmp=yes
RemoveIPC=yes
User=shadowsocks

> sudo chown root:shadowsocks /etc/shadowsocks-rust/
> sudo chmod 750 /etc/shadowsocks-rust/

Pls share if you have better ideas!

[zonyitoo]

Thanks for the detailed writeup! I'd go with option 2 (LoadCredential=):

• It keeps the full DynamicUser=yes sandbox — ProtectSystem=strict, PrivateTmp, RemoveIPC, NoNewPrivileges and the "no persistent identity" property all remain intact. Option 3 silently drops these implied defaults and has to re-list them by hand, which is easy to get incomplete.
• The 1MB cap is a non-issue — an ss-rust config is a few KB at most.
• systemd v245 (2020) is old enough for the distros that would ship this: Debian 11 (247), Debian 12 (252), Ubuntu 20.04+ (245).
• Zero user lifecycle to manage — no sysuser allocation, no postinst, no orphan UID cleanup on uninstall. It also keeps working out of the box for people running the unit manually on unpackaged distros.
• Migration is basically free — the config file stays at /etc/shadowsocks-rust/%i.json. PID 1 (root) reads it and exposes a 0400 per-unit copy under $CREDENTIALS_DIRECTORY that only this service can read; the copy dies with the unit (tmpfs). Existing setups keep working — users just tighten the dir to root:root 0700 as you showed.

Not fond of option 1: a world-readable file carrying the server password is bad hygiene, even if the practical impact is only "any local user can use your proxy".

If any packager sees a problem with the v245 floor, please speak up.