v.34.5_fix_systemd

deploy/README.md

@@ -23,10 +23,13 @@ addresses, limits or a service-account convention. Never point it at a user-owne
 source directory containing writable executables or real public web content.
 
 After starting through your service manager, run account/certificate CLI operations
-as the same service account with `--data-dir /var/lib/rustproxy`. The example
-uses `ProtectHome=true`, so certificate files intended for runtime use must be in
-the data directory, not in a home directory. Use an SSH tunnel to access the local
-admin port remotely. This reference unit keeps administration on `127.0.0.1:9090`; public HTTP/HTTPS
+as the same service account with `--data-dir /var/lib/rustproxy`. The reference
+uses `ProtectHome=read-only`, so site roots in `/home` and trusted external
+certificates can be read according to Unix permissions, groups and ACLs,
+without overriding the systemd sandbox. The reference binds administration
+to `0.0.0.0:9090`; restrict this to loopback before running on an untrusted
+network, or use administration HTTPS and strict network controls. Use an SSH
+tunnel to access a loopback-only admin port remotely. Public HTTP/HTTPS
 listeners remain explicit. For direct remote administration, enable Administration HTTPS and persist
 a non-loopback bind from the panel rather than exposing the plain-HTTP bootstrap listener. For a
 systemd drop-in, reset `ExecStart` before replacing it. Example preserving the loopback-safe admin:
@@ -36,7 +39,6 @@ systemd drop-in, reset `ExecStart` before replacing it. Example preserving the l
 ExecStart=
 ExecStart=/opt/rustproxy/current/rust-proxy --data-dir /var/lib/rustproxy --admin-listen 127.0.0.1:9090 serve --proxy-listen 0.0.0.0:80 --tls-listen 0.0.0.0:443
 ReadWritePaths=/var/log/rustproxy
-ReadOnlyPaths=-/etc/letsencrypt -/etc/ssl
 ```
 
 Saving HTTP/TLS or TCP/UDP stream listener changes in the UI does not restart this service. Restart explicitly
@@ -73,7 +75,11 @@ sudo getfacl /etc/rustproxy /etc/rustproxy/config.json
 
 **Security:** the shown `0.0.0.0:9090` requires administration HTTPS and network access controls before remote exposure; use loopback administration otherwise. The complete export, privilege commands, validation and rollback guidance live in [Installation](../docs/INSTALL.md#optional-systemd-json-configuration).
 
-External certificate files under `/etc/letsencrypt` or `/etc/ssl` remain read-only under the systemd sandbox. `ReadOnlyPaths=` does not grant Unix permissions; use narrow POSIX ACLs for the `rustproxy` user. For traversal of a protected root, for example:
+External certificate files under `/etc/letsencrypt`, `/etc/ssl` or another
+trusted root/service-owned directory remain read-only under the systemd
+sandbox. No path-specific `ReadOnlyPaths=` allowlist is necessary;
+`ReadOnlyPaths=` does not grant Unix permissions anyway. Use narrow POSIX ACLs
+for the `rustproxy` user. For traversal of a protected root, for example:
 
 ```bash
 setfacl -m u:rustproxy:--x /etc/ssl/
@@ -81,3 +87,7 @@ setfacl -m u:rustproxy:--x /etc/ssl/
 
 Grant `r--` only on the certificate/key files RustProxy actually needs; never grant write access to the service identity.
 If Certbot or another renewer recreates a key as `0600`, reapply the named file ACL to the newly resolved target in the renewal hook before calling the RustProxy reload API.
+External certificate parent directories and PEM files must be owned by root
+or the service account and meet the application's safe-file checks; arbitrary
+user-owned `/home` trees work as Web Server roots, but not as PEM ancestry.
+See [Installation: external paths](../docs/INSTALL.md#linux-debrpm-read-only-access-to-external-paths).