Docker "kedvesség" - process limits
Ez de fura... a szerveremen nem tudom honnan, be van állítva egy default process limit a usereknek:
ulimit -u
30784
Én úgy tudtam, hogy ez unlimited by default, de most olvasgatva úgy tűnik, az unlimited egy Debian specialitás, egyébként a kernel beállít egy alapértéket. (ettől kezdve nem értem, hogy működhet a fork bomb nevű poén)
No mindegy, a minap az androidos telefonomat sikerült kiakasztani egy ilyen fork bomb segítségével, hogy kis híján a szervizben kötött ki :D
Most docker konténerben akartam kipróbálni, de biztos-ami-biztos inkább megnéztem a konténer limitjeit. És itt jött a meglepetés: a host minden processzének be van állítva limit, kivéve a docker konténert. A konténerből simán megfektethetem a hostot is egy ilyen fork bomb segítségével...
Nem gáz ez egy kicsit?
Update: O.K., lehet limitet adni a konténernek, de ha külön nem gondoskodom róla, akkor bizony limitálatlanul rohangál...
■ ulimit -u
30784
Én úgy tudtam, hogy ez unlimited by default, de most olvasgatva úgy tűnik, az unlimited egy Debian specialitás, egyébként a kernel beállít egy alapértéket. (ettől kezdve nem értem, hogy működhet a fork bomb nevű poén)
No mindegy, a minap az androidos telefonomat sikerült kiakasztani egy ilyen fork bomb segítségével, hogy kis híján a szervizben kötött ki :D
Most docker konténerben akartam kipróbálni, de biztos-ami-biztos inkább megnéztem a konténer limitjeit. És itt jött a meglepetés: a host minden processzének be van állítva limit, kivéve a docker konténert. A konténerből simán megfektethetem a hostot is egy ilyen fork bomb segítségével...
Nem gáz ez egy kicsit?
Update: O.K., lehet limitet adni a konténernek, de ha külön nem gondoskodom róla, akkor bizony limitálatlanul rohangál...
Valószínűleg még a limit
Sajnos a fork bomb az nem
Amit viszont gázosnak tartok a magam részéről, hogy a docker ignorálja a rendszerben beállított limiteket akkor is, ha user mapping segítségével más user alatt fut a root-ja is.
A konténer indításakor (esetleg valahol konfigban?) kell megadni a konténerre vonatkozó limiteket. Ha ez elmarad, akkor a hoston hiába van bármi beállítva, kifekteti a jelek szerint.
Ha van beáldozható virtuális géped (nem konténer), próbáld ki ezt shellből:
:(){ :|: & };:
Ha a usered process limitje (ulimit -u) "unlimited", akkor pár másodperc alatt megdöglik a gép, csak a ki-/bekapcs segít rajta.
Ha simán indítasz mondjuk egy olyat, hogy "docker run --rm -it alpine" és abban próbálod ki, akkor azt hiszem, a host-odat fogod kinyírni vele, nem a konténert.
Kipróbálni nem tudom, de
Mondjuk személy szerint én nem aggódom miatta fejlesztői környezetben, de éleset üzemeltetőknek nagyon érdekes lehet.
Windows alatt - ahogy én fejlesztek - nem nagy ügy a linuxos "gazda" VM-et is restartolni ha muszáj, magától a gazdagéptől pedig korlátozott a CPU, RAM, storage, amivel gazdálkodhat.
Amíg úgy fejleszt valaki, hogy csak az épp aktuális projekt konténerei futnak és nincs "közös" konténer projektek között, addig dev környezetben nem para.
Élesben viszont simán megfekteti így egyik alkalmazás az összeset - ha valóban a hostot nyírja ki.
Hát konkrétan megjelent
Viszont a /proc alatt látszik, hogy a docker konténer processzlimit nélkül fut.
Nem hinném, hogy bugreportra érdemes, végülis a dockert nem analfabétáknak találták ki, ha valaki doksi olvasással indít, azért nem érik ilyen kínos meglepetések.
Én is csak azért tettem szóvá, mert meglepett, hogy outofthebox így működik.
A win7-nél virtualbox-ról
Linux
Szerintem ez egyaltalan nem
Ha neked ez ugy van bekonfiguralva, hogy lehessen fork bombot csinalni, akkor azt a kontenerben is meg lehet tenni.
Épp ez a gond, hogy nem
A hoston mindenhol, mindenkinek be van állítva.
Egyébként most megnéztem egy fedora virtuális gépben, ott valóban örökölte a guestként futó hosttól a limiteket. :)
Szóval ez akár egy ubuntu bug is lehet még...
Megnézem a laptopon is, hogy ott van-e eltérés.
Ahogy a linkelt stackoverflow
ulimitalapbol a soft limiteket mutatja meg, a kontener pedig a hard limiteket latja soft limitkent (soft limit: barmikor allithatod magadnak, sajat hataskorben; hard limit: csakroot-kent irhatod folul). A hard limiteket a-Hkapcsolo mutatja meg. Kicsit faramuci ez a mukodes, de van ertelme: a valos limit a hard limit, a soft limitet barmikor atlepheted.Csak az a gáz mindezzel, hogy
Mellesleg ki is próbáltam a laptopomon: ubuntu alatt simán megdöglik a host egy a konténerben futó fork bombtól... Úgy kettő másodperc után.
Ö... a soft limitet sem léphetem át bármikor. Azt saját hatáskörben megemelhetem a hard limitig.
Legalábbis amikor utoljára tanfolyamra jártam, még ez volt a helyzet.
Update: beállítottam a daemon.json-ben egy userns-remap paramétert, a hozzá tartozó userre a /etc/security/limits.conf fájlban beállítottam pár limitet ehhez a userhez, de ennek ellenére:
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size unlimited unlimited bytes
Max resident set unlimited unlimited bytes
Max processes unlimited unlimited processes
Max open files 1048576 1048576 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 30966 30966 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
a soft limitet sem léphetem
Legalábbis amikor utoljára tanfolyamra jártam, még ez volt a helyzet.
Igen, en is ugyanezt probaltam mondani :).
Az a probléma vele, hogy
Ugyanez egy fedoran már nem igaz, ott tényleg átvette a rendszertől ezeket az értékeket a docker.
Megneztem, nalam is unlimited
unlimiteda limit, de mindennek oka van, nalam a/lib/systemd/system/docker.service-ben szerepelt egyLimitNPROC=infinitydirektiva. Gondolom ubuntuval is ez a helyzet, lehet hogy fedoraban mashogy van felkonfiguralva.Mindennek a rákfenéje a
Na odáig nem jutottam. A
Kezdem érteni, miért utálják sokan a systemd-t...
Egyébként itt az indoklás:
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
Na ez se rossz - jó, hogy van tűzfal a hoston...
Ubuntu a host, ufw segítségével konfigurált packet filterrel.
Indítom az nginx konténert, megadom neki, hogy a saját portjait mely host portokhoz csatolja (docker run -p host:container) és nyugodtan hátradőlök, hogy ezeket a portokat úgysem lehet elérni, míg nem engedélyezem a hoston is. Erről egy pillanatra megfeledkeztem és megnyitottam böngészőből a konténerhez tartozó portot és az megnyílt...
Hát igen... nem árt olvasni is, a docker nem mindig úgy működik, ahogy azt elvárnám. :)
(konkrétan a -p opcióval megadott portokat berakja a netfilter nat táblájába, továbbítva őket a konténerhez, anélkül, hogy a tűzfal konfigot piszkálni kellene)