[hpc] egy kis oh, izé... küzdelem

A gondolat az volt, hogy az 59 számoló node az lehetőleg egyforma konfiggal legyen.
Sajnos a teljes egyformaság nem megvalósítható, mert legalább a /etc/hostname és a /etc/udev/rules.d/70-pers* egyedi.

A másik gondolat az volt, hogy a számoló node-okon 'gyári' oprendszer legyen, vagyis a disztribúció által csomagolt kernel/initramfs és egyeb csomagokhoz sem nyúlok hozzá.

Emiatt választottam az union fs megoldást, konkrétan az aufs -t. Volt egy master (template) branch, amiben benne volt egy teljes oprendszer, valamint volt 59 node specifikus branch, amikben benne voltak a /etc/hostname -k. Minden kliens pxeboot, nfsroot megoldással működik.

Ez lett 59 nfs root export az 59 gépnek.

Esett? esett. Potyogott, hasalt, fagyott, dőlt. Ha belenyultam a master branchba, akkor véletlenszerűen elestek a kliensek (file id change). Mostanában jóval több konfiguráció módosítás érkezik, nem elfogadható, hogy az apt-get -hez bootolni kell. Nekiálltam megtalálni a hibát. Nem volt reprodukálható 2 node-on (1 kliens, egy szerver). És nem volt másik 59 node-os clusterem tesztelni. Meguntam (elfogyott a rá áldozható időm), megálmodtam, hogy jó lesz nekem az rsync.

NFS szerveren belüli rsync segítségével példányositom a master branchet, sok helyet sem foglal, az rsync nagyon ügyesen tud hardlinkelve directory struktúrát másolni.

Minden jó és szép, kikerül az aufs a képből, nem fog az nfsd csodálkozni, nem fog elesni a kliens.

és akkor nem ment az rsh. (igen, clusteren belül rsh -t használunk)
mert, a pam_rhosts.so által hívott, libc -ben implementált ruserok() függvény nem hajlandó felolvasni a /etc/hosts.equiv file-t, ha annak hard link countja nem 1.

aztszem 1983 -ben írták ezt a kódot. (University of California).

Milyen már olyan kódot írni, ami 28 év után is megszopatja a T. usert? Azóta töröm a fejem, hogy milyen biztonsági kockázata volt vagy van annak, ha a hardlinkcount nem 1.

( Zahy v | 2012. 04. 04., sze – 19:21 )

Újabb matuzsálemi korú BSD-bug? Bár ez talán nem sechole.

( wauf | 2012. 04. 04., sze – 19:34 )

> Milyen már olyan kódot írni, ami 28 év után is megszopatja a T. usert?

Ez nem bug, hanem feature. Azon kodsorok megirasa kemeny mernokorakba telt (sehol nem voltak a modern kodkiegitos IDE-k, a kodot review-zni, tesztelni kellett, stb.)

Szerintem valahol valamikor valakinek valami baja volt azzal, hogy a hardlink count akarmennyi lehet, es lekodoltatta a "fixet". Aztan valahogy a nyakunkon maradt, es az eredeti koncepcio felett pedig mar reg eljart az ido.

( Replaced | 2012. 04. 04., sze – 20:46 )

magic symlink nincs linuxra? :)

--
NetBSD - Simplicity is prerequisite for reliability

( uid_2716 | 2012. 04. 04., sze – 23:26 )

man 5 hosts.equiv 


NOTES
       Some  systems  will  only  honor  the contents of this file when it has
       owner root and no write permission for anybody else.   Some  exception-
       ally paranoid systems even require that there be no other hard links to
       the file.

A támadás/félelem itt az, hogy ha valami susmus helyen van egy hardlink, akkor egy rekurzív chown/chmod (ami az inode-ot érinti) megváltoztatja az "eredeti" hozzáférési jogokat is. Hardlink létrehozása nem (feltétlenül) privilegizált, lásd a link() specifikációjában:

These functions shall fail if:

[EACCES]
A component of either path prefix denies search permission, or the requested link requires writing in a directory that denies write permission, or the calling process does not have permission to access the existing file and this is required by the implementation.

(Kiemelés általam.)

Szóval válasszunk egy 644/root:root jogosultságú/tulajdonú file-t az /etc alól, mondjuk legyen ez az /etc/passwd, majd mezei felhasználóként (feltéve, hogy a /tmp és az /etc azonos fs-en vannak): 


cd /tmp
mkdir -pv -- "$LOGNAME"
cd -- "$LOGNAME"
ln /etc/passwd .

Ha a root most lefuttat egy rekurzív chmod/chown parancsot a 

/tmp/"$LOGNAME"

-en, esetleg beleír valamit az ott lévő file-okba, abból baj lehet.

... Legalábbis ez a tippem.

Kiegészítés: ennek a vizsgálatnak persze nem sok értelme van, mert az extra hardlink létrehozható közvetlenül az fstat() lefutása után is.

Some exception-
ally paranoid systems even require that there be no other hard links to
the file.

neha olyan jo lenne, ha mellettem dolgoznal. A manualt nagyjabol 30-szor olvastam vegig, google is befigyelt, aztan kicsereltem a pam_rhosts.so -t pam_permit.so -ra, aztan lecsereltem az in.rshd -t egy 'ltrace -S' verziora, aztan athivtam 2 kollegamat, keressuk kozosen a hibat, aztan letoltottem a pam_rhost.so forrasat, aztan tesztprogramot irtam a ruserok() hivasara, aztan az eglibc forrasat is letoltottem, ugy lett meg.

Egyebkent most az a gyanum, hogy volt egy olyan filesystem, ahol a direntry tartalmazott security informaciokat, nem csak az inode, emiatt lehetseges volt, hogy a hardlinkje irhato egy egyebkent nem irhato file-nek. Nem magatol ertetodo, hogy szeparalt inode-tablaban kell minden metaadatat tartalmaznia egy file-nak.