Köszi a hozzászólást. A múltkor, amikor az IRC-n volt szó arról, hogy az új 3.x kerneleknél a /proc fájlrendszerben változhat a fájlok inode-száma, és ez megzavarja az RBAC-ot, akkor felmerült bennem a gyanú, hogy nem teljesen path alapú a Grsecurity, de biztos vagyok benne, hogy a működése nagyon eltér a SELinux-étól.
A SELinux-nál maga az inode hordozza a hozzáférési infót xattr-ok formájában, úgyhogy nem hiszem, hogy ott szükség lenne a vfsmount-ra is (a vsfmount-ot az AppArmor és a Tomoyo használja, de nem inode-dal, hanem dentry-vel párban). Az xattr-ok shutdown után is megőrzik az infót, a Grsecurity-nél viszont nem találtam xattr-okat a `getfattr --dump --match= FÁJLNÉV` paranccsal, úgyhogy biztos futásidőben állítja össze az inode-okat tartalmazó adatstruktúrát. Az igaz, hogy az első aktiváláskor a SELinux is fájlnevek alapján osztályozza és címkézi fel a fájlrendszert, az viszont percekig tart, a Grsecurity RBAC viszont egy másodpercen belül beröffen, tehát nem hiszem, hogy a memóriában tárolt inode-táblája ugyanúgy lefedné a teljes fájlrendszert, mint ahogy a SELinux teszi azt az xattr-okkal. Én úgy sejtem, hogy inkább on-the-fly rendel metainfókat az inode-okhoz az első hozzáféréskor. A doksiban sajnos nem találtam semmi erre vonatkozó adatot. Nem tudnád röviden összefoglalni, hogy működik pontosan?
Egyébként még tovább növekszik a SELinuxhoz viszonyított különbség az által, hogy a Grsecurity-ben ugyanarra a fájlra különböző jogok vonatkozhatnak, ha más path-on (hard link) keresztül hivatkozunk rá.