Umask

Linux-kezdő

Megköszönnék egy kis felvilágosítást! Egyszerűen nem tudok rájönni az umask helyes használatára. Addig meg van, hogy rwx jogokat 2 hatványaival tudok adni, de míg chmod-nál működik pl a 777-nél mindenki megkapja mindenre a jogot umask-nál ez jön össze.

  • 7464 megtekintés

( locsemege v | 2014. 02. 27., cs – 20:05 )

Az 1-es komplemensével csinál logikai AND kapcsolatot. Ugyan most nem olvasom el az umask manualját, de általában jó ötlet a mask-okat nullával kezdeni, mert ha az illető paraméter számként kerül értelmezésre, akkor kellemetlen, ha az nem oktálisan, hanem decimálisan történik. Úgy emlékszem, ezt a cifs mount fmask opciójával szívtam meg, de nagyon.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( bucko | 2014. 02. 28., p – 06:56 )

A mai, agresszívkismalacok által sújtott reggelen...

A 777 az 3 db oktális számként szokott megjelenni. Az oktálist felfoghatjuk a bináris supersetjének, mint ahogy hexadecimálist is. A jegyek száma permissiont kifejezve akár 4 is lehet:

4000 Sets user ID on execution.
2000 Sets group ID on execution.
1000 Sets the link permission to directories or sets the save-text attribute for files.
0400 Permits read by owner.
0200 Permits write by owner.
0100 Permits execute or search by owner.
0040 Permits read by group.
0020 Permits write by group.
0010 Permits execute or search by group.
0004 Permits read by others.
0002 Permits write by others.
0001 Permits execute or search by others.

Innentől az umask használata:
file_permission = max_file_creation_permission & umask
Ne zavarjon meg senkit, hogy a ravasz programok nem raknak x jogosultságot egy szövegre! Ugyanakkor a "chmod +x file" csak annyi x-et rak, amennyit az umask szeret engedni.
Az umask=444 az mkdir programot "titkosított mappa előállító eszközzé" fokozza. :)
Szóval rafinált egy dolog. :))

Az 1000 jog leírása nem mondható intuitívnak. A save-text attribútum ma már kb sehol nem érdekes, ellenben az a link permission ennél furmányosabb, mert a fenti megfogalmazás *számomra* úgy értendő, hogy csinálhatok hard linket a könyvtárhoz magához (olyan rendszert már láttam, amin ezt meg lehet csinálni, de olyat még nem, amelyiken ezt a sticky bittel lehet szabályozni, kérek linket), míg a valóságban azt jelenti, hogy a könyvtár*ból* való törlés korlátozva van (az pedig ugye unlink).

A "chmod +x file" fenti leírása erősen OS függő, van olyan, amelyik ebben az esetben figyelembe veszi az umask-ot (ahogy írtad), és van olyan, ahol ez egyenértékű az a+x formával, amikor is *nem* veszik figyelembe az umask-ot.

És az eredeti kérdésfelvetőnek:

amikor egy program létre akar hozni egy fájlt (közönséges fájlt, könyvtárat, soft linket, stb), akkor ebben a létrehozó műveletben alacsony szinten meg kell mondania az OS-nek, h milyen jogokat szeretne látni (lásd: man 2 creat). Ezeket a jogokat fogod tovább csökkenteni az umask-kal. Ha tehát a program 751 joggal akarja létrehozni a fájlt, míg az umask 237, akkor:
a 7-ből (4+2+1) eldobja a 2-t, marad 5.
az 5-ből (4+1) eldobja a 3-t (2+1), azaz mivel a 2-t nem tudja eldobni, mert már eleve hiányzik, tehát csak az 1-t, azaz marad a 4.
az 1-ből eldobja a 7-et (4+2+1), marad a 0.
Azaz a létrejövő fájl joga 540 lesz. Ha viszont 666-tal akarta volna létrehozni a program, akkor 440 a maradék.
Épelméjű emberek amúgy paranoia függvényében 077, 027, 022 umaskot szoktak beállítani, ezzel biztosítva, hogy véletlenül se kapjon másvalaki írás jogot egy fájl/könyvtár létrehozásakor.
Viszont mivel azt általában nem tudjuk, hogy az alkalmazások milyen joggal akarják létrehozni a fájlokat, általában azt sem nagyon lehet megjósolni, hogy az umak ebből mit hagy. Az umask-kal ugyanis azt adjuk meg, hogy mit *nem* engedünk meg biztosan.

Link: chmod
Az os verzió mindegy, mert 20+ éve ugyanúgy működik, míg a linux az "fejlődőképes", így néha változik. :(
A "sticky bit" (t) tipikus felhasználása pl. a /tmp, ami azt célozza, hogy ne törölje/módosítsa más az általam megnyitott/létrehozott valamit. A való világban inkább acl segítségével szoktam védekezni. A dir linket linuxon láttam először, de szerintem sincs igazán értelmes felhasználása.
A paranoia helyett inkább a tervezett kifejezést alkalmaznám. :) A paranoia jellegű védelem inkább a jóskapista home dir-re igaz. Védett adatok/rendszer esetén a szerveré a user jog, a mellékszerepőké a group. Az umask meg 007, és explicite megmondom a struktúra létrehozásakor, hogy ki hova hajthat be. Ha valami adat elkészül, akkor is explicit rakom rá a group jogosultságot, ha éppen szükséges. Az olyan rendszer, ahol csak explicit lehet a jogosultságot megmodani (+x automatikusan a+x), az nem kényelmes. Erre példa, ha fordítok egy teszt programot, és nem akarom, hogy a group tagok automatikusan tudják futtatni. Annyi magyarázat van azért erre a jelenségre, hogy az umask nem tiltás csak "ajánlás" és felülbírálhatod.

Hát én biztosan nem használnék (és nem buzdítanék senkit a használatára) 007-es umaskot, legaláb 027 legyen, hogy véletlenül se jöjjön létre csoport által írható fájl, illetve csoport irásjoggal megáldott könyvtár (mert ugye onnan akkor már törölhet is). Ha kell, utólag odateszem azt a jogot. Elvenni a kutya se fogja, ha véletlenül több joga lett valaminek.
Az utolsó mondatod meg rendesen félreérthető. Az umask-ot nem lehet felülbírálni - amikor egy adott umask beállítás van évényben, akkor a *létrehozás* pillanatában érvényes. Amit az umask kapcsán tudni kell, az az, hogy

- hiába állít be a rgazda tetszőleges umask értéket, ha van shell és umask hozzáférésem, ezt a beállítást módosíthatom - de amíg nem teszem meg, addig az övé van érvényben, utána meg az enyém;

- meglevő fájlokon pedig már nincs jelentősége az umask-nak, hisz arra ott a chmod.

De fenti 2 pont egyikét se kommunikálnám úgy, hogy az umask felülbírálható.

Először is elnézést kérek, ez nem az én napom volt! Írom össze-vissza a marhaságokat.

Szóval amit írni szerettem volna :) a következő. "Single user" alkalmazásban 077, group átjárással pedig 037 a használt umask értéke. A peremfeltételek: Az első esetben nincs másnak hozzáférése, a másodikban a group egyes dolgokhoz hozzáfér olvasás, esetleg végrehajtás joggal. Dir nem keletkezhet, legalábbis olyan helyeken, ahol valamilyen group jog is van. Azaz minden dir előre és megfelelő szigorral elkészítve. A nincs/van másnak hozzáférése úgy működik, hogy a teljes dir struktúra a főnöké, ami maga a szerver alkalmazás és környezete. Ez azért elég homályos. :) Megmutatom a gyakorlati példát, ami egy ftp adatgyűjtő szerver, amelyre az "user" felküld adatokat. Tehát:
Az user pl. user1:usersrgroup
A home user1home=server:servergroup 750 + acl=user1:500
A felküldendő file bekészítve file=server:servergroup 600 + acl=user1:200
- Szóval hiába lopnád el a jelszavát, még az user1 sem tudja olvasni, amit küld. Ugyanúgy a group tagok sem.
Ha a felküldendő file mérete növekszik -> acl=user1:000 , és ez addig marad, amíg a szerver fel nem dolgozta. Az ftp közben a file már nyitott, így az átvitel befejeződik. Persze a 037 umask csak a group ellen véd, viszont a védett adatokat az ott alkalmazott 700 jogosultság miatt nem érik el.

A felülbírálat alatt csak annyit értettem, hogy umask 077 esetén az mkdir 700-at készít, de mondhatsz ilyet is: mkdir -m 770. Gondolom egy open(,O_CREAT,) után hívnak egy chmod()-ot. Tényleg igazad van, mert az umask változatlan, csak a miatta kialakult érték más eszközzel módosítható.

Azért a 037-nél felszaladt a szemöldököm, de mivel hozzáteszed, hogy "Dir nem keletkezhet ..." meg hogy ACL, így üsse kő elfogadható. ACL nélkül sajnos nem, mert a felhasználók (meg a rendszergazdák) nem hajlandók megtanulni helyesen beállítani a jogokat. Gondolok itt a mindenhol megjelenő chmod 777-re, ami egy teszt kapcsán még csak-csak - de ugye úgy marad -, élesben viszont szívroham.

No, erre meg nekem szaladt föl. :) A rendszergazda keze igen hamar gipszben találná magát, ha az általam, vagy bárki más által szállított rendszerben jogosultságokat állítgatna. Az alkalmazás környezetéért és a kezelt adatok biztonságáért az alkalmazás és szállítója felel, míg a rendszergazda csak betartja a szabályokat.
Kedvencem a sudo! Alacsony biztonságú és trehány rendszeren egy újabb felesleges dolog. Vesd össze pl. a uucp group-pal, amikor a member nem éri el a modem eszközt, de tud olyan programot futtatni, ami használhatja. Ez egy tervezett jogosultság, a sudo meg gondolkodni nem tudó ember kezében egy visszafelé elsülő fegyver is lehet. És ez jócskát túlmutat a 777-en!

file_permission = max_file_creation_permission & umask

Ami persze nincs így. Mondom, az umask 1-es komplemensével csinál logikai AND kapcsolatot. Ha úgy lenne, ahogy írtad, akkor nem lenne read jog 0022-es umask-kal létrehozott file-okon.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE