Nos hát.. Alap probléma: Restart után a szerveren nem használható a /dev/null...
Nézek ki a fejemből, hogy ez miért és hogy, de a hibaüzenet egyértelműen fogalmaz:
Gyorsan átmásztam root-ba, megnéztem mi a helyzet a környéken:server@user:/home/user $ ls > /dev/null Permission denied ksh: /dev/null: cannot create
Aham.. hogy csak a root-nak van valami joga a mappára.. Ki lehetett az a hülye, aki átlőtte??? Na mind1, rakjuk helyére..server@root:/home/root # ls -ld /dev/null crw-rw-rw- 1 root system 2, 2 Oct 15 16:29 /dev/null server@root:/home/root # ls -ld /dev drw------- 5 root system 356352 Oct 15 15:00 /dev
Kicsit matattam még a gépen, tettem-vettem, amikor is egy újabb parancs kiadásakor ismét ugyan ebbe a hibába botlottam (Permission denied).. Nézem ismét a /dev jogait.. megint 600... Hát mondom ilyen nincs.. valaki ilyen hülye, és még aktívan a gépen is van? Ha megtalálom nem hogy a root jogot veszem el tőle, hanem még a kezét is letöröm.. Ez a kis "lelkesedés" addig tartott, amíg észre nem vettem, hogy rajtam kívül nincs senki a gépen.. Feltételezve, hogy én nem műveltem ilyen hülyeséget néztem hogy akkor ez most WTF.. Valaki távolról, vagy hogy??? Hát mondom akkor játsszuk ezt..server@root:/home/root # chmod 775 /dev server@root:/home/root # ls -ld /dev drwxrwxr-x 5 root system 356352 Oct 15 15:00 /dev
Visszaállítottam a /dev jogait 775-re, majd kb 5-10 mp-enként visszaellenőriztem 'ls -ld /dev'-el, hogy mi is lehet itt.. Kb ezt kaptam:
Hát mondom ilyen nincs.. valaki garázdálkodik itt, vagy mifene?? Hát a jó nénikéjét.. Fogjuk már meg..server@root:/home/root # ls -ld /dev drwxrwxr-x 5 root system 356352 Oct 14 15:10 /dev server@root:/home/root # ls -ld /dev drwxrwxr-x 5 root system 356352 Oct 14 15:10 /dev server@root:/home/root # ls -ld /dev drwxrwxr-x 5 root system 356352 Oct 14 15:10 /dev server@root:/home/root # ls -ld /dev drw------- 5 root system 356352 Oct 14 15:10 /dev
Első gondolatom az volt, hogy az audit subsystem tökéletesen megfelel ennek kiderítésére.. De nézzük hogy is lehet ezt kivitelezni?
- /etc/security/audit/objects alá fel lehet ugyan venni a /dev-et, de az objects alatt csak read/write/execute event-eket lehet vizsgálni.. Itt meg látható, hogy az nem segítene, ergo ez nem nyert hangszórót
- Gondoltam, hogy ha valami itt a /dev jogait piszkálja, akkor a chmod-ot kell hívnia kötelezően.. Hát akkor induljunk el ebbe az irányba: Vegyünk fel a chmod parancsot az objects alá az alábbi módon:
Illetve a /etc/security/audit/events alá az új eventünket:/usr/bin/chmod: x = "CHMOD_USE"
Amint ezzel kész vagyunk indítsuk újra az audit subsystem-et:* chmod execution CHMOD_USE = printf "pid: %d, command: %s"
Oksa.. Tehát akkor elvileg ez is a helyén van.. akkor már csak az kell, hogy realtime nézhessük mi is folyik a gépen. Ezt az alábbi módon oldottam meg:server@root:/ # audit shutdown auditing reset server@root:/ # audit start server@root:/ # audit query |grep auditing auditing on server@root:/ # audit query |tail -2 /usr/bin/chmod: x = "CHMOD_USE"
Ezzel a paranccsal lényegében direktbe szűrhetek arra, amire szeretnék.. Ergo fogtam magam, nyitottam egy újabb terminált, majd ott követtem a /dev változásait, miközben ez a stream az 'egyes" terminálon szépen futott. Direkt átírtam a chmod jogait ismét 775-re (megint 600on volt), és konstatáltam, hogy az audit igen is látja a módosításom:server@root:/ # /usr/sbin/auditstream | /usr/sbin/auditpr -t0 -heRltc |grep CHMOD
Ezt követően csak vártam, és a másodlagos terminálon követtem a /dev esetleges változásait.. Egészen addig amíg a terminálon láttam, hogy a jogok megváltoztak, de az audit ebből semmit nem vett észre... WTF!? Audit stop, mit szúrtam el?? Lehet van máshol is chmod a rendszeren???CHMOD_USE OK root Fri Oct 14 17:06:52 2011 chmod
Nincs, csak ez az egy.. Akkor meg hogy a fenébe??? Na jó, mind1.. Az auditról tudni illik, hogy azért nem csak az objects file-ja használható, hanem alapértelmezetten az events-ek között jó pár más event is előre van definálva, mint például ezek:server@root:/ # find / -name chmod -type f -ls 1057 9 -r-xr-xr-x 1 bin bin 9216 Jul 9 2009 /usr/bin/chmod
* chmod()
FILE_Mode = printf "mode: %o filename %s"
* fchmod()
FILE_Fchmod = printf "mode: %o file descriptor %d"A FILE_Mode alapból ott volt a files class-ban, viszont a FILE_Fchmod nem, így azt is felvettem (biztosra megyek, úgy voltam vele), így kaptam ezt a sort:files = FILE_Open,FILE_Read,FILE_Write,FILE_Close,FILE_Link,FILE_Unlink,FILE_Rename,FILE_Owner,FILE_Mode,FILE_Acl,FILE_Privilege,DEV_Create
Ez után már csak az kellett, hogy ezt a class-t felvegyem a users szekció alatt a root-hoz az alábbi módon:files = FILE_Open,FILE_Read,FILE_Write,FILE_Close,FILE_Link,FILE_Unlink,FILE_Rename,FILE_Owner,FILE_Mode,FILE_Acl,FILE_Privilege,DEV_Create,FILE_Fchmod
users:
root = general,files
default = objectsÚjabb 1-2 percnyi várakozás, és minden elvárás ellenére ugyan az az eredmény!!! -> Az audit nem veszi észre azt ami ezt csinálja, csak azt amit én manuálisan ráengedek.. Ekkor sejtettem, hogy ez valószínű nem valami user hülyesége, hanem lehet valami bug, mert a forkot az audit tuti észrevenné.FILE_Mode OK root Fri Oct 14 18:05:25 2011 chmod
Innentől viszont nyilvánvalóvá vált, hogy az audit e célra itt nem fog bejönni.. Kénytelen voltam elővenni a nagyágyút: trace
Szerencsémre a trace azért meglehetősen jól használható AIX alatt, feltéve ha az ember tudja hogy is használja.. Az már csak hab a tortán, hogy van egy csomó előre definiált trace event group, amik közül az alábbiak közül választhattam (A / JFS2 típusú)
Megvan azért annak az előnye, ha nem kell az embernek fejből tudnia az összes hookot :)) Ami viszont engem illetett - úgy voltam vele, hogy ennyi szívás után nem szórakozok: minden JFS2 módosításról tudni akarok!!! Ergo fogtam magam, és az alábbi módon jártam el:server@root:/ # trcrpt -G |grep jfs2 jfs2 - JFS2: all JFS2 operations (reserved) jfs2meta - JFS2: metadata operations (reserved) jfs2user - JFS2: userdata operations (reserved) jfs2snap - JFS2: snapshot operations (reserved)
A másik konzolon meg az alábbi kis while ciklussal vártam, hogy mikor is történik pontosan (!) a váltás:server@root:/ # chmod 775 /dev server@root:/ # ls -ld /dev drwxrwxr-x 5 root system 356352 Oct 15 15:00 /dev server@root:/ # trace -a -J jfs2 -o /tmp/trc_raw server@root:/ # trcon
Amint erre a pontra jutottam nyomban le is állítottam a trace-t, majd amikor állítottam volna le ezt a while ciklust konstatálhattam, hogy a CTRL+C nem működik!! -> Mint kiderült: Ha belépéskor nincs a /dev-nek elég joga, akkor a CTRL+C nem fog menni, hiába van jól belőve az 'intr' érték az stty alatt:server@root:/ # while true;do echo "$(date +"%Y.%m.%d %H:%M:%S") $(ls -ld /dev)";sleep 1;done 2011.10.14 18:42:00 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:42:01 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:42:02 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:42:03 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:42:04 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:42:05 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:42:06 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:42:07 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:42:08 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:42:09 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:42:10 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:42:11 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:42:12 drw------- 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:42:13 drw------- 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:42:14 drw------- 5 root system 356352 Oct 14 18:30 /dev
Amint átállítottam a /dev jogait, és nyitottam egy új shell-t nyomban visszaállt minden a régibe az adott shellen belül.. A másikon meg killelhettem a ciklust.server@root:/ # stty -a |grep intr intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol =
Na mind1.. Nézzük azt a trace-t
Kb sejthetitek miért is nem olyan gyakori a trace használata ebből már: kevesebb mint fél perc alatt majd 7 MB adat generálódott a riportban! Na de, ha már megvannak az adatok, akkor igen is nézzük át mi és hogy lehetett.. A probléma csupán az, hogy ~7 MB-ot átnyálazni kicsit sokáig tart, meg jelen esetben amúgy se célravezető.. Jobb volt inkább megnézni, hogy mely processek használták a /dev-et..server@root:/ # trcoff server@root:/ # trcrpt -O "exec=on,pid=on" /tmp/trc_raw > /tmp/trc_raw.out server@root:/ # ls -l /tmp/trc_raw.out -rw------- 1 root system 7213429 Oct 14 18:26 /tmp/trc_raw.out
Ehhez első körben tudni kell a /dev inode számát, hogy legalább legyen mire szűrnünk:
Oks.. Tehát 12289.. Ezt nyomban át is kell váltanunk hexába, ami meg 3001.. Ezt a számot használva meg könnyen szűrhetünk is. Ha viszont csak így magában tesszük, akkor ilyen hosszú rettentő sorokat kapunk:server@root:/tmp # istat /dev Inode 12289 on device 10/5 Directory Protection: rw------- Owner: 0(root) Group: 0(system) Link count: 5 Length 356352 bytes Last updated: Fri Oct 14 18:30:10 2011 Last modified: Fri Oct 14 18:30:10 2011 Last accessed: Fri Oct 14 18:30:27 2011
Ergo lehet jobban járunk ha inkább a statisztikára vagyunk kíváncsiak:server@root:/ # grep -w 3001 /tmp/trc_raw.out |head -5 4DF --1- -1 0.003434251 0.001326 JFS2 iget: vp = F100011010C3B3E8, count = 0001, ino = 3001, dev = 8000000A00000005, getcaller = 2CF754 4DF --1- -1 0.003444816 0.005402 JFS2 iput: vp = F100011010C3B3E8, count = 0000, ino = 3001, nlink = 0005, getcaller = 2CF9DC 4DF --1- -1 0.003447171 0.000623 JFS2 iget: vp = F100011010C3B3E8, count = 0001, ino = 3001, dev = 8000000A00000005, getcaller = 2CF754 4DF --1- -1 0.003452763 0.003297 JFS2 iput: vp = F100011010C3B3E8, count = 0000, ino = 3001, nlink = 0005, getcaller = 2CF9DC 4DF --1- -1 0.003455013 0.000683 JFS2 iget: vp = F100011010C3B3E8, count = 0001, ino = 3001, dev = 8000000A00000005, getcaller = 2CF754
server@root:/ # grep -w 3001 /tmp/trc_raw.out |awk '{print $2}'|sort|uniq -c
761 --1-
2 cdromd
36 initA másik lehetőség az init volt.. Erről ugye annyit illik tudni, hogy a /etc/inittab file-ban tárolt bejegyzések alapján ténykedik. Amennyiben egy program/script respawn-ra van állítva, akkor az időről időre meg is hívódik, ami meg is magyarázná, hogy hogy lehet az, hogy user interakció nélkül változzon a /dev jogosultsága.. Nade a baj az, hogy az inittab-ban azért csak úgy nem turkálunk, a cdromd-hez hasonló teszteléseket (állítsuk le, aztán nézzük meg jó lesz e úgy) meg itt már nem biztos hogy jó ötletnek tartanám..
Azt viszont tudnunk kell, hogy amennyiben az inittab indít valamit, úgy annak a bejegyzése beleíródik a wtmp-be is.. Én meg az előző mérésemből tudtam a pontos időpontot (18:42:12), így az alapján már könnyen el lehetett indulni:
server@root:/ # cat /var/adm/wtmp |/usr/sbin/acct/fwtmp |grep "Fri Oct 14 18:42:1[012]"
cons 8 155664 0000 0001 1318614131 Fri Oct 14 18:42:11 2011
cons cons 5 58206 0000 0000 1318614131 Fri Oct 14 18:42:11 2011
cons 8 58206 0000 0001 1318614131 Fri Oct 14 18:42:11 2011
cons cons 5 58208 0000 0000 1318614131 Fri Oct 14 18:42:11 2011
cons 8 58208 0000 0001 1318614131 Fri Oct 14 18:42:11 2011
cons cons 5 221186 0000 0000 1318614131 Fri Oct 14 18:42:11 2011
cons 8 221186 0000 0001 1318614132 Fri Oct 14 18:42:12 2011
cons cons 5 57910 0000 0000 1318614132 Fri Oct 14 18:42:12 2011
cons 8 57910 0000 0001 1318614132 Fri Oct 14 18:42:12 2011
cons cons 5 221188 0000 0000 1318614132 Fri Oct 14 18:42:12 2011
cons 8 221188 0000 0001 1318614132 Fri Oct 14 18:42:12 2011
cons cons 5 221190 0000 0000 1318614132 Fri Oct 14 18:42:12 2011Respawn is ahogy vártam, de most komolyan a getty okozna nekem ilyen gondokat? Hát nézzük meg:server@root:/ # lsitab cons cons:0123456789:respawn:/usr/sbin/getty /dev/console
Aham.. Hát most vagy én vagyok nagyon balszerencsés, és pont abban az időben történt más is, vagy a getty tényleg ilyen problémákkal küszködik.. (A TSM-es hibára még visszatérek). Tekintve, hogy a 'getty /dev/console'-t manapság inkább csak virtual console-okhoz használják, így szívfájdalom nélkül kikapcsoltam, majd vártam, hogy történjen valami:server@root:/tmp # ls -ld /dev; /usr/sbin/getty /dev/console;ls -ld /dev drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev /dev/: TSM was unable to open port "/dev/" drw------- 5 root system 356352 Oct 14 18:30 /dev
Ctrl+C.. Őszinte leszek.. Még mindig nem értettem a dolgot.. Ezek szerint tényleg a getty okozza a problémát.. De miért?? Nézzük a konzol beállításokat:server@root:/tmp # chitab cons:0123456789:off:"/usr/sbin/getty /dev/console" server@root:/tmp # chmod 755 /dev server@root:/ # while true;do echo "$(date +"%Y.%m.%d %H:%M:%S") $(ls -ld /dev)";sleep 1;done 2011.10.14 18:46:11 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev ...... 2011.10.14 18:46:40 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev ... 2011.10.14 18:46:57 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev ... 2011.10.14 18:47:22 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev ... 2011.10.14 18:47:38 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev ... 2011.10.14 18:47:58 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev ... 2011.10.14 18:48:20 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:48:21 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:48:22 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:48:23 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:48:24 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:48:25 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:48:26 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:48:27 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:48:28 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev 2011.10.14 18:48:29 drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev
Na jó.. Beismerem.. Ez tényleg nem egészséges.. Ezt azonnal orvosolni kell:server@root:/tmp # lscons -a current = NULL console_logname = /var/adm/ras/conslog console_logsize = 32768 console_logverb = 1 console_tagverb = 0
server@root:/tmp # chcons -a login=enable /dev/vty0
chcons: Console login cannot be enabled because the console device
is not an available lft, tty, or vty.Jah hogy úgy.. Na ezt rántsuk már be akkor:server@root:/tmp # lsdev -Cctty vty0 Defined Asynchronous Terminal
server@root:/tmp # cfgmgr -l vty0
Method error (/etc/methods/cfgtty -l vty0 ):
0514-040 Error initializing a device into the kernel.Aham.. LPAR profil alapján csak 1 Virtual Serial Adapter van (ezek szerint az lesz a vsa2), de akkor ez miért lát 3at?? Na mind.. Gyomláljunk, mert ez így gázos:server@root:/ # lsdev |grep vs vsa0 Defined LPAR Virtual Serial Adapter vsa1 Defined LPAR Virtual Serial Adapter vsa2 Available LPAR Virtual Serial Adapter server@root:/ # lsdev |grep vty vty0 Defined Asynchronous Terminal
Oks.. Mindjárt jobb.. Console-al mi van?server@root:/ # for i in vty0 vsa2 vsa1 vsa0;do rmdev -dl $i;done vty0 deleted vsa2 deleted vsa1 deleted vsa0 deleted server@root:/ # cfgmgr server@root:/ # lsdev |egrep "vty|vsa" vty0 Available Asynchronous Terminal vsa0 Available LPAR Virtual Serial Adapter server@root:/ # chcons -a login=enable /dev/vty0 chcons: console login enabled, effective on next system boot chcons: console assigned to: /dev/vty0, effective on next system boot
Na ez még gázos lehet.. Akkor ezt is rakjuk helyre:server@root:/ # pstart console DISABLE vty0 ENABLE
Ez után ismét megnéztem mi és hogy áll.. Sajna azt kellett tapasztaljam, hogy a penable igaz, hogy helyére rakta a console-t, viszont az inittab-ban is újra engedélyezte a cons bejegyzést.. Ez miatt ismét rakhattam off-ba, illetve lőhettem vissza a /dev-et 775-re.. Viszont sajna a jelek szerint a getty még mindig nem ment normálisan:server@root:/ # penable console server@root:/ # pstart console ENABLE vty0 ENABLE
Hát jó.. akkor nem maradt más restart.. Ami láss csodát.. Megoldotta a problémát!server@root:/tmp # ls -ld /dev; /usr/sbin/getty /dev/console;ls -ld /dev drwxrwxr-x 5 root system 356352 Oct 14 18:30 /dev /dev/: TSM was unable to open port "/dev/" drw------- 5 root system 356352 Oct 14 18:30 /dev
server@root:/tmp # ls -ld /dev; /usr/sbin/getty /dev/console;ls -ld /dev drwxrwxr-x 5 root system 356352 Oct 14 19:10 /dev drwxrwxr-x 5 root system 356352 Oct 14 19:10 /dev
Éljen.. akkor problem solved.. Na de azért bennem felmerült 1-2 dolog.. Az első, hogy mint látható, most a TSM nem dobott hibát. Tekintve, hogy a TSM-es hiba direktben a /dev-re hivatkozott, így erősen esélyesnek tartom, hogy a problémának ehhez is köze lehet.. Tekintve, hogy ez egy TSM szerver, így nem csodálkoznék, ha ez egy TSM bug lenne, viszont a neten körbeszaglászva ilyen, vagy ehhez hasonló hibaleírást véletlenül se sikerült találnom.. A gyanúmat még jobban alátámasztja az, hogy a getty által piszkált file-ok a /dev alatt default 622-es jogot kapnak (hacsak ezt az ODM-ben nem bíráljuk felül, de ilyen itt nem volt)
Az viszont a probléma ellen szól, hogy a TSM-nek semmi köze nem szabadna legyen ezen a szinten a rendszerhez, pláne nem a getty futtatásakor. Így az is elképzelhető, hogy ez is csak egy a sok side affect közül (mint pl a CTRL+C-s hiba) ami amúgy egy getty-os bug.
Mindazonáltal a hiba meglehetősen furcsa volta, illetve a hiba keresési mód miatt úgy gondoltam, hogy ez az írás megér egy blog bejegyzés (tudom - jó hosszú lett)
Nincsenek megjegyzések:
Megjegyzés küldése