( Zahy | 2024. 05. 23., cs – 16:48 )

Itt valami nagyon el van kavarodva az alapokkal. chmod mondható létező fájlra, de nem öröklődik. A cp pedig csak akkor viszi át az eredeti jogokat, ha az ember külön kéri ezt (az egyéb - pl. guis szarok viselkedését meg meg kell nézni a forrásban). És akkor még ugye nehezítés az ACL-eknél a az ACL_MASK, illetve a default ACL.

Hagyományos (ACL-telen) esetben:

Amikor egy könyvtárban létrejön egy új fájl, akkor ott nem a chmod, hanem

 

1. a fájlt létrehozó alkalmazás írójának agybaja

2. a fájlt létrehozó felhasználó umask beállítása

 

azok, amelyek (ebben a sorrendben) számítanak. És azt lehet mondani, hogy a legelső ponttól indulva, egyre csökkennek azok a jogok, mert ami az umaskban tiltva van, az nem lesz meg a végeredményben (umask 027 esetén tiltva van a csoport írás, és az egyéb kategória minden létező joga - azaz a létrejövetel pillanatában biztosan nem lesz a tulajon kívül senkinek írás joga, a tulajról meg nem tudunk semmit).

Azaz: ha a cp paranccsal rakok oda egy új fájlt, akkor a cp leprogramozója, ha vi fájlnév módon csinálok ott egy új fájlt, akkor a vi írója, ha touch newfilename formával csinálok, akkor a touch fejlesztője, ha pedig egy guis szarral, akkor annak a programozójának az agybaján múlik a dolog (*). Ha a programozó a létrehozásnál azt adta meg, hogy u=x,g=r,o=w (numerikusan: 0142) - ami egyébként gyakorlatilag engedélyezett, de  baromság -, akkor az a fájl semmilyen umask beállítás esetén nem fog a=rwx (azaz 0777) joggal létrejönni. Utólag pedig módosítható a chmod-dal (vagy a setfacl-lal).

(*) hagyományosan azt szokták javasolni, hogy a programozó könyvtár létrehozásakor (mkdir(2) rendszerhívás) 0777-et, egyéb fájltipus esetén (creat(2), mknod(2), mkfifo(2) vagy open(2) - O_CREAT flaggal rendszerhívások) pedig 0666-ot adjon meg, illetve biztonsági megfontolások miatt 0755 illetve 0644 (azaz a tulajon kívül másnak ne legyen írás joga) a javasolt.

De utólag lehet chmod-dal módosítani a jogokat a kívántra, és *ekkor* *már* rohadtul nem számít az umask.

És akkor ACL:

(Jó bonyolult, részletesen le van írva man 5 acl oldalon.)

- Ha van user:X:rwx és / vagy group:Y:-w- tipusú bejegyzés az ACL-ek között, akkor kell, hogy legyen mask::rwx ACL (és nem elegendő a default:mask::rwx). Lásd hivatkozott manual "VALID ACLs" bekezdése.

- Öröklődéshez kellenek a default ACL-ek.

És akkor mindehhez jön az, hogy

- milyen kapcsolat van a klasszikus (chmod-dal állítható) fájl jogok és az ACL-ek között (man 5 acl "CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS")

- és hogyan hatnak a default ACL-ek egy mappán belül létrehozott fájlok jogaira (man 5 acl "OBJECT CREATION AND DEFAULT ACLs")

- és ha ez is mind megvan, akkor jön a man 5 acl -ben a "ACCESS CHECK ALGORITHM", ami szépen lépésről lépésre leírja, hogy hogyan is megy ez akkor ha van mask-ACL, meg ha nincs; miben más pl. a csoporthozzáférés kezelése, mint ACL-nélküli esetben; és í. t.

Kis kieg:

Linuxon tapasztalatom szerint a setfacl háklis: user:VALAKI:jogok vagy group:VALAMI:jogok tipusú ACL-t nem adhatsz hozzá addig, amíg nincs a fájlnak mask-ACL-je (a FreeBSD pedig - hacsak nem tiltod meg neki - generál valamilyen mask-ACL-t). Továbbá a FreeBSD manual legyértelműen leírja, hogy csak akkor tudsz tetszőleges default ACL-eket hozzáadni a fájlhoz, ha vagy már van, vagy a parancsban megadod a default user::jogok,group::jogok,other::jogok ACL-eket is: azaz ezekból  is kell lenni default-nak ahhoz, hogy egyéb defaultokat is definiálhass. Linuxon mintha ez vagy nem kellene, vagy ilyenkor behaluzik valamit.