Názor k článku Jak nikdy nespouštět službu, aneb kdo posílá tajemný SIGKILL? od krauser - > Ano máme. A jsou linux-specifické. Takže tam...

> Ano máme. A jsou linux-specifické. Takže tam kde jsme měli portabilní programy (SysV není jen linuxová záležitost), tak se nic nezměnilo (alespoň dokud se nenašel někdo komu by se to chtělo portovat). A tam kde programy portabilní nebyly tak je to jedno, stejně mají linux specifický kód. Jesli se v něm volá libdaemonize nebo libsystemd je mi šumák.

Linux specificke? Proc se jim rika POSIX Capabilities tedy? Ano, puvodni POSIX draft 1003.1e je stazeny, ale tj celkem fuk, Linux neni jedina implementace.
Navic i kdyby byla, je to jedno, viz nize.

> 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".

Na tohle neslouzi caps, ale selinux policy, ta presne resi, ze program X muze poslouchat na portu Y a zadnem jinem.

> 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).

Vubec ne, zakladem je to, ze program pod root uzivatelem vubec nespustim, spustim ho jako neprivilegovany uzivatel (tzn. to, kam se dostane bezny sysv daemon) + navic mu dam urcite specificke caps navic. A nebo mu caps i normalniho neprivilegovaneho uzivatele jeste odeberu.

> 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í.

Prave ze ta aplikace nemusi mit vubec zadny linux specific kod. Muze byt napsana v ANSI C, stejne zdrojaky muzou fungovat na FBSD, Linuxu, Windows, Darwinu, ....

Proste a jenom se udela .service, v ni definuje pod jakym uzivatelem to ma bezet, prip. jak se omezi capabilities (prip pridam dalsi caps na binarku pres setcap). A ten program se nemusi starat vubec o nic. Je to lepsi, bezpecnejsi a jednodussi.

> 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í.

No a nebo se toho prava nevzda. S nastavenim caps v serivce nemuze v systemu nic, diky SELinuxu muze akorat znovu... poslouchat na svem portu :)
A nezasvini se kod platformne specifickymi vecmi.

Jednoznacn mnohem lepsi reseni nez to, co delaji daemony diky sysv - seteuid (cimz se rozhodne nezbavi vsech caps, ale pouze tech, ktere jsou navic dane root uzivateli oproti jinemu).