Pristupova prava v Linuxu

[Pavel Kankovsky]

On Tue, 7 Dec 2004, Jan Houstek wrote:

> * neda se poradne kontrolovat, s jakymi pravy vznikaji nove soubory
>   (umask je malo, je to globalni vec a navic rada hyperinteligentnich
>   utilit si prava stejne nastavi po svem, napr. pri kopirovani po siti
>   na zaklade toho, jaka prava mel original)

To je pravda, ale podle mych zkusenosti neni skupina programu, co natvrdo
prerazi umask (i v situaci, kdy je to evidentne nezadouci -- pokud je to
soubor treba s nejakym privatnim klicem, tak je to naopak spis zadouci,
aby se to neridilo umaskem), az tak velka. Pominu-li kopirovani odjinud,
coz je specificka vec, pak lze navic vetsinou takove chovani oznacit jako
chybu a dozadovat se opravy.

> * neda se rozumne urcit skupina (oblibene reseni typu sgid na skupinu
>   casto konci tim, ze nekdo v dusledku nejake akce sejme bud ten sgid nebo
>   zmeni skupinu)

Tak na tohle jsem snad ani nenarazil. Ne ze bych sdilene adresare pouzival
az tak intenzivne, ale trochu ano a adresare byla vetsinou nejmene
problematicka vec, potize obvykle vznikaly snad jen v okamziku, kdy tam 
nekdo presunul cely adresar odjinud.

Dal by se asi pro oba vyse zminene problemy udelat takovy do jiste miry
workaround, ze by se to nastavilo tak, aby to vetsinou bylo spravne, a
periodicky by se na to vypustil nejaky strojek, ktery by opravil pripadne
vznikle odchylky. Nebo aspon vynadal uzivateli, ktery je ma na svedomi. :)

Take mne napada, ze s presuny & hyperlinky se lze razne vyporadat tak, ze 
cely sdileny prostor bude jeden samostatny filesystem. Coz zaroven zabrani 
tomu, aby se navrzeny opravny stroj vymknul kontrole.

> * nikdo jiny nez vlastnik nemuze menit prava a neexistuje ani moznost akce
>   "take ownership" (i kdyz to treba lze udelat berlickou typu soubor
>    prejmenovat, zkopirovat zpet a prejmenovany smazat)

To by v zasade slo udelat pomocnym programem bezicim pod rootem (s nize
popsanymi vyhradami).

Jina moznost, ktera uz by vyzadovala zasah do jadra systemu a 
pravdepodobne byla trochu rizikova, ale take do znacne miry resila i 
dalsi problemy, by bylo zavedeni privilegovaneho clenstvi ve skupine, 
ktere by uzivateli umoznilo v nejake mire manipulovat s cizimi soubory, 
ktere maji danou skupinu, jako by byly jeho vlastni, tj. zejmena menit 
pristupova prava, pripadne prevzit vlastnictvi atd.

> * soubor si nese prava s sebou a neni zadny zpusob, jak je ovlivnit jeste
>   nejakym kontextem, napr. adresare, ve kterem se nachazi (jo, ja vim, ze
>   tohle je tezke treba kvuli hardlinkum, ale je to pomerne prirozeny
>   pozadavek)

Da se provest takovy sileny kejkl, kdy mam adresar a pod nim soubory,
pricemz soubory ma o+r (pripadne o+rw, ale to uz je hodne o hubu),
zatimco adresar ma o= a g+rwx. Takze pristupova prava je de facto urcena
adresarem. Vnorovanim souboru lze vytvaret pruniky skupin, vytvarenim 
alternativnich cest k ruznym hardlinkum souboru lze vytvaret sjednoceni.
Ale je to opravdu silene. :)  (Navic je to velmi krehka konstrukce.)


On Tue, 7 Dec 2004, Dracula007 wrote:

> Troufam si ale tvrdit ze nic lepsiho nez ACL asi nenajdete, alespon o
> nicem prakticky pouzitelnem nevim a myslim ze veci ktere v nem vyresit
> nejdou jsou prave z te sorty "logickych" omezeni.

ACL nejdou moc dohromady s unixovym pojetim souboru. Unixove soubory jsou
samostatne existujici entity, ktere nejsou zavisle na adresari, ve kterem
se nachazeji, a tudiz je treba, aby si kazdy soubor nesl uplnou informaci
o pristupovych pravech s sebou, protoze ji narozdil od Novellu a Woken
nemuze dedit za chodu. Kdyz pak nastavite ACL na celem podstromu, tak
vysledkem bude tisic souboru, kazdy se svou kopii ACL, a kdykoli budete
mit potrebu to ACL zmenit nebo treba overit, ze je spravne nastavene,
tak to bude strasna prace.

Lepsi je IMHO system, kde objekty nejdriv sdruzim do skupiny a pristupova 
prava prideluju az k te skupine. Znalejsim jedincum to bude pripadat 
povedome, podobnym skupinam objektu se v nekterych bezpecnostnich
modelech rika "typ".


On Tue, 7 Dec 2004, Jan Houstek wrote:

> Jaka logicka dira je v tom, ze chci umet prevzit vlastnictvi souboru,
> pokud mi stavajici prava dovoli existujici soubor smazat a na jeho miste
> vytvorit kopii?

1. ten soubor muze byt nalinkovany i jinde,
2. ten soubor muze byt otevreny.

V obou jmenovanych pripadech se modifikace se vysledek lisi.
(Tedy obou pripadech...v jistem smyslu je to totez. Viz tez chovani
unlink() na otevrenych souborech.)


On Tue, 7 Dec 2004, Karel Zak wrote:

> Existuji systemy na spravu dokumentu, verzovaci veci apod. IMHo pokud
> vam nestaci zakladni 'level' tak ze musite posunout o uroven vyse. UN*X
> vetsinou resi prava tak, aby na nem bylo mozne provozovat aplikace,
> ktere prinaseji neco dalsiho co on sam nezvlada. Ale nastesti se nesnazi
> nahrazovat na urovni OS aplikace samotne. Libovolny obecny ACL jednou
> prestane stacit...

Uplne preneseni vyhodnocovani pristupovych prav na userland je sice velmi 
flexibilni, ale ne vzdy zadouci.

Napr. z toho duvodu, ze zvetsuje pocet trusted komponent v systemu. Takze
misto jedne (jadro) mam najednou dve (jadro a jeste ten s*id program ci
demon ci co), pricemz rizeni pristupu k spravovanym datum lze zcela obejit
na obou urovnich.

Jistymi kejkly s nastavenim pristupovych prav (podobnymi vyse zminenym
trikum s rozdilnym nastavenim adresaru a souboru v nich) se lze i ve
standardnim unixovym modelem trochu priblizit idejim Clark-Wilsonova
modelu, kdy k datum pristupuji vyhradne skrz proverene programy (TP =
"transformacni procedury" v terminologii C-W), ale TP musi porad
respektovat to, zda ma uzivatel k datum povoleny pristup. Ale je to 
dost omezene a hodi se to jen na hodne specificke veci. Pouziva se to
treba Openwallove "tcb" (http://www.openwall.com/tcb/).


On Tue, 7 Dec 2004, Pavel Janoušek wrote:

> 	SUid bit na adresář (nepsaná konvence)? -

S*u*id bit na adresari nedela vubec nic. :)


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."