Arch Linux User Repository

@everyx No, it doesn't work for everyone and requires manual configuration of the override.

@akiirui could you submit a PR to the upstream repository for this systemd unit modification? The current system unit file is entirely derived from the upstream source at https://github.com/SagerNet/sing-box.

This is my sing-box@.service, using DynamicUser：

/etc/systemd/system/sing-box@.service

[Unit]
Description=sing-box service
Documentation=https://sing-box.sagernet.org
After=network.target nss-lookup.target network-online.target

[Service]
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE CAP_SYS_PTRACE CAP_DAC_READ_SEARCH
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE CAP_SYS_PTRACE CAP_DAC_READ_SEARCH
DynamicUser=yes
CacheDirectory=sing-box-%i
CacheDirectoryMode=755
LoadCredential=config.json:/etc/sing-box/%i.json
ExecStart=/usr/bin/sing-box run -c ${CREDENTIALS_DIRECTORY}/config.json -D ${CACHE_DIRECTORY}
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=10s
LimitNOFILE=infinity

[Install]
WantedBy=multi-user.target

/etc/systemd/system/sing-box@PROFILE.service.d/override.conf

[Service]
LoadCredential=cert:/etc/letsencrypt/live/EXAMPLE.COM/fullchain.pem
LoadCredential=key:/etc/letsencrypt/live/EXAMPLE.COM/privkey.pem

PROFILE.json

"tls": {
  ...
  "key_path": "/run/credentials/sing-box@PROFILE.service/key",
  "certificate_path": "/run/credentials/sing-box@PROFILE.service/cert"
}

One solution would be to make the config not readable by non-root users and load it using LoadCredentials in the systemd service.

@Poscat In fact, most users who care about this should create a configuration file under /etc/sing-box/ themselves, set the permissions, and then enable sing-box@[config_file_name].service.

However, can you send me a patch to my email? I will carry out a review.

One solution would be to make the config not readable by non-root users and load it using LoadCredentials in the systemd service.

Are there any reasons the default config is readable by anyone? This seems to be a potential security issue :/

@Poscat Since the sing-box user is created by systemd-sysusers, modifying the file group to sing-box within the PKGBUILD should not work. I'm not sure what the best practice is for this type of requirement. Do you have any related suggestions?

Are there any reasons the default config is readable by anyone? This seems to be a potential security issue :/

add gopath to build so that it doesn't pollute your home dir export GOPATH="$SRCDEST/go-modules"

@kevku Setting GOPATH="$SRCDEST/go-modules can be a helpful solution if they haven't already configured a GOPATH, I will submit an update soon.

add gopath to build so that it doesn't pollute your home dir

export GOPATH="$SRCDEST/go-modules"

When using tun inbound with systemd-resolved, sing-box would execute resolvectl commands to modify default DNS route and search domain, but sing-box user does not have this privilege.

ref: https://github.com/SagerNet/sing-box/issues/477 https://github.com/SagerNet/sing-tun/blob/38c945fec5df642b1ee0895c5c3a75a3f1276341/tun_linux.go#L821-L824

I suggest install a polkit rule file to /usr/share/polkit-1/rules.d/sing-box-tun.rules:

// Allow sing-box to set domain and default-route
polkit.addRule(function(action, subject) {
    if ((action.id == "org.freedesktop.resolve1.set-domains" ||
         action.id == "org.freedesktop.resolve1.set-default-route" ||
         action.id == "org.freedesktop.resolve1.set-dns-servers") &&
        subject.user == "sing-box") {
        return polkit.Result.YES;
    }
});

This would allow sing-box user to modify systemd-resolved DNS configuration without manual authorization.