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
- 5506 megtekintés
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.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
...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.
- A hozzászóláshoz be kell jelentkezni
Ltrace
Strace
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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`).
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Az strace egyébként jó ötlet, én is ezt néztem először.
- A hozzászóláshoz be kell jelentkezni
inotify
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Szia, viszont az nem látszik, hogy ki a hívó, csak az hogy valaki épp olvassa a fájl, pl ha futtatom.
- A hozzászóláshoz be kell jelentkezni
lsof
- A hozzászóláshoz be kell jelentkezni
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 :-)
- A hozzászóláshoz be kell jelentkezni
inotify + /proc/[pid]/fd
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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 :-)
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Az inotify nem parancs, hanem rendszerhívás. Vannak tool-ok, amik használják, de nem kell hozzá csomag :-)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
> 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?
- A hozzászóláshoz be kell jelentkezni