4.0 KiB
RustProxy (DEB/RPM): dostęp do katalogów WWW i certyfikatów
Jednostka z paczki uruchamia rust-proxy jako rustproxy:rustproxy, z
ProtectSystem=strict i ProtectHome=read-only. Katalogi /home, /var/www,
/srv i zewnętrzne PEM są dostępne do odczytu, jeżeli pozwalają na to
standardowe uprawnienia użytkownika, grupy lub POSIX ACL. Nie jest potrzebny
systemctl edit ani dopisywanie ReadOnlyPaths=. Dostęp do zapisu poza
/var/lib/rustproxy, /var/log/rustproxy i dopuszczonym /etc/rustproxy
pozostaje zablokowany przez systemd. Nie zmieniaj ProtectSystem na false.
1. Katalog strony WWW w /home
Przykład (zastąp klient i ścieżkę nazwą swojej strony):
sudo setfacl -m u:rustproxy:--x /home/klient
sudo setfacl -R -m u:rustproxy:r-X /home/klient/public_html
sudo -u rustproxy test -r /home/klient/public_html/index.html && echo OK
sudo systemctl restart rustproxy
--x pozwala jedynie przejść przez prywatny katalog domowy; r-X nadaje
odczyt plików i przechodzenie przez podkatalogi. Dla nowo tworzonych plików
ustaw także odpowiednie domyślne ACL na katalogach witryny lub pilnuj grupy
oraz umask narzędzia publikującego.
2. Grupa zamiast ACL (np. /var/www)
Nadaj witrynie osobną, możliwie wąską grupę, np. web-readers, zapewnij
jej r do plików i x do katalogów, a potem:
sudo usermod -aG web-readers rustproxy
id rustproxy
sudo systemctl restart rustproxy
Grupy dodatkowe użytkownika rustproxy są automatycznie uwzględniane przez
systemd przy starcie usługi. Nie wpisuj ich w SupplementaryGroups= i nie
udostępniaj plików całemu światu (chmod 777 / chmod -R 755 nie są wymagane).
Restart jest konieczny po zmianie grup, ponieważ uruchomiony proces nie
pobiera nowej listy grup samoczynnie.
3. Zewnętrzny certyfikat z Certbot / Let's Encrypt
Dla example.com nadaj jedynie możliwość przechodzenia przez katalogi i
odczytu bieżących rzeczywistych plików (symlinki live prowadzą do archive):
sudo setfacl -m u:rustproxy:--x /etc/letsencrypt /etc/letsencrypt/live \
/etc/letsencrypt/live/example.com /etc/letsencrypt/archive \
/etc/letsencrypt/archive/example.com
sudo setfacl -m u:rustproxy:r-- "$(readlink -f /etc/letsencrypt/live/example.com/fullchain.pem)"
sudo setfacl -m u:rustproxy:r-- "$(readlink -f /etc/letsencrypt/live/example.com/privkey.pem)"
sudo systemctl reload rustproxy
Ważne: RustProxy celowo wymaga, aby zewnętrzne pliki certyfikatu/klucza oraz
wszystkie rzeczywiste katalogi nadrzędne były własnością root albo
rustproxy, nie były zapisywalne przez grupę/innych, a klucz prywatny nie był
czytelny przez innych. Katalog WWW może być własnością innego użytkownika;
ścieżka do PEM ma ostrzejszą walidację. Nie zakładaj, że certyfikat trzymany
pod /home/klient z katalogiem należącym do klient zadziała po samym ACL.
Umieść go w zaufanym katalogu np. /etc/letsencrypt i nadaj odczyt ACL/grupą.
Po odnowieniu certyfikatu (nowy plik w archive/) odtwórz uprawnienia przez
hook odnowienia, a potem przeładuj RustProxy.
4. Diagnostyka
systemctl show rustproxy -p User -p Group -p ProtectHome -p ProtectSystem -p ReadWritePaths
systemctl cat rustproxy
namei -l /home/klient/public_html/index.html
sudo -u rustproxy test -r /home/klient/public_html/index.html && echo OK
journalctl -u rustproxy -n 60 --no-pager
Test sudo -u potwierdza prawa POSIX poza sandboxem systemd. Jeśli działa,
a RustProxy dalej nie czyta pliku, sprawdź aktywną jednostkę/drop-in, politykę
SELinux lub AppArmor (ausearch -m avc -ts recent na SELinux), symlinki i
system plików. Ręczna jednostka w /etc/systemd/system/rustproxy.service ma
pierwszeństwo przed pakietową w /usr/lib/systemd/system i nie zostanie
nadpisana automatycznie. Web Server ma własną politykę symlinków. ACL nie
pozwoli zapisać strony lub uploadów pod /home//var/www, dopóki nie zostanie
jawnie dopuszczony zapis w sandboxie; zapis aplikacji trzymaj osobno.