Soluția de moment: downgrade la Firebug 1.4: http://getfirebug.com/releases/firebug/1.4/

PS: Firefox 3.6 sub Hardy amd64 este probabil cea mai instabilă versiune lansată vreodată. Am avut versiuni de Firefox Alpha sau Beta ce erau mai stabile de atât.

Bun. La partea cu instalarea îmi doream să ajung. Mai bine zis la partea cu actualizarea. De regulă pe un Ubuntu Server ce mai rulează servicii mici/medii VirtualBox are bunul simț să ruleze în background ca daemon printr-un simplu init script. În concluzie actualizările le fac atunci când îmi mai aduc aminte să deschid interfața grafică. Sub Windows în schimb este o jucărie unde mai testez ultimele apariții în domeniul OS. Dar aici mă lovesc suficient de des de acea fereastră ce mă anunță faptul că a apărut o nouă versiune. Click – download  – next, next, next … gata. În teorie era gata. În practică 3.0.12, adică ultima versiune, refuză să adauge orice fel de HDD virtual nou și am o mică bănuială despre imposibilitatea de a adăuga noi mașini virtuale.

Mă apuc să lucrez în calculator să văd ce se întâmplă (doctore). Cretinătatea aceea de installer nu a închis VBoxSVC înainte de instalare. Adică acel serviciu ad-hoc din arhitectura VirtualBox ce se ocupă de mașinile virtuale atâta timp cât rulează cel puțin una. În mod normal stă închis acel proces. Ridicolul merge mai departe. Acel proces, VBoxSVC dă un ‘lock’ exclusiv pe fișierele de configurare astfel încât să nu apară chestia aceea numită ‘race condition’ în geek language. Iar acel proces nu mai vrea să moară. Task Manager-ul e inutil ca de obicei la omorât procese încăpățânate. Am scos artileria grea: Advanced Process Termination (APT). Pe lângă o duzină de metode de kill, știe două metode de kernel kill și încă două de crash kill. Kernel kill pe Windows 7 x64 nu are suport. Nu mi-am spart capul cu hack-ul de OS. Din păcate metodele din user mode au dat greș. Windows încă e copil mic și udă patul atunci când vine vorba de procese încăpățânate. Sistemele UNIX-like (ex: Linux, FreeBSD) rămân în situația penibilă de mai sus atunci când un proces rămâne blocat în ‘IO wait state & friends’. Soluția este evidentă: reboot. Dar m-am cam săturat să rămân cu procese blocate pentru ca Windows e rebut la management-ul lor din ‘user mode’. Iar VirtualBox e rebut la actualizare și nu își știe închide serviciul înainte de un nou ‘deploy’. În mod curios, procesul blocat nu apare în APT. Dar APT are o jucărie numită ‘Custom PID’ pentru a da kill după kill.

Din păcate, ocazional, dezvolt și aplicații ce au nevoie de acces la funcția mail(), funcție ce altceva înafară de FALSE aka FAIL nu știa să returneze. Verific Postfix-ul – rula de zor. Deci nu era bubă de MTA. NU, nu suport Sendmail. Iau o porție de copypasta de pe php.net, pun totul întrun fișier php, rulez în shell – surpriză:

sh: -t: not found

Mă scarpin cu o mână în cap și cu cealaltă în dos. Ceva îmi pute – și nu era de la a doua mână. Încep să sap pentru a afla ce pește prăjt au făcut cei de la Zend cu php.ini de încearcă să ruleze aplicația ‘-t’. Crăp un output de phpinfo() in Firefox și mă luminez:

sendmail_path Local Value: -t -i Master Value: -t -i

Erm, WTF Zend? Casc vinovatul (/usr/local/zend/etc/php.ini) și caut linia cu pricina ce bine mersi era comentată. Cică în mod implicit ar trebui să fie ’sendmail -t -i’, dar se pare că opțiunea nu este hardcodată ca atare. Soluția e la mintea cocoșului:

sendmail_path = sendmail -t -i

Restart la Apache2. Merge? Merge. Shell-ul este fericit deasemenea.

M-am trezit inca de dimineata cu gand rau impotriva Gnome History. Din pacate gandul meu a fost mai slab decat implementarea incapatanata a celor ce au gandit Gnome-ul din acest punct de vedere si n-au pus pe undeva o optiune pentru dezactivarea acestei functii, optiune ce sa fie demna de ‘Captain Obvious’, altfel spus, la mintea cocosului. Daca in trecut istoricul se tinea in fisierul ~/.recently-used iar un simplu:

chmod -c 400 ~/.recently-used

era suficient pentru a opri atrocitatea, in prezent (de la Gutsy si pana in prezent daca nu ma insel) lucrurile sunt sensibil mai diferite. Numele fisierului s-a schimbat intre timp in .recently-used.xbel. Nu aceasta ar fi problema esentiala daca metodele clasice ar functiona. Am incercat schimbarea ACL-urilor precum am pus mai sus: ceva le restaureaza. Am pus symlink catre /dev/null … ceva sterge link-ul si restaureaza fisierul. L-am creat de sub root si l-am lasat asa … ceva ii restaureaza ACL-urile si le pune iarasi pe contul meu. Parca era un film de acela prost cu Greuceanu ce omoara balauri alimentati cu baterii Duracell ce tot primesc resurect. Din fericire acesta a fost balaur pe 2 biti (4 capete). Cine stie bancul cu balaurul pe 8 biti, pricepe.

Metode exista, si sunt doua la numar. Prima desi functioneaza, este trista pentru ca are prostul obicei de a genera erori GTK in shell:

rm ~/.recently-used.xbel ; mkdir ~/.recently-used.xbel

Se pare ca e o piatra prea tare de rumegat pentru implementarea incapatanata prezentata mai sus.

Dar are dezavantajul erorilor din shell. Fericitii (ca mine) ce folosesc ext3 pe post de filesystem (nu cunosc utilitare echivalente pentru reiser, xfs, jfs – nu dati cu pietre) pot apela la o smecherie ce marcheaza fisierul ca immutable iar la incercarea de a face ceva, o sa se loveasca de un raspuns mai incapatanat de la Sfantul Kernel:

sudo chattr +i ~/.recently-used.xbel

Chestia asta il va opri pe mucos sa mai salveze istoricul, ba mai mult, scuteste shell-ul de erori neinteresante.

Introducere

Determinarea MIME Type-ului corect pentru un fisier este o problema esentiala. Nu o sa explic si de ce … daca nu stii de ce, atunci tutorialul acesta iti depaseste nivelul cunostintelor. Atunci cand se face upload la un fisier printr-un form, sau se doreste import-ul unui fisier, se poate intampla ca extensia fisierului sa nu reflecte realitatea sau ca aceasta sa lipseasca cu desavarsire, fapt ce va duce la varii probleme. Array-ul $_FILES ce ia valori in functie de continutul unui form ce are specificat in mod explicit enctype=”multipart/form-data” se prea poate sa nu contina valoarea corecta a mime type-ului pentru $_FILES['file_input_name']['type'] deoarece detectia mime-ului cade pe spinarea browserului iar in majoritatea cazurilor acesta se foloseste de extensia fisierului deci va esua in cazurile descrise mai sus. Este nevoie ca informatia sa fie interpretata citind headerele fisierului si folosindu-ne de mime magic.

PECL si fileinfo

Nu o sa imi pierd timpul sa explic ce e PECL. Google este de mare ajutor. Din pacate in repository-urile Ubuntu/Debian, extensia fileinfo nu este disponibila in mod implicit. Din fericire este disponibila prin intermediul PECL. Acum incepe treaba sa fie paroasa.

In primul rand, este nevoie de una bucata compilator. Exista un pachet ce le face pe toate, deci:

sudo apt-get install build-essential

Bun. Avem compilator, avem PECL (presupun, daca n-ai HTTP server si PHP – citesti degeaba). Pentru build-ul fileinfo mai este nevoie de pachete de development, deci:

sudo apt-get install libmagic-dev php5-dev

ce va instala headerele de development pentru libmagic, phpize si alte chestii. Faceti acum, sau regretati mai tarziu. Acum este timpul sa compilam extensia fileinfo folosind pecl:

sudo pecl install fileinfo

Daca maraie vreo eroare la configure, instalati pachetul de development aferent (pentru cei somnorosi, are sufixul -dev). Daca maraie vreo eroare la compile, imi pare rau, nu va pot ajuta. Pe masina de devel a functionat fara probleme. Daca nu maraie nici o eroare, ar trebui sa indice faptul ca extensia a fost instalata cu succes. Ar trebui sa fie ceva de genul:

Build process completed successfully
Installing ‘/usr/lib/php5/20060613+lfs/fileinfo.so’
install ok: channel://pear.php.net/Fileinfo-1.0.4

Daca ati ajuns pana aici, mai este putin si usor. Extensiile instalate prin intermediul PECL nu sunt incarcate in mod automat, spre deosebire de cele instalate din repository-urile Ubuntu/Debian folosind apt-get sau alternativa (cu mici exceptii, spre exemplu mcrypt.so trebuie incarcat in mod explicit – nenea maintainer a fost cascat). Pentru a mentine ideea si spiritul Debian, incarcarea modulului se va face folosind directorul de fisiere alternative de configurare pentru PHP. Tastati urmatoarele chestii intr-un terminal (da stiu, copy-paste e mai comod):

cd /etc/php5/conf.d/; sudo touch fileinfo.ini; sudo nano fileinfo.ini

Bagati urmatoarea linie in acel fisier:

extension=fileinfo.so

dupa care salvati cu Ctrl+O. Inchideti editorul text folosind Ctrl+X. Nu, nu sunt vim maniac, sa nu aud de el. Acum este timpul sa se dea restart la HTTP server pentru a incarca noua configuratie. Ar trebui sa fie valabil si pentru cei cu GCI/FastCGI (eventual alt HTTP server gen lighttpd), desi subsemnatul e de ala cu Apache 2+PHP5 handler, deci in cazul meu (si al majoritatii):

sudo /etc/init.d/apache2  reload

ce va duce la un graceful restart (aka restart fara downtime) urmat de incarcarea noilor fisiere de configurare. Daca totul e ok, noul modul de PHP ar trebui sa fie incarcat. phpinfo(); ar trebui sa indice acest fapt, atat in lista de fisiere de configurare alternative (cele din /etc/php5/conf.d) cat si prin faptul ca ar trebui sa indice pe undeva in mod explicit faptul ca fileinfo este incarcata.

Utilizarea fileinfo pentru a afla MIME Type

Acum sa trecem la lucruri grele. fileinfo contine niste functii smechere asemanatoare cu fopen. Pentru ubergeeks exista modul orientat obiect de lucru cu ele (php.net/finfo_open explica), dar subsemnatul se multumeste cu trei apeluri procedurale din moment ce nu exista nici un avantaj real in cazul de fata pentru a defini un obiect si a-l distruge dupa ce se afla mime-ul. Pentru cei dornici sa isi implementeze o clasa proprie … este alta poveste. Eu mi-am facut o functie custom ce am inclus-o in API-ul central ce primeste ca parametru calea fisierului si imi returneaza mime-ul in caz de succes sau un cod de eroare pentru debug in caz de esuare. Miezul problemei sta in:

$finfo=finfo_open(FILEINFO_MIME, "/usr/share/misc/magic");
if(!$finfo)
	die("Can't open the fileinfo database.");
$mime=finfo_file($finfo, $fileName);
finfo_close($finfo);

Si cam atat. Succes si spor la treaba.

echo “blacklist mod_name” >> /etc/modprobe.d/blacklist
sudo update-initramfs -u

Voila … sintaxa pentru blacklisting …

http://www.thewebsiteisdown.com/

In fine, nu ma apuc sa detaliez chestii. Important este ca din punctul de vedere al resurselor ocupate sta foarte bine (si zic asta de bine, nu de rau), este rapid, n-am avut probleme nici cu stabilitatea. Mi-am pus si Compiz-Fusion (evident, dooh) pentru ca am mai declarat pe undeva urmatoarele: dupa perioada OS X nu am mai putut sa privesc un desktop non-3D cu aceeasi ochi. Desi este cel mai bun sistem pentru servere (daca maine ar fi sa imi trec file serverul de pe Ubuntu Server pe FreeBSD – as face-o, dar imi trebuie niste timp pe care nu il am) sa zicem ca face o figura frumoasa si pe desktop. Ce-i drept, are lipsurile lui, despre care cred ca o sa ma apuc sa scriu la un moment dat.

Din punctul de vedere al hardware-ului, singura chestie care imi lipseste enorm este un driver care sa imi suporte placa de sunet care o am ca add-on, si anume o Audigy 2 ZS Notebook. Ce-i drept, n-am incercat Open Sound System care vine cu propriile module. Este o idee. Driverul snd_emu10kx care suporta Audigy si Audigy 2 nu vrea sa stie de placa mea, ba mai mult, cand l-am instalat si am uitat sa il scot din lista de boot (s-a pus automat acolo), FreeBSD a refuzat sa mai boot-eze pana nu am eliminat fizic placa din sistem. Acu pe partea de multumiri din punctul de vedere al hardware-ului este faptul ca se pupa bine cu el, ba mai mult, a rezolvat o problema pe care nu au reusit sa o rezolve nici driverele de sub Windows si nici cele de sub Linux: placa de retea – pe care o suspectez de o oarecare defectiune care se manifesta la 100Mbps. Chiar am facut teste de transfer prin SFTP, MikeS este martor. I-a picat si lui fata la testul de doua fisiere peste 1GB – nu a cazut nici unul sub 5MB/s, media a fost undeva de 11MB/s. Culmea, la 1Gbps prin conexiune directa cu serverul merge “flawless” sub Windows si Linux. Am umplut vreo 3 threaduri pe varii forumuri de specialitate in cautarea unei solutii. N-am gasit nici in prezent. Sub Windows/Linux tot ca un cur imi merge reteaua daca nu o pun pe 10Mbps – iar la 10Mbps ma apuca Sfantul Asteapta pana iau ceva de pe severul propriu care este in acelasi LAN – limitat la 100Mbps de router, un ASUS WL500g Premium. Cica in ultimele lui ore de viata, Linuxul in linie de comanda cu Midnight Commander si serverul montat prin SSHFS nu a mai cazut la trasfer (si am facut un backup masiv, vreo 30j de gigi de date). Dar este singura situatie in care a functionat corect … in rest a fost praf.

Oricum, articolul care mi-a dat multe idei si m-a facut sa imi pun FreeBSD in defavoarea Linux a fost acesta:

http://www.over-yonder.net/%7Efullermd/rants/bsd4linux/bsd4linux1.php

Iar daca ar fi sa apreciez ceva la FreeBSD este faptul ca fisierele de configurate tipice sunt foarte logice ca denumite, ca pozitionare in file system, precum si inca alte cateva chestii. Deasemenea ma bucur ca nu exista haosul din lipsa de organizare a Linuxului in ceea ce priveste anumite chestii dat fiind faptul ca un standard este greu de impus cand fiecare incearca sa traga foc la oala lui. Inchei …

Sursa: http://wonder.rodp.net/2008/02/pidgin.html

KDE 4, asa cum a fost promis, ruleaza nativ sub Linux, Windows, OS X, mai pe scurt, sub orice platforma sub care este suportat Qt-ul celor de la Trolltech. Inainte sa apara eram destul de entuziasmat de vestea aparitiei KDE 4. Tin minte ca din intamplare citisem despre planurile ce tin de KDE 4 inca de acum 2 ani. Eram entuziasmat pentru faptul ca la vremea cand asteptam KDE 4, inca eram user de KDE 3 sub Linux. Faptul ca a fost promis nativ sub Windows/OS X nu a facut decat sa imi creasca entuziasmul.

O mica notificare ar fi faptul ca sub OS X rula KDE 3 si o buna parte a aplicatiilor ce tin de acest desktop environment, dar modul de rulare nu era nativ ci rula sub implementarea Apple a XFree86. Chiar am fost curios sa vad cum arata o mana de aplicatii KDE sub OS X si au iesit momente horror … aratau ca nuca in perete si faptul ca nu rulau nativ era destul de nasol la consistenta. Acum cica s-a rezolvat problema … astept sa vad cum arata treaba in teren.

Sub Windows lucrurile stateau putin diferit datorita anumitor restrictii ce tin de licentierea Qt 3. Da, KDE 4 respecta numerotarea versiunii majore de Qt sub care au fost dezvoltate … KDE 3 a fost dezvoltat sub Qt 3, KDE 4 sub Qt4. Nimic nou sub Soare. Odata ce problemele s-au rezolvat incepand cu v4 a Qt, acest fapt a permis portarea aplicatiilor si sub Windows.

Alaltaseara mi-am pus KDE 4 sub Windows. Installer-ul desi e grafic, cel mai probabil va pune probleme celor nefamiliarizati cu lumea *nix. Mi-e mi-a adus a installer de cygwin, deci concluzia rapida a fost ca baietii de la KDE nu au dorit sa reinventeze roata. Setup-ul a inceput in mod “uzual” – downloadarea pachetelor necesare din repository (uzual – cum ziceam mai sus, precum cygwin). Instalarea nu a decurs fara probleme. La anumite pachete setupul (v0.8.5 – cea mai recenta) claca fara drept de apel. Spre exemplu am dat sa instaleze toate tool-urile de development. Desi rar am avut nevoie de CVS cand de regula gaseam sursele gata arhivate, am dat sa instaleze si TortoiseCVS. Asta a fost OK. A crapat la instalarea TortoiseSVN pe care il aveam instalat deja din moment ce sunt SVN user, ce-i drept aveam o versiune mai veche. Clacatul se traduce prin 100% load si apasarea butonului de ‘Cancel’ se traducea prin proces care continua sa ruleze in background, dar nu facea nimic. Multumesc cerului ca setup-ul nu stie multi-core, deci sistemul nu a fost afectat substantial la viteza, sistemul mutandu-si chestiile pe core-ul celalalt al procesorului. Ar mai fi si alte pachete la care am intampinat probleme, si culmea, pachetele respective nu erau instalate anterior precum TortoiseSVN.

Utilizarea este de-a dreptul seaca. In primul rand trebuie rulate in terminal doua comenzi de configurare … nu am nimic impotriva, dar in documentatie caile erau indicate complet aiurea. Le-am dibut si am rezolvat. A urmat rularea aplicatiilor propriu zise. Practic installer-ul pune executabilele si dll-urile in directorul bin care se gaseste in directorul de instalare al KDE 4. Cum ziceam la un moment dat, poate fi putin ciudat pentru un user nefamiliarizat cu *nix. Pentru mine a fost OK, atata ca in bin este un haos de nedescris. Am dibuit niste chestii cunoscute, le-am rulat, a fost relativ OK. Prima executie a fost mai dureroasa in sensul ca tre sa isi faca in prealabil o chestie care ruleaza in background, dupa care nu mai sunt probleme. Aplicatiile se integreaza bine ca aspect printre celelalte. Inafara de cateva butoane si alte chestii tipice KDE, aplicatiile arata bine. M-am jucat cateva jocuri ce vin in pachet, am editat niste fisiere text folosind Kate si Kwrite, m-am dat pe net cu Konqueror. Desi am fost incantat, inca nu am vreun gand de inlocuire a unor aplicatii ce le folosesc deja sub Windows, exemplu Windows Explorer-ul pimpuit sa il dau la o parte pentru Konqueror din motive de varii instabilitati, feature-uri care nu functioneaza sau nu functioneaza corect, etc. Poate cel putin nu pentru moment. Mai este de lucru … atat la stabilitate cat si la uzabilitate. Oricum, KDE 4 sub Windows inseamna o mana de aplicatii, si nicidecum un full desktop environment, ceea ce lasa un gust semi-amar in gura.

Sub Linux totul a fost destul de scurt … dupa aproximativ 15 secunde de gugălit am gasit un repository neoficial in care sa fie KDE 4 pentru ubuntu. L-am instalat usor pentru ca package managementul si-a facut treaba. Mici probleme au fost la anumite aplicatii specifice, desi in general treaba a mers OK. Desktopul plasma arata bine, pare o revolutie peste KDE 3, desi mie inca nu mi-a sters impresia ca Vista Sidebar cu ale lui gadgets s-au mutat si s-au intins pe tot desktop-ul. La un moment dat a inceput chiar sa ma enerveze acest aspect. Interfata este mult mai bine lucrata din punctul de vedere al consistentei fata de KDE 3, multe chestii seamana, dar la anumite optiuni de configurare nu s-au eliminat dialogurile interminabile si putin uzabile. Am incercat sa schimb stilul ferestrelor de pe Oxygen (cel implicit si fresh pentru KDE 4) pe alte stiluri tipice KDE 3, dar a dus la scaderea caliatii vizuale. Oricum, la nivel de interfata, vizual vorbind, KDE 4 este peste KDE 3, desi inca nu s-au reparat unele din pacatele trecutului. Ce am apreciat a fost faptul ca s-a implementat meniul tabular care are motor de cautare pe care il stiu de sub openSUSE.

Aplicatii nu am prea testat pentru ca sincer nu ma interesau aplicatiile in sine, ci desktop environment-ul. Oricum, aplicatiile tipice KDE le rulez cu succes si sub Gnome, si chiar daca arata putin ciudat, tot raman in sfera acceptabilului. Desi de aproximativ 4 luni am trecut de la KDE 3 la Gnome, sincer sa fiu, nu m-as mai intoarce nici pentru KDE 4. In plus, desi initial erau o mana de chestii care in KDE le gaseam imediat si sub Gnome sapam dupa ele, cu timpul situatia s-a inversat. Exact aceasta a fost senzatia cand am trecut acum din sesiunea de Gnome in cea de KDE 4. Au inceput imediat sa imi lipseasca chestii, sa ma enerveze alte chestii, sa imi lipseasca Compiz-Fusion (da, dupa un an si ceva de OS X – am ramas fan al desktop-urilor 3D).

Pe total KDE 4 a fost pentru mine o semi-dezamagire, sau poate ca asteptarile mi-au fost prea mari. Vom vedea ce vor aduce versiunile mai noi, pentru ca desi e release, mie inca nu imi sterge impresia de preview release.

Chiar si Google, YouTube, Yahoo sau Wikipedia, FaceBook, Nokia folosesc platforma MySQL. Este nu doar o platforma open source, ci si foarte buna, stabila, usor de instalat, administat sau upgradat ulterior. Sun Microsystems vrea sa transforme solutia MySQL intr-o plartforma pentru companii.

Serverul de baze de date MySQL produs de compania MySQL ocupa aproximativ 80% din piata serverelor Web, un fapt bine cunoscut de altfel. Sun se asteapta sa dea lovitura cumparand MySQL prin integrarea serverului de baze de date in solutiile oferite de acestia, marind in acelasi timp canalele de distributie MySQL.

Avand in vedere cota de piata MySQL, se poate spune cu usurinta faptul ca aceasta tranzactie va schimba fata Internetului prin prisma impactului pe care il va avea aceasta tranzactie.

“Cumparam astazi o solutie pentru baze de date care a fost aleasa de clientii din toata lumea cu o viteza extraordinara”, a spus Schwartz. “Titanii web-ului folosesc toti MySQL, banci, companii auto, toate firmele din Fortune 500 folosesc MySQL”, a adaugat el.

Chiar nu mai am nimic de adaugat … speechless …

Sursa 1 Sursa 2 – oficiale

Sursa 3 – neoficiala

Sursa

Stateam si ma gandeam zilele acestea la o metoda de a proteja anumite aplicatii de accesul neautorizat in ceea ce priveste accesul fizic la o masina. Problema sta cam asa: un sistem securizat priveste utilizatorul ca un potential risc … deci nu este o entitate in care se pune incredere (si bine face, dar despre asta in episodul urmator). Chiar daca utilizez deja sistemul sub un cont de user dupa cum va povesteam aici, browserul, clientul de mail au master password care cripteaza parolele stocate in managerele proprii … sistemul prezinta o vulnerabilitate asupra accesului direct …

Se intampla sa vina prieteni pe la mine (din care unii evident – impart ocupatii asemanatoare), si cum nu am o masina dedicata pentru fiecare chestie in parte, sa zicem ca muzica canta de pe aceeasi masina de pe care fac development, browsing, si alte chestii. Momentan mi s-a pus pata pe cookie-uri, desi exista si alte date confidentiale care ar trebui sa ramana pe disk-urile proprii si numai acolo. Daca eu, ca detinator al sistemului … folosesc un model de securitate prin care eu nu sunt crezut fara autentificare ca superuser … de ce ar fi altii crezuti? Simplu … ei nu ar trebui sa fie, dar sunt. Browserul isi stocheaza profilul in directorul de “user data”. Chestia asta e valabila si sub *nix … deci vorbesc la cazul general, indiferent ca e vorba de /home/{user_name} sau de %systemroot%\Documents and Settings\{user_name}\Application Data (pe scurt %appdata%). Din moment ce browserul ruleaza sub un anume user … drepturile din “user data” sunt drepturile complete ale aceluiasi user. Simplu ca buna ziua. De ce nu mi-as crede proprii prieteni? Hmm … nu stiu … cred ca de cand am inceput sa citesc documentatie despre securitate … am devenit paranoic. In fine, sa continuia asupra ideei lansate.

Morala este simpla … se creeaza un utilizator cu acces limitat. Sub Windows (prin modelul prezentat in articolul anterior dedicat acestui fapt) este obligatoriu ca acesta sa aiba parola diferita de o parola nula pentru a permite utilizarea runas. Sub *nix este necesara prezenta loginului daca nu exista sudo, in caz contrar un sudo su {user_name} – ar loga un utilizator fara drept de login. Smecheria asta cu sudo am descoperit-o cand ma chinuiam sa dau drepturi de acces unui server HTTP (Apache 2) la un director SSH montat ca local prin sshfs. Solutia a fost sa montez directorul ruland comanda de mount de sub userul serverului … dupa ce in prealabil am dar acces mai larg la montare.

Dupa ce utilizatorul este creat … se muta user data-ul in directorul userului nou, se interzic drepturile de acces (citire) in ceea ce priveste fisierele utilizatorului (in cazul in care grupul/others au acces de citire la fisiere), iar aplicatia care se doreste a fi rulata protejat, se ruleaza folosind noul utilizator … astfel in momentul in care aplicatia este inchisa … datele sunt in siguranta. Ideea este simpla … punerea in aplicatie cere niste consum de taste in plus.

Apropo de paranoia care o ziceam mai sus … nu e 100% absurda. Au existat cazuri (da, la plural) cand din vina prietenilor mei, primeam acces la datele lor fara sa fac efort … mi se oferea un authentication_id (o metoda stupida de a autentifica calculand un hash obosit pentru a scuti utilizatorii unui site de actiunea de a tasta user+pass – si care ramane constant daca se schimba parola – deci algoritmul de generare este prost pentru ca nu stie de modificari, securitatea este precara datorita faptului ca un URL de acest gen este trimis in mod plain text prin retea), sau o usa de acces la chestii din sistem – si evident – nu ratam ocazia unui prank de zile mari. Motivul pentru care mi s-a pus pata pe cookie-uri care ar putea fi folosite pentru un prank la adresa proprie … motivul pentru care am varsat literele de mai sus … cu un singur catch … aplicatia nu trebuie sa ruleze ca utilzatorul respectiv in momentul in care se primesc vizite dupa modelul celui de mai sus (si chiar in general).

Disclaimer