Fórumok
Mi történhetett?
mysql> use mysql;
ERROR 1044 (42000): Access denied for user ''@'localhost' to database 'mysql'
gentoo host alatti gentoo guesten futó mysql-5.1.62-r1 adta nekem ezt...
Nem vagyok mysqlguru, lehet csak lemaradtam valamiről?
Köszi!
Hozzászólások
> ERROR 1044 (42000): Access denied for user ''@'localhost' to database 'mysql'
Ez alapján cseppet sem vagy rootból belépve, hanem üres string júzernévvel próbálkozol...
mysql -u root ...
Pedig úgy rémlik úgy is próbáltam.(Megtaláltam historyban tényleg próbáltam és az is azt adta...) De ott a pont, volt ''@localhost és ''@hostneve sor is a user-ben.
Töröltem, baj? :))
Most már jó. Köszi!
semmi sem baj, csak olyan felhasználóval próbálj belépni, ami (még) benne van a user táblában. mással roppant nehéz lesz :)
az üres felhasználónevű hozzáféréseket én is ki szoktam törölni, az authentikáció nem úri huncutság.
En meg vegig szoktam tolni a mysql_secure_installation scriptet. Instant csinal mindent, ami nekem kell.
--
+1
mysql -u root [-p] [db_name]
-u root : root@localhost lesz a login
-p esetén kérni fogja a jelszót
db_name esetén use database db_name is lefut magától
--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...
Majdnem.
Legyunk mar pontosak, azert ez nem egy bonyolult parancs.
--
:PP
copypasta volt, beneztem :S Kuldj egy kis hamut, raszorom a fejemre.
--
aaaaasssssshhhhh
Ha nincs meg a mysql root jelszavad:
1. állítsd le a mysql-t
2. mysqld --skip-grant-tables -el indítsd
3. mysql -u root (jelszó nélkül beenged)
4. UPDATE mysql.user SET Password=PASSWORD('jelszavam') WHERE User='root';mysql> FLUSH PRIVILEGES;
5. quit
6. leállítod az előzőleg elindított mysqld-t, majd elindítod normál módban.
itt inkabb valami olyan problema van hogy a mysql.user tablaban nincsenek meg (bizonyos) jogok a root bejegyzeshez...
A mysql root felhasznalo es csak egy sima egyszeru felhasznalo annyi kulombseggel hogy a mysql.user tablaban levo bejegyzes altal fel van ruhazva bizonyos extra jogokkal.
ezzel a skip-grant-tables modszerrel (en meg nem probaltam, remelem mukodik) inditsd el a mysql serveredet, de elotte tuzfallal vedd meg hogy csak te ferj hozza.
kerdezd le a root user jogait:
select * from mysql.user where user='root';
nezd meg hogy mihez nincs joga, es add meg neki:
update mysql.user set jog='y' where user='root';
flush privileges;
problema lehet ha tobb root usernevu bejegyzes van, pl egy localhosthoz, egy pedig barhonnan elerheto (host='%')
ha ez a helyzet, akkor szolj es segitunk
Majdnem. A mysql.db tablaban levo bejegyzesek altal van felruhazva jogokkal, a mysql.user tablaban csak a globalis jogok tarolodnak, a db-szinutek pl. nem.
es a skip-grants inditas utan mindossze ennyit kell kiadni:
A tobbinek meg mar skip-grants nelkul belepve is lehet jogot adni.
Viszont en messze elitelem a mysql felhasznalok insert/update/delete altali maceralasat. Errol tessen leszokni. azert vannak fasza sql utasitasok kulon ezekre a feladatokra, hogy ne kelljen tudnod, hogy mit es hogyan tarol a mysql a userekrol. Ha holnaptol fog ldap authot tamogatni, akkor mit fogsz csinalni?
--
bocsi, de az elsoben nincs igazad, a mysql root felhasznalo jogai GLOBALISAK, pont ez a lenyeguk, a db tablaban egy specifikus dbre lehet jogokat adni.
En inkabb megtanulom mi mit hol tarol, es mit csinal vele, eleg sokszor volt mar ra szuksegem. Pl a mi rendszerunkben $domainid_$userspecified formatumuak a mysql felhasznalok es adatbazisok. Kesobb tudtuk meg hogy a _ a db tabla db mezojeben single char wildcardnak felel meg, ezert ahelyett barmilyen 1 karakteres dolgot letrehozhattak a felhasznalok. pl a legtobbszor a _ helyere ? -t irtak (hu/en bill kiosztas valtasa miatt), mi meg nem ertettuk hogy johettek letre. Ha nem tudtuk volna hogy a mysql mit hol tarol, akkor eleg nehez lett volna kinyomozni, nemhogy globalisan javitani a problemat.
(a mysql auth mar idotlen idok ota igy megy, de ha megvaltozik, igerem majd megtanulom a grant parancsokat is.)
Furi, mert a cPanel batran hasznalja az account_db formatumot a db-khez. Hanyas verzioju MySQL-re igaz amit irsz?
Egy dolog ismerni a formatumot, mas dolog pedig kizarolag azt hasznalni az erre szakositott parancsok helyett.
--
a cpanel egy fura allatfaj. Szerencsere nallunk a sajat fejlesztesu rendszerunkkel szemben elegge hatterbe van szorulva, nameg persze eleg sok mindent kell a konzerven modositani hogy biztonsagos legyen ... tudtad hogy kb egy fel eve van hozza ismert rootkit, de megse frissitik a kernelt amivel ezt meg lehetne oldani?
Az oszes binarybol forditott gyari mysql server a mysql.user tablat hasznalha a root jogainak deklaralasahoz. Egy csomo jogot nem is tudsz megadni a db tablan keresztul, pl replikacio, a tejhes server lockolasa, a kulombozo super jogok etc. Ezek nelkul meg van kotve a mysql admin keze rendesen.
Lehet hogy tenyleg szebb megoldas az erre szakosodott mysql parancsokat hasznalni, en megis inkabb kezzel / scripttel szoktam editalni a tablakat ... megszokas, igy alakult ki ... aztan persze flush privileges.
"tudtad hogy kb egy fel eve van hozza ismert rootkit, de megse frissitik a kernelt amivel ezt meg lehetne oldani?"
Mert a cPanel nem frissit kernelt. Nem az o feladata. Hogy a CentOS nem hoz ki uj kernelt - ez viszont tenyleg gyasz.
"Az oszes binarybol forditott gyari mysql server a mysql.user tablat hasznalha a root jogainak deklaralasahoz. Egy csomo jogot nem is tudsz megadni a db tablan keresztul, pl replikacio, a tejhes server lockolasa, a kulombozo super jogok etc. Ezek nelkul meg van kotve a mysql admin keze rendesen."
He? A forrasbol forgatott MySQL is ilyen, sot, tovabbmegyek, a MariaDB is ilyen. A globalis jogok a user tablabol jonnek, a db-lokalis jogok meg a db tablabol. Te magad irtad. Nincs kulonbseg a binarisbol rakott meg a forrasbol telepitett MySQL kozott. A nullarol epitett rendszernel pedig az utolso lepes egy GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION; .
En pont ezert szeretem az erre csinalt parancsokat, nem kell gondolkodnom, hogy "itt egy jog, hol kell engedelyezni?" hanem csak annyit mondok neki, hogy plz. engedelyezd. Es megcsinalja. Mert a technikara alapulo varazslatban az a tuti, hogy mindig mukodik. Ja, es jo esellyel megfeleloen escapeli a db neveket, igy nem lehet kerdojeles meg egyeb randa nevu db-t letrehozni - mint a sima inzertalassal.
--
"Hogy a CentOS nem hoz ki uj kernelt - ez viszont tenyleg gyasz."
vattafak??
A cPanel az nem OS, hanem egy, a CentOS-re epulo termek (hosting solution). Neki nem feladata kernelt patchelni.
Hogy a CentOS nem fixalja a vulnerable kernelt - ez viszont problema.
Vagy valaki valamit nem jol erthetoen fogalmazott meg.
--
cPanel-ben nem vagyok otthon. De ha egy termék(A) egy másik termékre(B) épül, és A termékben nem vezetik át B frissítéseit, az akkor B hibája?
Vagy ha a CentOS lyukas, akkor a RHEL is lyukas?
A cPanel-t alapvetoen CentOS-ra es FreeBSD-re lehet telepiteni (ezek a tamogatott rendszerek). Viszont attol, hogy tamogatja, mint alap rendszert, meg nem lesz feladata a CentOS kerneleit patchelni.
Nem tudom, pontosan milyen vulnerabilityrol van szo, de ha az tenyleg a kernelt (pontosabban a Linux kenrnelt) erinti, akkor azt elsosorban a CentOS fejlesztoinek a dolga lenne patchelni es nem a cPanel-e. De fixme.
--
Na, akkor közelítünk...
Szóval van egy szolgáltató, aki a cPaneljét CentOS-re installálja.
Majd nem frissíti alatt a CentOS-t. És ezért a CentOS csapat a hibás?
Vagy a RHEL-ben javították, de a CentOS-esek nem adták ki a javítást?
Vagy a RHEL-ben sem javították?
(Azon nem akadtam ki, hogy maga alatt nem frissít rendszert a cPanel. ;)
Szerk: CentOS-t azért -a szó szoros értelmében- nem nagyon fejlesztik. Inkább fordítják :)
Stop.
Akkor elmondom megeccer: denke elmondta, hogy vulnerable a kernel, es nincs javitas ra. Nem pontositotta, hogy milyen vulnerabilityrol van szo, igy nem tudom konkretizalni a dolgot, azt sem, hogy ki javitotta, ki nem, kinek a hibaja, vagy egyaltalan, mi a mano folyik itt. Nem tudom, mert denke nem pontositotta a hibat, amirol irt, en pedig nem fogok egy veg nelkuli barchobaba belemenni, mert nincs ertelme.
A CentOS-rol pedig koztudott, hogy nem surun ad ki frissiteseket, kernelhez foleg nem.
En azt probaltam leszogezni, hogy ha van egy Linux kernel vulnerability, akkor azt nem a cPanel fejlesztoinek a feladata befoltozni, vagy arra barmilyen formaban javitast adni, mert ok csak felhasznaloi a Linux okoszisztemanak, egy alkalmazas a cPanel a Linux felett, semmi egyeb. Ugyanugy, ahogy a KDE fejlesztoitol se varja el senki, hogy fixaljak a libstdc++ bugjait.
Ennek fenyeben nem tudom a fenti hozzaszolasodat ertelmezni.
--
Danke, akkor most jön denke. ;)
Ehhez a temahoz a kollegaim jobban ertenek, en tavoltartom magam a cpaneltol mint a tuztol de:
Kb egy fel eve jott ki egy rootkit ami az oszes akkori kernelt megboritotta, kiveve ha nem volt beforgatva mindenfele memoriaterkep kiadasa, vagy memoriaszegmensek randomizalasa (grsec). (a kernel team viharleptekben adott ki javitast)
Amikre a cpanel felmegy:
-bsd mar nem supportalt
-RHEL fizetos (ezert senki nem hasznalja szinte)
-centos
A cpanel teny hogy egy centosra epulo valami, de ettol fuggetlenul, ha te vagy egy olyan ceg, ami sok 10.000 webhosting solutiont LICENCELSZ (men ingyen ugye) es talalnak egy olyan hibat ami a termekedet is erinti az az alatt futo rendszerben akkor:
A: vagy nyomast gyakorolsz a centosra hogy bazzeg adjatok mar ki egy javitott kernelt, me'az oszes termekem torheto miattatok
B: lecserelem a solution alatt futo rendszert, es mar legalabb az ujonnan eladott termekeket nem egy hibas alaprendszerrel adom el.
C: ha valamiert nem tudom megtenni egyiket se akkor kiadok egy patchet reszletes leirassal az installalashoz, ami befoltozza a lyukat az OSZES centos alternativara.
A cpanel egyiket se tette meg igy gyakorlatilag szinte az oszes cpanelhez van mukodo rootkit.
--------------------------------------------------------------------------------------
Viacom Informatikai Kft. Egyedi fejlesztesu, felho alapu webhosting szolgaltatasok. Hureg, Lir, AS.
Elnezest tevedtem, valami modon mar javitottak a hibat, de tenyleg kb egy fel evig nyitva volt a dolog, az x86_64 32bit emulacio hibajat hasznalta ki az exploit.
--------------------------------------------------------------------------------------
Viacom Informatikai Kft. Egyedi fejlesztesu, felho alapu webhosting szolgaltatasok. Hureg, Lir, AS.
A cPanel egyiket se tette meg, mert nem feladata. Az Oracl-nek kotelezo lenne vajon RHEL-t/CentOS-t patchelni, tekintve, hogy az tamogatott operacios rendszer az Oracle RDBMS, a MySQL es a WebLogic Server szamara is?! Nem, mert NEM AZ O TERMEKE. Egyet tehet, feljelentheti a hibat az illetekes bugzillaban, amennyiben az nem tortent meg. Valoszinuleg mire ok oda jutottak, mar megtortent a feljelentes.
A cPanelnek kurva egyszeru az allaspontja: o a CentOS rendszert tamogatja mint alaprendszert, emellett a FreeBSD-t is. Nem felel a kernelert, mert nem epit explicite a kernelre semmit. Amennyiben problema van a CentOS rendszer kernelevel, azt a tulajdonos kotelessege javitani, mivel a cPanel-lel nem erkezett semmifele kernel, igy max jofejsegbol telepithetne valami fixalt kernelt - viszont nem tudhatja, hogy az alaprendszerben milyen kernel van, es miert, pl. CloudLinux. Akar egy kerneloldali vedelemre epulo plugint is megolhet azzal, hogy felerolteti a sajat kernelet.
A cPanel gondozza, patcheli es karbantartja a rendszerre kerulo PostgreSQL, MySQL, Apache es PHP verziokat. Sem kapacitasa, sem lehetosege nincs tamogatni a Linux kernelt - semmilyen formaban - sem ertelme nincs.
Ha nem tetszik a Linux kernel, tessek FreeBSD-re telepiteni a cPanelt. Tamogatott rendszer. Arra nincs rootkit. Vagy tessek kernelt cserelni. Szabadon megteheto.
FreeBSD: valamennyire meg tamogatott, mert a telepitovel erkezik BSD kompatibilis kod is. Lattam par forumot, ahol vitaztak, hogy akkor most az mennyire supportalt.
--
Nem ertek veled egyet a kovetkezok miatt:
1 a bsd mar nem tamogatott mint ahogy feljebb irtam. info a cpanel hivatralos weboldala.
2 ha en kiadok egy termeket es az szar (a felhasznalot kurvara nem erdeklio hogy miert, csak az hogy szar) akkor megteszek mindent hogy kijavitsam. Inkabb felveszek 30 supportos (akik az ezekkel kapcsolatos panaszokat kezelik) helyett 1 hardcore kernel fejlesztot aki kijavitja, meg olcsobb is lesz. Mivel a cpanel igen elterjedt, es a licencelese se ket filler, szerintem bele kellene fernie a budget be.
for the record, a mi rendszerunk soha nem volt sebezheto, nem a "savanyu a szolo" effektus vezeti a kezem :)
--------------------------------------------------------------------------------------
Viacom Informatikai Kft. Egyedi fejlesztesu, felho alapu webhosting szolgaltatasok. Hureg, Lir, AS.
Azert tudjuk mar, hogy mirol beszelunk. Nem egy szar office programrol beszelunk, amit kb. a hulyeknek is hasznalni kell tudni, hanem egy hosting megoldasrol. Ha valaki webhostingra adja a fejet, igenis ertsen mar annyira a linuxhoz, hogy le tudjon tolteni egy ruhes rpm-et a javitott kernellel, es fel tudja onerobol telepiteni, vagy menjen el telefonos muszaki supportosnak a T-hez. Oda pont eleg annyi tudas, amennyit te feltetelezel.
--
Csak a tapasztalat mondatja velem, de ne menjunk bele :)
--------------------------------------------------------------------------------------
Viacom Informatikai Kft. Egyedi fejlesztesu, felho alapu webhosting szolgaltatasok. Hureg, Lir, AS.
Tudom, hogy van Steve Bloody hosting is, de ott a kernel szokik lenni a legkisebb problema. Tartok tole, hogy mar egy CSF felhuzasa is problema.
--
"A CentOS-rol pedig koztudott, hogy nem surun ad ki frissiteseket, kernelhez foleg nem."
most számoltam 25 db kernelt az ötös ághoz, nem tudom, hogy másoknak hasonló intervallumban mennyi jön ki, de ez annyira nem kevés szerintem, pláne, ha minden update után újra is kell indítani a szervereket :-)
igazából a RedHat-nak kellene a dolgait javítani, ami lecsorog a CentOS-ba
ha a CentOS patchelgetne, akkor bukná a bináris kompatibilitást...
"He? A forrasbol forgatott MySQL is ilyen, sot, tovabbmegyek, a MariaDB is ilyen. A globalis jogok a user tablabol jonnek, a db-lokalis jogok meg a db tablabol. Te magad irtad."
Minek adnank a mysql root usernek per db jogokat mikor mar amugyis megvan neki ugyan az csak globalisan?
hidd el, a biinarybol forgatott mysql serverben a kovetkezot fogod talalni:
db tabla ures, table es row tablak uresek, es a user tablaban egyetlen bejegyzes lesz:
host: localhost, vagy %, user:root, password='', es az oszes tobbi jog 'Y'.
--------------------------------------------------------------------------------------
Viacom Informatikai Kft. Egyedi fejlesztesu, felho alapu webhosting szolgaltatasok. Hureg, Lir, AS.
Oke, akkor mashogyan teszem fel a kerdest: milyen tipusu MySQL szervert lattal, ahol a root jogai NEM a user tablabol jottek?
Egyebkent pedig a binarybol forgatott kifejezest legyszives elfelejteni. A binarist nem lehet forgatni. A forrast lehet forgatni, a binarist telepiteni. Binarisbol forgatott... fozelekbol fozott.
--
Igazad van a, a binary dologgal, tenyleg hulyeseget irok. forrasbol forgatott mysql server-t akartam irni.
Minden altalam ismert mysql disztro es forras eseten a mysql root jogai a user tablabol jonnek defaultbol.
--------------------------------------------------------------------------------------
Viacom Informatikai Kft. Egyedi fejlesztesu, felho alapu webhosting szolgaltatasok. Hureg, Lir, AS.