Fórumok
Sziasztok!
Adott egy parancssorban futó nagy, összetett programrendszer.
Bizonyos fájlok neveit megváltoztattuk a fejlesztés során.
A kérdés: hogy lehet azt figyelni, hogy a régi fájlnevekre történik-e megnyitási kísérlet?
Magyarán ha valahol közvetlenül be lenne drótozva egy fájlnév, amit megváltoztattunk, és így már nem létezik, valahogy a Linux képes ezt loggolni, hogy nem létező fájlra történt megnyitási kísérlet?
A fájlnevek néha kiértékelt kifejezésekből, string konkatenációkból vagy adatbázis tartalomból állnak elő, vagyis nem annyira egyszerű a dolog, hogy rákeresek a régi nevekre és már meg is van a hely, esetleg még használják.
köszönöm!
dio
Hozzászólások
Hat, egy EPERM vagy egy ENOENT tipusu hiba az annyira gyakori hogy nem valoszinu hogy ezt barmi ku"lo"n loggolna... Szvsz egy LD_PRELOAD alapon levo" kis shared object-et behuzne'k, ami az open()-re ra'kattan es ha az -1 ertekkel te'r vissza akkor loggolja a parame'tereit.
Szia, ez egy ragyogó gondolat, itt találtam egy érdekes leírást is:
http://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker-tricks-usin…
Ez vajon működik akkor is, ha a fájlt nem megnyitják olvasásra, hanem az operációs rendszerrel futtatják?
Jaja, ez jo leiras, ilyesmire gondoltam.
A file-t normalis esetben mindig egy program fogja megnyitni. Ha ezen program inditasa elott behuzol egy LD_PRELOAD-ot, akkor azt tudod figyelni. Hogy globalisan hogyan lehet engedelyezni az LD_PRELOAD-nak megfelelo funkcionalitast az jo kerdes, talan az /etc/ld.so.conf-ban be lehet allitani. De ezt nem nagyon javallanam, inkabb csak a ce'l-program kornyezete'ben kapcsolnam be eztet.
...Ha ezen program inditasa elott behuzol egy LD_PRELOAD-ot...
Az a helyzet hogy hálózatba van kötve kb húsz gép, amin állandóan futó szerverek adatokat cserélnek és programokat futtatnak - nem tudom biztosan, hogy ki lesz a fájleléréssel próbálkozó program, ezért gondoltam rá, hogy az operációs rendszer oldaláról keresnék megoldást.
Ltrace
Strace
Szia, az strace-t már néztem - lehet hogy én értettem félre a leírását, de az egy konkrét program megfigyelésére szolgál, amennyire megértettem - itt pedig nem létezik a fájl, és nem tudom biztosan hogy honnan jöhet a hívás.
Amit figyelni kellene: jön-e futtatási vagy olvasási kérés olyan fájlnévre, ami már nem létezik?
Ha a ``honnan jöhet a hívás'' egy adott program _vagy_ annak a child-processzei ko"zu"l kerul ki, akkor az `strace -f` segit (-f: fork). Ezen belul is tudsz szu"rni az open-re (`strace -e trace=open`).
Szia, egy nagy, több gépen futó összetett kommunikációs rendszerről van szó, nem tudom pontosan hogy honnan jöhet kérés egy fájl elérésére.
az ltrace egy adott parancsot futtat, és figyel meg, de én pont azt nem tudom hogy ki próbálhat elérni egy már nem létező fájlt.
Egy `strace -f -e trace=open -o /vala/hova/loggol/open.log ...` hivast azert meg lehet probalni egy-egy gepen futo rendszerre elhelyezni, aztan hatha ki lehet szu"rni az open.log-bol (grep, sed, stb-vel) hogy mikor volt ENOENT es/vagy EPERM.
Az strace egyébként jó ötlet, én is ezt néztem először.
inotify
igen, van egy IN_OPEN - open of file
esemény amit meg lehet figyelni, ez lehet hogy jó lesz!
Azt nem tudom, hogy nem létező fájlok esetében hogy megy, de majd kiderül.
Szia, kipróbáltam, pyinotify-vel:
https://github.com/seb-m/pyinotify
valóban jelez ha létező fájlhoz nyúlok, de nem jelez ha nem létezőt próbálok megnyitni.
viszont a régi fájlneveket vissza tudom állítani.
Így a pyinotify-vel elvileg elkapható, ha valaki hívja őket.
szerk: úgy értem, hogy újra létre kell hozni a régi fájlneveket, és figyelni egy ideig hogy hívja-e őket valaki.
Szia, viszont az nem látszik, hogy ki a hívó, csak az hogy valaki épp olvassa a fájl, pl ha futtatom.
lsof
Igen, ez jó, ha hosszan futó programokról van szó.
ha egy nem létező fájlt akarsz megnyitni, az szerintem nem lesz benne a listában.
viszont nagyon jó a gondolat, köszönöm, van éles rendszer ahol ezt lehet használni :-)
inotify + /proc/[pid]/fd
Szia, te voltál a gyorsabb, én csak most jutottam el eddig az ötletig, köszönöm!
:-)
Az a helyzet, hogy az eredeti probléma valószínűleg nem oldódott meg, de sok jó ötlet elhangzott, köszönöm, jó locsolást! :-)
dio
Merő kíváncsiságból: ez mennyivel jobb, mint az auditd?
Ami leírást találtam róla, ez csak egy kernel kiegészítés, amihez még jócskán kell dolgozni, hogy megtaláld, a megnyitni próbált, nem létező fájlokat. Az audit logjából meg percek alatt kiderül mindenféle programozás nélkül is. (végső esetben ausearch-t használva)
Tippre az auditd is ezt használ(hat)ja. Igazából csak az van, hogy én inkább programozó vagyok, nem sysadmin, nekem az eszköztáramban azok vannak, amiket írtam :-)
Függőségként nem szerepelt, ha jól láttam. :)
Persze ettől még lehet.
Csak azon törtem a fejem, hogy vajon mi gond lehet az audittal, hogy szinte sehol sem hallani róla, hogy használnák.
Pedig egy elég kellemes kis eszköz, ha a rendszerben való matatásokat akarjuk nyomon követni. (akár könyvtárak, fájlok stb. hozzáféréseit, akár pl. rendszerhívásokat)
Az inotify nem parancs, hanem rendszerhívás. Vannak tool-ok, amik használják, de nem kell hozzá csomag :-)
Van hozzá pár csomag, köztük egy inotify-tools. Illetve a doksi, amit megnéztem, azt írta, hogy kernelt kell patchelni a használatához. Persze lehet, hogy elavult iromány volt.
Már elég régóta benne van a kernelben. Az inotify-tools csak egy command line tool+interfész, de nem muszáj használni. Ettől függetlenül valószínűleg nem azt használja az auditd (jobban belegondolva elég nagy overhead-et okozhat).
Esetleg felraksz egy auditd-t és...
auditctl -aexit,always -F exit=-2 -F arch=b64 -Sopen
Ebből kiindulva nagyjából be tudod lőni, mi kell neked (azt hiszem, elég csak a megcélzott könyvtárral kiegészíteni)
Egy dolgot nem tudok: milyen hatása lehet a performanciára.
Forráskódot átfésülni greppel a megváltoztatott filenevekre?
Szerintem mióta itt germózol vele hogy elkapd a grep már kihányta volna ha van benne olyan.
===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)
http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation
> A fájlnevek néha kiértékelt kifejezésekből, string konkatenációkból vagy adatbázis tartalomból állnak elő, vagyis nem annyira egyszerű a dolog, hogy rákeresek a régi nevekre és már meg is van a hely, esetleg még használják.
Ezek után?