Index.
Sajnálom, hogy nincs országunkban erős oknyomozó újságírás, amely ilyenkor felkeresné Bajnai Gordonkát vagy a tököm tudja kit, aki a pénzek elosztásáért felelős, és kérdőre vonná, hogy a k. anyjába ennyire akadozik nálunk még a támogatások lekérése is? Hát már akkor se kell a pénz, ha “ingyen” adják?
Ez egy érdekes hibaüzenet, amit NTFS fájlok írásakor kaphat néha az ember. A GetLastError ilyenkor a 665-ös hibát adja vissza.
SQL Servernél a snapshotok írásakor jöhet ez elő, otthoni felhasználásnál nagyobb fájlok torrentes letöltése esetén, amikor a torrent kliens mint pl. a uTorrent úgy van beállítva, hogy használja az NTFS sparse file funkcióját. Ha egy sparse fájlt nagyon sok kicsi darabban raknak össze, akkor állhat elő ez a hiba, nem lehet folytatni a fájlt.
Aszongya a tudomány:
” When a sparse file (used for snapshot database files) is populated Windows limits the amount of data that may reside in the file. Once the amount of data stored in the sparse file exceeds the limit further data storage in the file may be prevented.
· Windows 2003 – 64GB (Error 1450 returned)
· Windows 2008 and Vista – 16GB (Error 665 returned)
”
Forrás.
Ilyenkor én az xcopy /Z forrás cél módszert használom, így a másolás leáll ugyan egy idő után hibával, de a fájl jelentős részét (általában az egészet) sikerül visszanyerni. Aztán a torrent kliens majd befoltozza a lukakat. Így sosincs gondom nagyobb SDK vagy egyéb hasznosság torrentes letöltésekor.
Az IE8-ban még tovább fokozzák a secu parát, és most már a tabfülek mögötti böngésző vezérlők is külön-külön processzben fognak futni.
Ennek a beteg addinektől való védelmen kívül számtalan előnye lesz, lsd. a cikket.
Én csak egyet nem értek. A Firefoxban az égvilágon semmiféle védelem nincs az addinek barbárkodása ellen. Teljes joggal azt ütnek szét a gépen amit akarnak. Miért nincs ebből baj firefox alatt, és miért van annyi gond IE alatt? Ez most nem egy élcelődő kérdés, tényleg nem értem. Az IE7 a protected móddal már igencsak fényévekre leelőzte secu szempontból a firefoxot, mégse hallunk problémákat a firefox felől (nem sima bugokra gondolok, hanem malicsusz addinekre).
Egyébként én firefoxot használok, aminek döntően egyetlen oka van: inkrementális keresés. Ha majd egyszer megjön az ms esze, lehet, hogy megpróbálkozok az IE-vel újra.
Most upgrade-eltem a 2.6-os verzióra (végül is már egy hónapja kiadták :), és egyből tönkrementek a permalinkek, azaz, ha egy cikkre kattint valaki, nem jött be az azt tartalmazó aloldal.
Itt leírják a gyógyítást.
Eddig még nem volt gond az upgrade-del, ez az első eset. Egyszer megbocsájtok nekik. :)
Az itt látható példa azokat a C# kódfájlokat listázza ki, amelyek árván maradtak, azaz ott vannak a fájlrendszerben, de nincsenek benne egy csproj fájlban.
Az egész számomra azért érdekes, mert szerintem igen tömören és elegánsan parsolják az xml csproj fájlt Powershellel.
A lopás árnyékát el nem kerülve, de idemásolom a példát a fenti forrástól:
[source=’php’]
param([string]$csproj = $(throw ‘csproj file is required’))
$csproj = Resolve-Path $csproj
$dir = Split-Path $csproj
# get the files that are included in compilation
$xml = [xml](Get-Content $csproj)
$files_from_csproj = $xml.project.itemgroup |
%{ $_.Compile } |
%{ $_.Include } |
?{ $_ } |
%{ Join-Path $dir $_ } |
Sort-Object
# get the files from the dir
$files_from_dir = Get-ChildItem $dir -Recurse -Filter *.cs |
%{ $_.FullName } |
Sort-Object
Compare-Object $files_from_csproj $files_from_dir
[/source]
Van egy kis virtuális masinám, amiben Windows 2008 fut, ezt debugolom éjszakánként kernel módban.
Eljött az ideje, hogy aktiváljam, de az aktiválás azt mondta:
Activation Error – 0x8007232B, DNS name does not exist
Azanyád, rossz a net config? Nem, mert simán lehet böngészni a gépben. Google, kiderül, hogy ha rossz a product key, akkor is ilyet mond az aktiválás. Nem tudom, de szerintem ez van olyan kényes kérdés, amit illett volna jobba kidolgozni az MSnek.
Tegnap megjelent a VS 2008 SP1, korábban hiányoltam.
Előtte le kellett futtatni a VS beta dirib-darabokat leszedő eszközt, a Visual Studio 2008 Service Pack Preparation Tool-t.
A takarító cucc elszállt, annak rendje és módja szerint, a Team Foundation Explorer matatása közben. Megpróbáltam repair-elni azt az eredeti DVD-ről, ugyanazzal a hibával elszállt. A logban láttam, hogy valamit akar a G: drive-ról, annak idején erről telepítettem, de most nem arról akartam repair-elni. Berakom a G:-be a DVD-t, és a repair sikeres. Most emlegetem a telepítő-írót kicsit. :)
A removal tool ezek után már simán működik persze, mehet az SP telepítő. A mostanában szokásos webes telepítőről van szó, ami pici, de aztán lehúzza magára az univerzumot. Érdekes, hogy egyszerre elindítottam egy X64-es és egy X86-os gépen is, és az X64-en vagy 3x annyi letöltési időt ír ki, hiába, hosszabb adat- és címbusz, hosszabb kód.
A telepítés nem kapkodja el, jó 1.5 órát elmolyolt, de felment. Kíváncsi vagyok a korábbi heap probléma előjön-e ezzel a végleges fw-kel.
Apró, de hasznos tudnivaló.
Mentésből visszaállított adatbázisok klasszikus problémája, hogy hiába van a visszaállított adatbázisban Józsi nevű felhasználó, és hiába van a szerverszintű loginok között Józsi, a kettő nem akar egymásra találni.
Régebben az sp_change_users_login-t használtuk a párkeresésre.
SQL 2005-től működik az ALTER USER WITH LOGIN is, ez ráadásul az előbbivel ellentétben NEM csak standard loginokra működik.
ALTER USER user_name WITH LOGIN = login_name
Az sp_change_users_login viszont egyszerre sok felhasználót is tud párosítani, így nem érdemes teljesen elfelejteni.
Multimédiás blog híján mindenki játssza le a fejében a hangot. :)
Örülünk, töltünk, telepítünk.
Köszönet Hangyál Zolinak a gyors hírért.
Update: szopás, várni kell még pár napot a VS 2008 miatt.
SQL Server 2008 RTM Available for Download
English downloads are available now and additional languages will be added on a daily basis. Visual Studio 2008 users will need to download and install Service Pack 1 which will be available here after August 11, 2008.
Voltam, láttam, visszamennék :) Ahogy várható volt ez nem az a vizsga, amit 2 nap tanulással le lehet tenni. A Windows Internals könyvből 3 fejezetet tudtam megemészteni ennyi idő alatt, így az azokkal kapcsolatos kérdésekre tudtam is kb. a válaszokat. Ha valaki elolvassa, megérti és kipróbálja a gyakorlatokat a könyvből, akkor szerintem a kérdések kb. 70%-ára tudni fogja a választ.
A maradék 30-hoz általános API programolási ismeretek, windbg igen alapos ismerete és a device driver programozás egyes részletei szükségesek. Emellett tudni kell kékhalált analizálni, érteni az IO műveleteket kernel módban, IRQ-kkal kapcsolatos debugolásokat, dumpokat elemezni, verifierrel vegzáni drivereket, paged, nonpaged, stb. memóriákat elemezni, heap corruption-öket debugolni, lefagyott vagy lerohadt user módú appokat debugolni, kernelből visszahívni user módba, szervizeket piszkálni, leak-eket analizálni, különböző utilokat ismerni (umdh, procexp, tlist, kernrate, sc, gflags, stb.), 64 biten 32 bites cuccok futtatása, UAC jobbra-balra, DEP, memory mapped files, IO completion portok, named pipe-ok, file-ok kezelése szinkron és aszinkron módon, Credential api, perfmon, pool tagging, kernel profilozás, power események kezelése device driverből, kernel struktúrák debugolása, azokból infók kibányászása (nt!_KWAIT_BLOCK, _DISPATCHER_HEADER, stb.), P&P eszközök debugolása, user és kernel módú szinkronizálás, aszinkron IO programozása driverben, kernel szálak kezelése, IRQL szintek és azok jellemzői, Deferred Procedure Call programozása, DMA kezelés, védett módba lépés különböző processzorokon, kézzel lekreseltetni a lefagyott oprendszert (dump céljából), checked buildű kernel hozzáadása éles géphez, filter driverek problémái, stb, stb. Most több nem jut az eszembe. Kb. 3/4 rész kernel, és 1/4 rész user mód volt benne. A kérdések legalább a fele a WinDbgről szól. Ezzel nem is lett volna baj, ő az új szerelmem már pár hónapja (sokkal többet tud, mint a vs debuggere), de én eddig user módban debugoltam. Igaz, hétvégén összehoztam egy kernel debug sessiont a 64 bites gépen, orgazmushoz közeli érzés CTRL-Break-kel megállítani az oprendszert, és beleesni a kernel debuggerbe. Majd ha e helyett már unalmat érzek, akkor érdemes elmenni erre a vizsgára (ez kicsit kétértelmű lett. :).
Szóval korrekt, de nehéz kérdések voltak.
Feltett szándékom, hogy azért is megértem mi történik a Windowsban, és megcsinálom a vizsgát, majd később, pénzért (ez most ingyenes beta volt). Ami nekem még előnyöm a MVP-ként a Windows forráskód hozzáférés, majd ha a kernelt tudom forrásszinten debugolni, az is egy újabb hőhullámot fog kiváltani. :) User mód már megvolt, az is egy élmény forrásszinten.
A tanuláshoz a következő könyveket és forrásokat szándékozok bevetni:
Első körben ennyi. Már csak pár évnyi éjszaka kell, és túl is vagyok rajtuk. :)
Az IIS7-ben megoldották, hogy hiába egy account alatt fut sok worker processz, akkor SEM tudják egymás védett fájljait olvasni. Így el lehet szigetelni a webappokat annak ELLENÉRE, hogy egy account alatt futnak (még ha nem is a javasolt konfig hosztereknek). De hogy a csudába? Eddig nem tudtam, de most megtaláltam a választ: Service SID.
“Service SIDs protect access to resources owned by a particular service, but by default services still have access to all the objects that the user account in which they run can access. For example, a service running in the Local Service account might not be able to access resources created by another service running as Local Service in a different process that has protected its objects with permissions referencing a service SID, however, it can still read and write any objects to which Local Service (and any groups to which Local Service belongs, like the Service group) has permissions.
Windows Vista therefore introduces a new restricted service type called a write-restricted service that permits a service write access only to objects accessible to its service SID, the Everyone group, and the SID assigned to the logon session. To accomplish this, it uses restricted SIDs, a SID type introduced back in Windows 2000. When the process opening an object is a write-restricted service, the access-check algorithm changes so that a SID that has not been assigned to a process in both restricted and unrestricted forms cannot be used to grant the process write access to an object. ”
Már csak az nem vili, hogy ezt hogyan használják fel az IIS wp-ek esetén, azok ugyanis nem szervizek. Ha egyszer megtalálom a választ, leírom.
Van valakinek jó tapasztalata ezzel az újítással? Ez az, ami USB-s memóriaeszközt használ memóriapótlásra. Nekem még nem volt kulcsom, ami elég gyors lett volna neki.
Gyorsított ez már valakinek? Most, hogy a gépembe nem lehet 2G-nál több RAM-ot rakni és folyton kevés a RAM, elgondolkodtam rajta.
A Windows Integrity Control (WIC) régebbi nevén Mandatory Integrity Control (MIC) az a mechanizmus a Vistában és a Windows 2008-ban, amely miatt egy alacsonyabb szinte besorolt processz nem tud Windows üzeneteket küldeni egy magasabb szinten futó processznek. A klasszikus probléma ami miatt ezt bevezették az interaktív szervizek hekkelése volt. Ha egy System account alatt futó szerviznek van Interact with the Desktop beállítása, akkor ki tud rakni ablakot az interaktívan bejelentkezett felhasználó asztalára. Ez látszólag ártatlan dolog. Azonban a magas jogosultságokkal futó szerviz GUI-nak tudunk mi, kis privilégiumú felhasználók üzeneteket küldeni. Ez azt jelenti, hogy ha pl. a textboxok tartalmát a szerviz nem ellenőrzi jól, egy jól irányzott hosszú szöveggel buffer overrunt okozhatunk a szervizben, megfelelő ügyességgel a szövegben elrejtett bináris kódot végrehajtatva vele. Ez az alapprobléma, ezzel nem lehet mit kezdeni Vista előtt, együtt kell élni vele. Gáz, de ez van. Sokszor mondták, ne írjunk ilyen szervizt, de egyszerűbb volt ezt csinálni, mint külön írni egy szervizt és egy sima userként futó klienst, ami mondjuk named pipe-on vagy egyéb IPC-n keresztül kommunikál egymással, biztonságosan.
Vistában egy szerviz magas integritási szinten fut, míg egy nemadmin felhasználó (aki lehet, hogy admin, de az UAC miatt nem admin, mint én is) az közepesen. (Érdekességképpen, egy protected módban futó IE7 esetén az általa elindított folyamtok alacsony szinten futnak.)
A WIC miatt egy közepes folyamat (sima user, sima app) nem tud üzenetet küldeni egy magas szinten futó folyamatnak (szerviz), így az előbbi hekkelési probléma megoldott.
No, aminek apropóján írom ezt, az a következő. A céges VPN-t egy Citrix Firebox SSL programmal érjük el. Ezt adminként kell futtatni, hogy meg tudja változtatni a hálózati beállításokat. Adminként így ő magas integritási szinten fut. Hogy a jelszót ne kelljen begépelnem előszeretettel használom a KeePass automatikus gépelő szolgáltatását, így CTRL-ALT-A-ra az ablak címe alapján benyom olyan billentyűkombinációt a célablakba, amit megálmodtunk. Ez viszont természetesen nem megy az előbbi helyzetben, mert a KeePass nemadminként, így közepes integritású szinten fut. Az integritási szinteket a process explorer mutatja meg, egy processznél a security fülön.
Ellenpróbaként adminként futtattam KeePasst, így egyből gépelt.
Ugyanez a probléma jött elő, csak rejtettebb módon, amikor proteced módban futó IE alatt fejlesztett AddInból adtam ki OutputDebugString hívást (ezt hívja meg a DefaultTraceListener is .NET-ben). A DebugView elvileg az ilyen hívások kimenetét adja vissza, de nem jött meg bele semmilyen üzenet. Utánanéztem, ilyenkor is üzenetek formájában mennek át a szövegek, ergo megint a WIC köpött a levesbe. A megoldás az volt, hogy alacsony integritási szinten kellett futtatni a DebugView-t. Erre írtam egy kis programocskát (ez alapján), ami egy processzt egy adott integritási szinten indít el. A PsExectől várnék el valami ilyesmit. Ha valaki tud ilyen kész utilt, akkor kérem jelezze.
Update: megválaszolom magamnak, a psexec -l Low Integrity-vel indít el egy processzt. :)
Powered by WordPress