kvóty a jak na ně (Was: Re: jak velky disk snese EXT2?)

[Pavel Janik ml.]

   From: "Jan ' Kozo ' Vajda" <jvajda na somi.sk>
   Date: Thu, 20 Apr 2000 09:51:12 +0200 (MET DST)

Zdravím,

   > 	ale ak je to server a mate tam n+1 pouzivatelov a nejake services,
   > 	tak je IMHO lepsie mat particii viac, aby Vam napr. velky prilev
   > 	mailov neohrozil cinnost inych sluzieb ( ked je plny disk, tak niet
   > 	kam zapisat ) .. nehovoriac o tom, ze nejaky dobrak moze zaplnit
   > 	disk umyselne ( obcas ani quota nepomoze )

rozdělení na /, /usr, /var, /var/spool/ apod. je jasné, ale i datové partition
se vyplatí rozdělit. Pokud se odrovná nějaká partition, neohrozí to ostatní...

A když už jsme u těch kvót, tak si dovolím zase jednu story. Před nějakou
dobou jsem byl pozdě večer ve firmě a dělal jsem balíky GNU Emacsu a teTeXu
pro Red Hat Linux 6.2CZ. Když už jsem měl vše hotovo, chtěl jsem je zkopírovat
na ftp.linux.cz, kde mám ovšem kvótu. No nic, zapakoval jsem všechna RPMka do
jednoho .tar, aby to bylo přehlednější a spustil

scp všechno.tar účet na ftp.linux.cz:

A čekal jsem. Asi po dvou hodinách (přenášel jsem i zdrojové balíky, bylo toho
opravdu hodně) se mi vypsalo něco ve smyslu:

Quota exceeded.

V tom momentě jsem myslel, že zastřelím administrátora serveru. Jak se nakonec
ukázalo, tak je v ssh chyba, která mi klidně dovolí nakopírovat kolik chci *i
přes hard-kvótu* a tak mi to vlastně zachránilo dvě hodiny času :-)

Chybu jsem ihned reportoval autorovi RPM balíku (shodou okolností to byl
stejný člověk, kterého jsem chtěl předtím zastřelit :-). Ale on nemá čas -
proto si to někdo vezměte za domácí úkol. SSHD pravděpodobně ukládá na
souborový systém jako root a teprve na konci provede chown, kdy zařve na kvótu
(ale ve zdrojácích jsem si to neověřoval, mám teď úplně jiné problémy než číst
zdrojáky sshd :-(). Což je špatně. Nemůže to však udělat ani tak, že by si
ověřil, kolik místa má dotyčný na serveru a jenom tolik mu povolil
nakopírovat, protože: a) Yenya už by byl zastřelený mojí kulkou, b) uživatel
by mohl v druhém sezení smazat nějaké soubory a měl by hned volného místa co
hrdlo ráčí. Mohl by např. změnit identitu pomocí seteuid (ještě, že ne setuid
:-) a zapisovat pod uživatelem. Pokud by bylo vše v pořádku, na konci by se
vrátil pod roota. Pokud by to bylo špatné, vrátil by se taky, ale
pooooodstatně dříve než se tomu stalo v mém případě.

P.S. Výše uvedené není podloženo studiem zdrojových textů, ale každopádně se
tak stalo a podle mého názoru je to security hole jako Brno (možná i Praha,
ale já jsem BrnoCentrista). Pavle - ověříš a reportuješ to do bugtraqu?

Nějaké návrhy, patche?
-- 
Pavel Janík ml.
Pavel.Janik na inet.cz