Fórumok
Sziasztok,
Az lenne a cél hogy az újonnan létrejövő fájlok örököljék a szülő ACL-jeit,
erre megadtam a -d kapcsolót a setfacl-nek.
Így néznek ki jelenleg egy könyvtár ACL-jei:
# owner: root
# group: root
user::rwx
group::r-x
other::---
default:user::rwx
default:user:user_name:rwx
default:group::r-x
default:group:group_name:rwx
default:mask::rwx
default:other::---
A "group_name" tagjainak nincs rwx joga, nem értem miért.
A default ACL-ek nem jelentenek egyből effektiv hozzáférést vagy nem értek valamit? :)
Köszönöm!
Hozzászólások
A default ACL arra vontakozik, amit a könyvtárba fogsz csinálni, nem magára a könyvtárra.
Adtam a csoportnak jogot a könyvtárra ÉS meghagytam a default-ot is az öröklödő fájloknak.
Igy néz ki most egy másik user által bemásolt fájl ACL-je:
"csoport" tagja így be tud lépni a könyvtárba de a fájlra nincs joga, pedig ott
Szülőkönyvtár ACL-je:
Szerintem a
mask:---miatt van, hogy azeffective:---Az viszont érdekes, hogy ha a
default:mask:rwx, akkor a fájl miértmask:---opcióval jött létre.Igazad lesz
Nekem sem tiszta hogy a "default:mask::rwx"-ből hogyan lesz #effective:---
Valószínű a cptől, az viszi a létező fileok jogait, és az automatikusan megy a maskba.
Amennyire emlékszem, ez sajna ilyen szopó, az aclek... Szóval nem az igazi az egész.
Nem ez volt, standard permission-ök közül csak a tulajdonosnak és a csoportnak volt joga, senki másnak.
Az új fájl tulajdonosa és csoportja más volt, hiába az ACL adott volna jogot neki, ha a chmod ezt kilökte.
Ha chmod 777 a szülő akkor az effective permission szépen megy ACL alapján.
Azt hittem hogy az ACL felülcsapja a chmod-ot, de nem: mask a kettő kombinációja.
Viszont, itt megint elakadtam: a terv az lett volna hogy chmod 777 a szülőre, ACL-ben pedig csak az érintett csoportoknak és felhasználóknak adok jogot, other pedig ---.
Így akkor az érintett csoportok és felhasználók megkapták volna ACL alapján a jogot, chmod ebben nem korlátozza őket.
A probléma hogy a chmod-ot nem tudom örököltetni az új fájlokra, ellentétben a default ACL-el.
Igy a user odamásolja a cuccát a saját chmod-jával SCP-vel, default ACL ugyan adnak jogot, de ezt a chmod kilöki.
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.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Köszönöm hogy részletesen leírtad, továbbra sem értem a chmod - acl - mask kapcsoltát.
Leírom hogy mit csinálok hogy megértsd.
Adott egy mappa ami root:root és 770.
Ezek az ACL-ek vannak beállítva:
# owner: root
# group: root
user::rwx
user:user:rwx
group::r-x
group:group:rwx
mask::rwx
other::---
default:user::rwx
default:user:user:rwx
default:group::r-x
default:group:group:rwx
default:mask::rwx
default:other::---
Ez itt még az elvárható módon müködik, a probléma akkor jön elő ha létrejön benne egy új fájl:
root:root és 600
# file: informatica_filesharing/sbxdev/simplifi/r360/idmc_fileshares_list.json
# owner: root
# group: root
user::rw-
user:user:rwx #effective:---
group::r-x #effective:---
group:group:rwx #effective:---
mask::---
other::---
Azt gondolnám hogy a mask örökölni fogja a "default:mask::rwx"-t, de nem ez történik.
Csak úgy tudom kibillenteni ebből az állapotból ha kézzel megadom a mask-ot vagy chown-al szélesebb jogosultságot adok a 600-nál.
Az lenne a cél hogy a user akármilyen fájlmatatóval másol oda cuccokat, ne kelljen neki chown-olnia mert az ACL delegál hozzáféréseket.
> Köszönöm hogy részletesen leírtad, továbbra sem értem a chmod - acl - mask kapcsoltát.
Pedig nagyon egyszerű:
a chmod és az ACL egymással abszolút semmilyen kapcsolatban nincsenek. Az ACL *csak* akkor hat, amikor létrehozol egy fájlt és soha később (ugyanúgy, mint az umask); a chmod pedig bármikor később hat - amennyiben a fájl már létezik.
A valódi probléma még mindig az, hogy a fájl létrehozásakor (ekkor umask / ACL van érvényben) te azt nem tudod megmondani, hogy mit szeretnél, csak azt, hogy mit NEM, ugyanis ezt határozza meg az umask.
umask 077 jelentése: tulajnak nem tiltunk semmit; ellenben nem engedem, hogy a a fájl csoportjogai, és a fájl egyéb jogai közül is bármi be legyen állítva. Ami nagyon nem azt jelenti, hogy a tulajnak lesz rwx, mert itt viszont mint írtam, a létrehozó szoftveren múlik. Ha az a tulajnak rwx-et állít, akkor azok mind megmaradnak. De ha a szoftver csak rw-t, akkor nem lesz a tulajnak x joga. Ha a szoftver rx-et állít, akkor meg az írásjog fog hiányozni a tulajtól (is).
umask 027: tulajnak nem tiltunk semmit; csoportnak nem engedjük az írást; mindenki másnak *semmit* sem. (De változatlanul nem jelenti azt, hogy a tulajnak meglesz minden joga, vagy hogy a csoportnak biztosan lesz pl. olvasási joga.)
umask 002: tulajnak és csoportnak semmit nem tiltok, mindenki mástól tiltom az írás jogot. (De változatlanul nem jelenti azt, hogy a tulajnak meglesz minden joga, vagy hogy a csoportnak biztosan lesz pl. olvasási joga.)
umask 700: klasszikus hiba: a tulajtól minden jogot megtiltunk, senki másnál nem tiltunk semmit.
No most ha van ACL, akkor a mask ACL is hat, azaz nem csak az umask-kal tudsz a létrehozáskor korlátozni, hanem a mask-ACL-lel is. (Annyi a nehezítés, hogy a mask-ACL egyaránt hat a tulajra is, meg mindenki másra is.) És ami külön öröm, hogy az umask a default mask ACL-ből eredeztetett mask-ACL-re is hat :-(
Mutatom a példát. Van egy mask-ACL-lel és default-mask-ACL-lel rendelkező, üres könyvtár. Csinálok benne két fájlt, az első esetben van valami halvány umask (002), a második létrehozásának idejére viszont ideiglenesen 000-ra teszem az umaskot, azaz semmit nem tiltok.
$ rm -f ACL/*
$ umask
0002
$ touch ACL/p1
$ ( umask 0 ; umask; touch ACL/p2 ) ; umask
0000
0002
$ getfacl ACL ACL/p?
# file: ACL
# owner: zgabor
# group: zgabor
user::rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:tss:r--
default:group::rwx
default:mask::rwx
default:other::r-x
# file: ACL/p1
# owner: zgabor
# group: zgabor
user::rw-
user:tss:r--
group::rwx #effective:rw-
mask::rw-
other::r--
# file: ACL/p2
# owner: zgabor
# group: zgabor
user::rw-
user:tss:r--
group::rwx #effective:rw-
mask::rw-
other::r--
És ha megvizsgáljuk a két fájt, az látszik, hogy nincs semmi különbség. Viszont az is látszik, hogy noha senki nem tiltotta a futtatási jogot, egyik fájlon sincs futtatási jog, ráadásul az x-jog a (default-mask-ACL-ből származó) megörökölt mask-ACL-ből is elveszett.
Miért veszett el?
Ennek megértéséhez még egy kis példa. Az előzőek után az umask 0002-n áll, és létrehozunk még egy fájlt olyan módon, aminél a létrehozó program eleve be akarja állítani a futtatási jogot (erre nagyon alkalmas egy fordítóprogram, ami *futtatható* állományt csinál).
$ tcc lo.c -o ACL/lo.tcc
$ getfacl ACL/lo.tcc
# file: ACL/lo.tcc
# owner: zgabor
# group: zgabor
user::rwx
user:tss:r--
group::rwx
mask::rwx
other::r-x
És mit látunk? A fájlon (tulaj, csoport és egyéb) van x-jog, ráadásul a default-mask-ACL -ből örökölt mask-ACL-ben is megmaradt.
Azaz hiába, hogy a default-mask-ACL-ben te mindent engedsz, mert ha a létrehozó program tilt bizonyos jogokat, akkor már a megörökölt mask-ASL-ben is hiányozni fog a megfelelő jog. És hasonlóan, az umask is tilt bizonyos jogokat. Sajnos az umask lekérdezhető, de hogy egy konkrét program pontosan milyen jogokkal akarna egy fájlt létrehozni, azt max. tesztekkel, vagy a forrás tanulmányozásával lehet kideríteni.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Pont az a baj az ACL-el hogy noha az egyetlen lehetőség hogy örökletes jogosultságokat lehessen érvényesiteni,
erre alkalmatlan mert a default mask nem jelent kizáróságot a mask létrejötténél, hiszen azt a chown-ban beállított jogosultságok is meghatározóak.
Hogy mégjobban inkonzisztens legyen: a mask kézzel felülírható a fájl létrejötte után (itt pontatlan voltál abban hogy az ACL csak a fájl létrejötte után hat), így a chown-al való kapcsolatát is elveszti.
Ha maradok az ACL vonalon, incrontab-al felülírom a jogosultságokat egy fájlrendszer-eseménynél (ha még támogatott, lassan 10 éves lesz az utolsó release).
Windows-ból jött emberként nem tudok más mondani: pocsék ez a permission modell és igény sincs a kernelfejlesztőkben a fejlesztésére.
"Windows-ból jött emberként nem tudok más mondani: pocsék ez a permission modell és igény sincs a kernelfejlesztőkben a fejlesztésére."
Az {u,g,o}x{r,w,x} modell volt az alap, az ACL-ek erre "rakódtak rá" idővel, mert kiderült, hogy annál több kell - mindezt úgy, hogy visszafelé kompatibils maradjon, azaz kezdve a creat() -tal ne törjön el semmi...
Az adott könyvtárra is tegyél egy mask rwx-et.
Default-al öröklődik, erre kell építenem mert új fájlokat fognak elhelezni a mappában.
Mask miatt egyszerűen nem tudom megoldani azt hogy több csoportnak és felhasználónak külön definiálok ACL-el jogot
úgy hogy azok öröklődjenek és kizárható legyen minden más hozzáférése.
Ha chmod-al everyone nem kap jogot, ACL-s jogosultság kizáródik (effective), ha kap akkor viszont felülírja az ACL-eket.
> Default-al öröklődik, erre kell építenem mert új fájlokat fognak elhelezni a mappában.
Az öröklődő mask, és a könyvtár saját maskja 2 különböző dolog.
> Mask miatt egyszerűen nem tudom megoldani azt hogy több csoportnak és felhasználónak külön definiálok ACL-el
Ezzel rohadtul nem értek egyet, speciel ha egy fájlra / könyvtárra akarsz adni user:joska:XYZ vagy épp group:joskaespista:IJK tipusú ACL-t, akkor kötelező mask-ot is adni hozzá . Ha pedig mask::rwx -et kap, akkor legalább nem fogja korlátozni amit beállítottál.
Csak nagyon halkan kérdem, a man 5 acls megvolt már? Tudom, hogy elég ronda, meg főleg hosszú, és még angolul is van, de elég részletesen leírja, hogy hogyan kell elképzelni ezt az egészet.
És csak úgy magamban mormogom, hogy ha valaki ACL-ezni akar, akkor szokjon le a chmod-ról, helyette használjon setfalc -t (és getfacl -t). Elvben keverhetőek, de az elmélet és a gyakorlat nem mindig egyezik. (Nem Linux volt ugyan, de én pl. találkoztam olyan implementációval, ahol ha volt ACL, akkor dokumentáltan tiltott volt a chmod, mert *eldobta* az "extra" ACL-eket.)
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Default maskot állitottam be mert a szülőkönyvtár alatti struktúra nem állandó, ez szerepel is a fenti hozzászólásomban:
Ez mellett a csoport nem kap addig effektiv hozzáférést amig chown-al el van véve minden jogosultság az everyone-tól:
Amint everyone kap RWX-et, a csoport effektive hozzáférése RWX lesz.
Eszem ágában sem volt keverni a chmod-ot az ACL-el, de nem tudom hogyan lehetne ezt kikerülni, ebben a konkrét esetben.
Félreérted. Magára a mappára nem csak default:mask::XYZ adható (ez fog öröklődni), hanem mask::IJK is. Mutatom:
$ getfacl ACL
# file: ACL
# owner: zgabor
# group: zgabor
user::rwx
group::rwx
other::r-x
default:user::rwx
default:user:tss:r--
default:group::rwx
default:mask::rwx
default:other::r-x
$ setfacl -m mask::r-- ACL
$ getfacl ACL
# file: ACL
# owner: zgabor
# group: zgabor
user::rwx
group::rwx #effective:r--
mask::r--
other::r-x
default:user::rwx
default:user:tss:r--
default:group::rwx
default:mask::rwx
default:other::r-x
Attól, hogy adtam (egy korlátozó) mask ACL-t a mappára, máris másként működik a csoportjog (magán a mappán)!
Nem kezdtem el kiszámolni a te esetedben, de nekem is az a véleményem, mint fentebb a kollégának, hogy az egész hóbelevanc tetején levő mappára kellene egy mask::rwx ACL pluszban, és akkor talán már elkezdene jól működni. Értelemszerűen miután megkapja a mappa a saját (tehát nem az öröklődő, default) mask-ACL-jét, az ezt követően létrehozott fájlokon lehet tesztelni, hogy az öröklés jól működik-e. Nyilván a már ott levő fájlokon már nem oszt-nem szoroz.
(Legalább az eredeti kérdésben és egy hozzászólásban szerepelnek nálad konkrét ACL-ek, de mivel a nagy adatbiztonságban - valószínűleg - mind a kettőben lecserélted a valós felhasználó és csoportneveket, de nem ugyanarra, ezért elég nehéz a valós helyzetet kiszámolni.)
Kieg:
a chmod-ot úgy kell kikerülni, hogy jól beállítjuk a tetejét (azaz kap a felső mappa mask::rwx ACL-t), utána beállítjuk az öröklődő (tehát default: kezdetűeket is, nem kihagyva a default:mask::rwx ACL-t sem). Valamint ha valami chmod-ra lenne szükség, akkor minden chmod helyett a neki megfelelő setfacl ACL1,ACL2,ACL3 parancsot használjuk. Például chmod 751 filename helyett ezt:
setfacl -m user::rwx,group::rx,other::x filename
Azaz:
ACL1 = user::rwx (vagy amit akarsz)
ACL2 = group::rx (vagy amit akarsz)
ACL3 = other::x (vagy amit akarsz)
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Ha megnézed a szülőkönyvtár ACL-jeit, ott a maszk explicit megadva:
Ennek ellenére egy újonnan bemásolt fájl maszkja már --- lesz:
Mivel másolod/hozod létre a fájlt?
A "baj*" az, hogy a mask gyakorlatilag a fájl létrehozáskori group permissiont kapja (de ettől még maga a group permission megkapja a defaultot). Touch-nál pl. MODE_RW_UGO, így a mask RW lesz. Ha cp-vel másolsz valamit, aminek a group perm-je pl. csak r, akkor a mask is r lesz.
*baj: valaki szerint ez nem baj, sőt, így helyes: https://serverfault.com/questions/352783/why-does-chmod1-on-the-group-a…
Röviden annyi lehet az értelme, hogy a létrehozó megad egy group permissiont, azt a default ACL felülírja, viszont a mask mégis "visszabillenti" az egyensúlyt a létrehozó szándékához (aki nem tud az ACL-ekről).
Amin lehet vitatkozni, hogy ez jó-e, sajnos látszik, hogy a POSIX ACL szabvány elhalt 98-ban, azóta sem gondolta utána senki. A default masknak így sok értelme nincs szerintem se.
Ténylegesen nincs kontrollom felette, de elő tudom írni hogy csak a WinSCP a támogatott mód a fájlok mozgatására.
WinSCP támogat chown-t (talán be lehet állítani default-ot is) és mivel felülről zárt a szülő, így nem tudja elcseszni a jogosultságokat,
de pont ezt a kézimunkát szerettem volna elkerülni.
Elbaszott nagyvállalati környezet, ne keress logikát mögötte.
Erre jutottam én is, default mask-nak így nincs tényleges szerepe.
Szerver oldalon megpróbálhatod az sftp szervernek megadni az umaskot (már ha sftp módban használod a winscpt, ami mondjuk ajánlatosabb, mint az scp).
Van ez a lassan legacyvá válló incron cucc amivel force-olható ACL vagy chown egy fájlrendszer-eseménynél.
sftp-server -u 000 nem működik?
Mivel mask=group perm, így ha a file g+rw-vel keletkezik, talán a mask is jó lesz.
File esetében milyen szerepe van a masknak, amiért ez fontos?
Mellesleg kipróbáltam, ahogy említetted, winscp, szóval van egy Debianom, winscp-vel rátettem egy file-t
# file: fileneve
# owner: owner userid
# group: groupid
user::rw-
user:egyexplicituser:rwx #effective:rw-
group::r-x #effective:r--
mask::rw-
other::r--
Az umask 022, a könyvtár acl-je:
# file: .
# owner: owner userid
# group: groupid
user::rwx
user:explicituser:rwx #effective:---
group::r-x #effective:---
mask::---
other::r-x
default:user::rwx
default:user:explicituser:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
Ez ugye az ACL mask, ami az effective permissiont határozza meg a fájl esetén. Könyvtáron levő umask-nak nincs szerepe az alatta levő fájl esetén.
A fájl milyen jogosultságokkal (chmod) van létrehozva a könyvtárban?
Mint írtam, 022 az umask. Az umask nem könyvtáron van, hanem rendszerszinten vagy legalábbis felhasználószinten definiálva. Az nem az ACL mask. 022-es umask esetén egy file automatikusan 644-gyel jön létre egyébként.
Nem kötekedés, pontosítás:
> 022-es umask esetén egy file automatikusan 644-gyel jön létre egyébként.
Nem, hanem csak annyi biztos, hogy nem lesz csoport+egyébnek írás joga. Fenti (hosszú, ACL-es) példa is mutatja, hogy ha az alkalmazás azt akarja, akkor lesz neki x-joga (azaz nem 644, hanem 755), de ez még mindig azon múlik, hogy az alkalmazás amelyik meghívja a creat("fnév", jogok) rendszerhívást, mit tett a jogok-ba. Szoktak oda 666-ot, 644-et, 640-et vagy 600-at írni, de írhat oda a fejlesztő akár 700-at is (sőt 077-et is), és azt fogja tovább szűkíteni az umask.
Fordítsd le és futtasd le a következő kódot, és ellenőrizd a létrejött fájl jogait. (Minden futás előtt törölni kell a teszthez :-) )
#include <stdlib.h>
main() {
return creat( "/tmp/proba.lo.jogok", 0123 );
}
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Öröklődik. De mi, ha nincs? :O
Sikerült megakadnom valamiben, hátha valakinek van ötlete.
Adott egy fájl ami így jött létre:
A cél az lenne hogy a "csoport" csoport tagjai csak olvasni tudják a fájlt.
CHMOD biztosan nem ad írási jogot, ACL az érintett group is csak r-x-t, de a csoport tagjai továbbra is képesek törölni.
Levettem az wx-et a maskról és a userről, így néz ki most:
Továbbra is képesek törölni.
Itt már csak arra tudok gondolni hogy a szülőkönyvtár ACL-el biztositott joga (ott valóban van RWX a csoport) érvényesül,
akkor is ha a benne levő fájlra explicit nincs joga.
Tehát az effektive jogosultságot a getfact egyszerűen kihagyja.
Így néz ki a szülő:
Lehet ezzel bármit kezdeni, ha csak egyetlen fájra akarom korlátozni az irást,
de az érintett könyvtárban a csoport tagjainak képesek kell lennie új fájlokat létrehozni, majd az módositani?
Hint: mit is jelent a fájl törlése? Mit ír ilyenkor az user processze?
Amit az sftp lib-je az openssh-nak meghív, amikor törlök egy fájlt. :)
Az meg az unlink(2)
" The unlink(2) system call rm is using to remove a file does only care about the permission of the containing directory, with some exceptions like when the directory has its sticky bit set "
Ott a pont...