Názor k článku Jak nikdy nespouštět službu, aneb kdo posílá tajemný SIGKILL? od ebik - Zatraceně, vytratila se mi pointa. A navíc jsem...

Zatraceně, vytratila se mi pointa. A navíc jsem si tu manpage přečetl napoprvé špatně, protože je ta manuálová stránka napsaná tak aby bylo jasné jak se řeší SUID bit na souboru. Tady jsme ale v jiné situaci.

Přijde mi, že capabilities je pěkný systém jak udělat hardening, ale stále mi nerozliší, že uživatel www-data-4 smí poslouchat jen na 1.2.3.4:80 a uživatel www-data-5 jen na 1.2.3.5.80. Takže stále musím věřit aplikaci, že si vezme ten správný resource. A pokud neobsahuje linux-specifický kód tak se práva CAP_NET_BIND_SER­VICE umí vzdát jen jediným způsobem: změnou uživatele z roota na neroota. Vůbec se neodvažuji tady pomyslet na aplikace, které se práv po inicializaci nevzdají, jen proto, že "už jich přece nemají tolik, tak proč to řešit".

Pokud budete chtít z tohoto důvodu CAP_NET_BIND_SER­VICE aplikaci vůbec nedat, potřebujete aby váš init systém uměl rozumět prostředkům, které té službě předává (listen socketa na port 80), to už není moc KISS, a vždy přijde někdo s další třídou prostředků, které je do toho potřeba doimplementovat. Tohle by bylo hezké, kdyby to bylo řešeno jako obecná rozšiřitelnost, a ne jen řešení jednoho konkrétního případu (síťový subsystém).

Pokud bude mít aplikace linux-specifický kód, starající se o inicializaci (zahození CAP_NET_BIND_SER­VICE), tak už mě neuráží, že se má starat i o to, aby správně běžela v historickém sys-V initu. A pokud pak systemd vyžaduje jinou sekvenci spouštění, má ji vyžadovat, místo toho aby tvrdil, že takovou aplikaci (napsanou pro sysV) umí spustit bez ztráty spolehlivosti spuštění.