>> "Es lehet azon sajnalkozni, hogy nincs ennel bosegesebb allitasi lehetoseget biztosito FS"
> Van, NTFS a neve.
A szovegkornyezetbol ki kellett volna deruljon, hogy UNIX-like kornyezet alatt ertettem a dolgokat, de termeszetesen igazad van. Mindazonaltal egyelore nem lattam semmilyen UNIX-like kornyzeteben nativ-NTFS tamogatast, amire az emberek az adataikat is ra mernek bizni (mondjuk / , /boot, /usr es hasonlok). De ha a vilag ennyire nem toleralja az ugo/rwx -et, akkor eltelik egy-ket ev, es a legujabb Ubuntu mar nativan NTFS6-ra formazza a VXVM-es koteteinket a linuxos szerveren.
Ellenben egy kis ellenkezes:
> a normalis appok ugyis access(2) rendszerhivassal csekkoljak a jogokat
Az sajnos nem jo. Idezet man 2 access, FreeBSD:
SECURITY CONSIDERATIONS
The access() system call is a potential security hole due to race condi-
tions and should never be used. Set-user-ID and set-group-ID applica-
tions should restore the effective user or group ID, and perform actions
directly rather than use access() to simulate access checks for the real
user or group ID. The eaccess() system call likewise may be subject to
races if used inappropriately.
Van ott mas is, de ez a lenyeg: ne ellenorizd elore, hanem probald megcsinalni az adott muveletet es korrekten kezeld le az esetleg visszakaphato EACCESS hibakodot. Azt, hogy sechole hogyan lesz, azt nem tudom, de mit fog kezdeni a szoftvered azzal, ha az access, es az ot valamikor kesobb koveto open (vagy barmi egyeb) muveleted kozott: remountolja valaki RO-ba az FS-t; chmod-dal megvaltoztatja a fajl vagy a path valamely tagjanak a jogat; chown-nal tulaj/csoportvaltas tortenik; es i. t.? Mivel az access fajlnevet var es nem FD-t vagy FILE* -ot, ezert ez a helyzet siman fennallhat. Mivel ez fennallhat, a szoftvered kenytelen lekezelni az open/egyeb eseteben az EACCESS hibakodot - node akkor mi a francnak probalta az access-t? (Speciel kb ugyanez a helyzet a stat(2)-vel is, de ott legalabb van fstat(2), ellenben faccess(2) nem letezik - meg ugy kb minek.)