Hajmeresztő (szerencsére csak szakmailag) időszakon vagyok lassan túl, ezért is nem blogoltam már régen.
Pár vegyes tanulság az elmúlt időszakból, zöme magamnak is emlékeztető:
- A C/C++ secure stringkezelő (és egyéb) függvények nem úri huncutságok, és nem csak security szempontjából fontosak. A buffer overrun fogalom sok embernek a hekkeléssel forrt össze, pedig adatvesztések, instabilitások is gyakran következményei. Ha egyszer vannak rá normális függvények, és a kódok átírása se olyen vészes (tudom, mert átírtam vagy 100 függvényhívást az új függvényekre), akkor nem látok okot nem megtenni. Ahol a régi kód kussol, csendben elbassza a dolgokat az új visong. Ugyanez a helyzet a /GS kapcsolóval is (stack overrun ellenőrzés), valamint a /analyze opcióval (prefast) is. Igenis hallgatni kell rájuk, mert értelmes hibákat szúrnak ki.
- Ha az IIS alatt nem megy egy website, Service Unavailable hibával nem indul a worker process, és 0x80004005-ös (Access Denied) hiba van az eventlogban, akkor az iis valahol nem tud írni vagy olvasni. Jelentős FileMon/Regmon erőfeszítéseim ellenére se jöttem rá mi hiányzik neki, de az aspnet_regiis -ga megadja a szükséges jogokat a futtatáshoz.
- Ha egy osztály IDisposable, akkor kurvára meg kell hívni a Dispose metódust. Nem tudok elég nagy betűket rendelni ehhez:
Használd a C# usingot, bmeg!!!
Én a DirectoryServicessel szívtam meg, mivel az nemmanazsolt kódot és erőforrásokat hívokat a háttérben úgy fejreáll mint állat pár száz allokált objektum után, ha nem Disposolunk keményen.
- A backup hasznos dolog. Ennek hiányában a GetDataBack-kel számottevő sikereket érhetünk el. A rendszergazda meg barátkozzon össze a kapa nyelével a megfelelő testrészén.
Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.
LEAVE A COMMENT
4 COMMENTS
DS: Nem is tudtam hogy nem manazsolt kód. Vajh miért nem írták meg abba? Mindegy, ez költői kérdés volt.
IIS AccDenied: Én fel tudom azt tételezni, hogy az ASPP.NET Service (ami a services.msc-be is láccik) nem indul accdenieddel, csak ez az IIS-t baromira nem érdekli. gondolom ezért segít a aspnet_regiis, de ez csal tipp, látatlanba semmi komoly.
SecureString: Bocs, de úgy érzem,a világ elszalad mellettem… Pontosan mitől Secure ez a String? Mert manázsolt kódos?
IDisposable: Ezt se tudtam…
Ja, GetDataBack: Van egy jó tippem: Linux alatt minimális erőfeszítéssel összetehető egy otthoni iSCSI rendszer. Ennek rengeteg előnye van:
– A Windows képes normál lemezként látni, mintha csak a gépedben lenne. Ezzel egyyütt nincs ott
– A Víruskergetők, antispywarek ide is ellenőriznek. Nem egyszer futottam rá arra, hogy a kedves anti* programok rá se hederítenek alapból a hálózati meghajtókra…
Ehhez csak a MS iSCSI Initiatorára van szükség, Linux oldalon pedig az iscsi-target csomagra. Olyan a default konfigfájl, hogy aki ismeri a latin betűket, az el tud menni rajta… Gondolom ez nem gond :)
Ami még előny, hogy ha RAID-be vagy LVM-be kötöd a szerver lemezeiz, erről a Win kliensekek nem kell tudniuk. Sőt, akár egy fájl is szerepelhet mint “winchester”, és ez a fájl átnyúlhat kötetek közt is.
Egyetlen hátrányként azt tudom említeni mint az előnyeként: A win normál lemeznek látja és fragmentálja is rendesen…. defrag futtatása naon ajánlott…
A Secure stringkezelő cuccok natív kódú izék, nem manazsoltak. Egyszerűen arról van szó, hogy a stringbe (char*) író vagy onnan olvasó függvények kaptak hosszakat, így nem tudod túlírni őket, nincs buffer overrun.
SString: Értem. Ez így télleg hasznosnak tűnik, csak jön a homlokcsapkodás, hogy ez eddig mért nem jutott senkinek eszébe… Na mindegy.
Mondjuk foglamam sincs, kedvenc VB-m mit használ, de jó tudni ilyen okosságokról.