Ha debianon mysql-t nézegetnél

ne riasszon el, hogy nem tudsz semmilyen mysql jelszót, elég csak belépned a debian-sys-maint userrel, és a hozzátartozó jelszóval amit az /etc/mysql/debian.cnf fileban találsz, és máris root jogod van mindenhez, broáf.

( _ventura_ v | 2013. 05. 16., cs – 11:03 )

igen, de azt csak a root éri, ha pedig elérik akkor már mind1 hogy azon keresztül mennek be az sql be vagy csak simán root-al kiütik a jelszót ;>

Fedora 17, Thinkpad x61s

Egy root jog egy szerveren nálam nem feltétlen azzal is egyenlő hogy kapott hozzáférést a mysql-hez is.
Nyilván ki tudja ütni, de azt nem tudja sutyiban, ezzel nézegetni meg simán tud...

--------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( hrgy84 | 2013. 05. 16., cs – 11:05 )

A csuf: nem torolheted le a fajlt es nem veheted el a debian-sys-maint jogait, mert akkor hibaval lep ki az init script...
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( petya | 2013. 05. 16., cs – 11:29 )

A debianon kivul minden mas disztribucio normalisan tudja csomagolni a mysqlt.

A helyzet ennel sajnos sokkal rosszabb. Amit te irsz, az egy kb. nem letezo biztonsagi problema (root felhasznaloval hozzaferek a disken levo adatokhoz, broaf). Ami a nagyobb baj, hogy az init script az elejen nyom egy information_schema selectet, ami erinti az osszes tablat (megnezi kell e repair). MyISAMet ma mar nagyon kevesen hasznalnak. MySQL 5.5-ig az innodb_stats_on_metadata be van kapcsolva, ami azt jelenti, hogyha az adott tablan metadata muvelet van, frissulnek a tabla optimizer statisztikai, ami azzal jar, hogy egy par, veletlenszeru page-et elolvas a tablabol. Ez akkor csinal plusz felesleges IO-t, amikor a buffer pool meg ures vagy majdnem ures, tehat az io-ra mashol szukseg lenne. A MySQLben erre van beepitett megoldas (myisam_recover), ami ezt a problemat jol oldja meg, ez teljesen felesleges a debianos init scriptben.

Ami meg rossz ezen kivul, hogy ha kell, ha nem, az apt ujrainditja a szervert.

Na igen, bar a cegnel sok MyISAM tabla van, azert ilyen helyeken meg lehet olyat is csinalni, hogy hetente egyszer csekkolja a rendszer, hogy van-e reparalando tabla, es esetleg megprobal egy automata repairt is. Egy biztos: ez semmikeppen sem packager task, siman rendszergazdai feladat.

Az APT-s cuccra pedig nocomment.

Btw, ezek erintik a nepszeru Ubuntu disztrot is, ezeket a hulyesegeket 1:1 veszik at a Debiantol.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

"Amit te irsz, az egy kb. nem letezo biztonsagi problema (root felhasznaloval hozzaferek a disken levo adatokhoz, broaf)."

Értem, innentől kezve felettébb érdekes miért kódolva vannak a jelszavak a shadow fileban, hiszen ahhoz is csak a root user fér hozzá..., ugye ezt te sem gondoltad így komolyan :)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Ez azert nem ugyanaz, mert mivel a mysql egy nyilt forrasu adatbazis kezelo, ha hozzafersz magukhoz a datafileokhoz (es rootkent hozzafersz) el tudod olvasni oket, mert a formatum ismert. Nem kell hozza futo szerver, a nyers datafile elolvasasahoz a jelszo sem kell, sot ahhoz sem, hogy csv-t csinalj belole, es betoltsd az adatokat egy masik mysqlbe.

Szoval tovabbra is tartom, hogy az nem biztonsagi problema, hogy rootkent hozzaferek egy felcsatolt filesystem fileaihoz.

Attól, hogy fizikai hozzáférésed van, attól még NEM vagy jogosult rá. Sajnos a UNIX-oknak ez egy rohadt nagy hibája, hogy van olyan entitás (UID=0) a rendszerben, ami mindenhez korlátozás nélkül hozzáféréssel rendelkezik. A másik nagy baj, hogy vannak olyan feladatok, amiket meg csak ezzel lehet elvégezni.
Az, hogy root-ként hozzáférsz valamennyi, a rendszerben elérhető, nem titkosítottan tárolt információhoz, az egy, már a tervezés során "beépített" biztonsági probléma.

Első körben az, hogy root-ként hozzáférsz full joggal az online állapotban lévő DB-hez by default. Ez a csomag készítőinek a hibája. Ennél tágabban viszont a UNIX-filozófia hibája, hogy létezik egy mindenek felett álló user, amely valamennyi, a rendszerben tárolt adathoz alapértelmezetten hozzá tud férni. Röviden: mindkettő felvet jogosultsági problémákat.

Abban egyetértünk, hogy a gond nem azzal van _jelen esetben_, hogy hozzáférsz egy uid 0-val bármihez, ez így normális linux alatt.
Itt azzal van a gond, hogy ezzel a jogosultságoddal suttyomban hozzáférhetsz online egy adatbázishoz, amihez alapból a kutya se biztosított jogot neked.
És miért is férhetsz hozzá, mert valami vadbarom cleartext-ben tárol egy olyan jelszót, amivel ha olyan napod van, észrevétlenül törölgethetsz _bármilyen_ adatbázisból bármit.
Na ez a kemény benne, nem az hogy olvasható a file root-al, jó hogy olvasható vele :)))
Az alábbi kérdésre, igen ez egy debianos bug/feature, szerintem szimplán tervezési hiba.
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Az Oracle akkor ugyanettol a tervezesi hibatol szenved. Rootkent csak beirsz annyit, hogy su - oracle, majd sqlplus / as sysdba, es maris hozzafersz az online adatbazishogy DBA jogokkal, hacsak nem varazsolsz mindenfele RBAC-kal a host OS szintjen, amit az oracle nem fog megtenni neked. Es ehhez meg file sem kell amiben barmilyen jelszo lenne. De eros a gyanum, hogy minden adtbaziskezelonel lehet ilyet csinalni root-tal.

Lehetőség nem azonos a jogosultsággal. Az, hogy e kettő keveredik a Unix-okban, azért nagy kár, de amikor kitalálták, akkor megbíztak a root jelszót ismerő személy(ek)ben. Az, hogy a DB-t el lehet indítani a jogosultsági rendszer kikapcsolásával, az "nem bug, hanem feature" - a jelszót ismerő ember fejére esik egy villamos, vagy elüti egy tégla...

Feladat: Adott egy hosting szolgáltatás. Adott rajta egy valamilyen rendszer (irreveláns) ami tárol mysql/ftp/mail/stb adatokat és fájlokat.
Esemény: Halódik a vas/erősebb gépre kell migrálni.
Felhasználó tudja csak a saját jelszavait, amivel hozzáfér a tárolt adatokhoz.
Felhasználó nem elérhető, meghalt, részegen fekszik egy fesztiválon stb.
Tedd át a cuccait (helyenként kicsit módosítva, hogy az új rendszernek megfelelő hívások legyenek) úgy, hogy a root nem fér hozzá.
Elvégzendő 24 órán belül...
Jó az, ha a root hozzáfér, mivel a felhasználó amikor igénybe vette a hosting szolgáltatást, megbízott az ottani rendszergazdában.
Én tartom magam ahhoz, hogy a rendszergazda munkaköre egy bizalmi munkakör.
Aki ezzel a bizalommal visszaél, az nem rendszergazda, hanem cracker.

Ha kritikus, akkor van borítékban jelszó, ha nem kritikus, akkor ráér addig, amíg a jogosult felhasználó (adatgazda) kijózanodik/elérhetővé válik/estébé. Egyébként meg migrálás során nincs gond, hiszen a _leállított_ DB-t el lehet indítani jogosultságok figyelembe vétele _nélkül_, de ez ismert, és elfogadott dolog.
Az viszont nem, hogy élő, működő DB-ben lehet turkálni egy "közös ló" felhasználóval úgy, hogy arra az tárolt adatok tulajdonosának semmiféle ráhatása nincs, az így elvégzett lekérdezésekről nem kap információt, estébé...
HA szükséges, férjen hozzá (de csak akkor!), tehát ne bármikor, bármilyen kontroll és naplózás nélkül.

Ja, az adatok _módosítására_ a felhasználó tudta és beleegyezése nélkül ne formáljon már jogot általában a rendszergazda. Ha bizonyos táblák bizonyos részei függnek a környezettől, akkor legyen egy dbadmin szerepkör, ami ezekre a táblákra vonatkozó update joggal bír, és tessen azt használni.

Rossz a feladatfelvetes. Ha halodik a hardver alatta, akkor miert is kellene a tartolt ADATOKON modositani? Altalaban hardvercseret 1:1 migracioval intezunk, a szoftverkornyezet komolyabb modositasa nelkul.

Rendszerfrissitesnel pedig a legtobb db szoftver visszafele kompatibilis onmagaval, tehat a regebbi verzio altal tarolt adatot az uj fel tudja olvasni, legfeljebb elszoszol az adatok konvertalasaval.

Downgradelni meg nem szokas, eles rendszert foleg nem.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.