UServerwaltung in MySQL

[knebb]

Yohoo!

Die Sache <TOPIC> ist mir in MySQL vollkommen unklar. Gibt es dazu ein paar gute Links?

Ja, es ist mir klar, daß MySQL die Nutzer "user@host.de" und "user@zweiter.de" als ZWEI Nutzer ansieht- und nicht als ein Nutzer mit verschiedenem Hostanteil.
Ja, es gibt den Wildcard '%'.

Konkrete Fragen:
1. Wie stellt MySQL den Hostteil fest? Woher bekommt es die Daten eben für "user@host1", anstelle von "user@192.168.0.3".
2. Ich habe via MySQL Administrator (Windows-Frontend, direkt von mysql.com) einen User angelegt. Ohne Hostteil-Einschränkung. Der Versuch zu connecten scheitert lokal: "denied for 'user'@'localhost'". Mache ich das ganze von einem zweiten Rechner, ist alles ok :?: Trage ich als Host den localhost ein, geht's auch von da- und auch noch von dem anderen Server...
3. Gibt es eine definierte Reihenfolge, in der er die User überprüft? Z.B. connect von user@localhost hat mehr Privilegien als user@%. Welcher wird nun genommen?
4. Wann nimmt er IP? Trage ich user@localhost ein, hat er Zugriff, trage ich user@127.0.0.1 ein, kriegt er keinen Zugriff....

Ich finde das Ganze sehr merkwürdig. Hilfe!


Grüße

[Joe User]

http://dev.mysql.com/doc/refman/5.0/en/ ... ystem.html
http://dev.mysql.com/doc/refman/5.0/en/ ... ement.html

[knebb]

Die Links sind recht gut- insbesondere weil ich die auch schon kannte ;)

Aber so richtig helfen tun die mir bei meinen Fragen nicht. Also gut, nochmal soweit wie ich das verstanden habe:

Bei einem Verbindungsaufbau prüft der MySQL-Server die Paramter "username", "host" und "password". Erst wenn alles drei paßt, wird der Zugriff gewährt. Das ist klar.
Frage: woher bekommt der Server den Teil "host" bei einer Anfrage? Der mysql-Client gibt den ja nicht mit, oder? Wenn ja, als welchen Wert?

Gilt "first match" oder "best match"?


Grüße

[lines]

Hallo

Bei einem Verbindungsaufbau prüft der MySQL-Server die Paramter "username", "host" und "password". Erst wenn alles drei paßt, wird der Zugriff gewährt. Das ist klar.
Frage: woher bekommt der Server den Teil "host" bei einer Anfrage? Der mysql-Client gibt den ja nicht mit, oder? Wenn ja, als welchen Wert?

Der server weiss von wo der client kommt.
Beispiel:

Code: Select all

$ mysql -hrantanplan -uichbins -p
Enter password: 
..
mysql> show processlist;
| Id     | User  | Host                | db    | Command | Time | State | Info             |
| 157521 | ichbins  | 213.229.xx.xx:13952 | NULL  | Query   |    0 | NULL  | show processlist | 

da ich eine dynamische IP habe ist der Zugriff(host) auf % sonst würde die Verbindung von extern nicht klappen.

Gilt "first match" oder "best match"?

?

lg

[knebb]

Frage: woher bekommt der Server den Teil "host" bei einer Anfrage? Der mysql-Client gibt den ja nicht mit, oder? Wenn ja, als welchen Wert?

Der server weiss von wo der client kommt.
[/quote]
Klar weiß der, von welchem Rechner die Vbdg. kommt- das ist ja aus dem TCP/IP-Protokoll schon klar.
Aber woher bekommt der MySQL-Server den für die Authentifizierung genutzten Hostnamen? Über DNS-Abfragen via /etc/resolv.conf? Warum hat er dann einen Unterschied zwischen "localhost" und "127.0.0.1"?
Das müßte ja das gleiche ergeben...

da ich eine dynamische IP habe ist der Zugriff(host) auf % sonst würde die Verbindung von extern nicht klappen.

Auch klar. Aber mich interessiert ja weniger die pauschale Freigabe "%", sondern die speziellen Restriktionen. Mit "pauschal für alle frei" verstehe ich das System auch ;)

Gilt "first match" oder "best match"?

?

Was ist, wenn sowohl "%" als auch z.B. "client1" eingetragen ist und ich mich von client1 connecten will? Welche Berechtigung nimmt er?

[Joe User]

Über DNS-Abfragen via /etc/resolv.conf?

Ja, sofern in der Config erlaubt.

Warum hat er dann einen Unterschied zwischen "localhost" und "127.0.0.1"?

127.0.0.1 = TCP/IP
localhost = Socket

[os-t]

Was ist, wenn sowohl "%" als auch z.B. "client1" eingetragen ist und ich mich von client1 connecten will? Welche Berechtigung nimmt er?

Ich glaube zu wissen, dass er best match verwendet.
Liegt wohl darin begründet dass MySql die User ja auch per SQL abfragt, also in etwas so:

Code: Select all

select * from users where user like "user@hostname"

Jetzt versucht er Stück für Stück die Wildcards zu setzen bis er nen ordentlichen Treffer hat.

Das alles ist natürlich exemplarisch und intern ein wenig anders organisiert, aber im Prinzip macht er wohl genau das...

Gruß Markus

[knebb]

Über DNS-Abfragen via /etc/resolv.conf?

Ja, sofern in der Config erlaubt.

Parameter dazu? Und onst macht er es ausshcließlich über IP?

127.0.0.1 = TCP/IP
localhost = Socket

Das mag tatsächlich für localhost zutreffen- aber wie begründest Du Das bei z.B. "10.3.76.2" und "clientrechner"?
Mir ist einfach nicht klar, woher er den Hostteil für die Authentifizierung nimmt. Wie stellt der Server diesen fest? Liefert der Client den mit? Macht er Resolver-Auflösung? Bei nur IP ist das wohl klar, weil er dann ja die IP-Adresse des Clients kennt...

[duergner]

Das wurde dir doch oben schon gesagt. Dein Server versucht da einfach den DNS Namen zu einer IP zu finden, also ein simpler DNS Lookup.

[isotopp]

1. Wie stellt MySQL den Hostteil fest? Woher bekommt es die Daten eben für "user@host1", anstelle von "user@192.168.0.3".

MySQL holt sich mit getpeername() die Adresse zur Verbindung und dann mit gethostbyaddr() den Namen zu dieser Adresse aus dem DNS. Dadurch wird die Sicherheit von MySQL an die Sicherheit von DNS gebunden, was für viele Zwecke eine schlechte Idee ist. MySQL kann man das DNS-Abfragen mit "skip-name-resolve" in der my.cnf abschalten. Dann werden nur noch IP-Nummern und "localhost" bearbeitet.

2. Ich habe via MySQL Administrator (Windows-Frontend, direkt von mysql.com) einen User angelegt. Ohne Hostteil-Einschränkung. Der Versuch zu connecten scheitert lokal: "denied for 'user'@'localhost'". Mache ich das ganze von einem zweiten Rechner, ist alles ok :?: Trage ich als Host den localhost ein, geht's auch von da- und auch noch von dem anderen Server...

Der String localhost ist in Unix-MySQL magisch. Er wird auch dann ausgewertet, wenn skip-name-resolve in Kraft ist. Er bezeichnet Verbindungen, die über Unix-Domain-Sockets aufgebaut werden statt über TCP/IP.

Ein "%"-Wildcard enthält localhost nicht. "%"-Wildcards decken alle TCP/IP Adressen ab, schließen aber Unix-Domain-Sockets nicht mit ein. Daher braucht man root@localhost und root@%, wenn man alles abdecken will.

3. Gibt es eine definierte Reihenfolge, in der er die User überprüft? Z.B. connect von user@localhost hat mehr Privilegien als user@%. Welcher wird nun genommen?

localhost ist magisch.

Ansonsten hat beim Hostteil der genauere Match Vorrang vor dem ungenaueren Match. Das ist besonders dämlich, wenn man ""@hostname und "user"@"%" hat, denn hier wird der "" User wegen des genauen Hostname-Matches vor dem Wildcard-User bevorzugt.

4. Wann nimmt er IP? Trage ich user@localhost ein, hat er Zugriff, trage ich user@127.0.0.1 ein, kriegt er keinen Zugriff....

127.0.0.1 ist eine TCP/IP-Verbindung zu localhost. localhost ist eine Unix-Domain-Socket Verbindung auf dem lokalen Rechner.

Ich finde das Ganze sehr merkwürdig.

Das liegt daran, daß es merkwürdig ist. Das Rechtesystem ist einer der ältesten Teile von MySQL und bisher noch nie modernisiert worden.



Grüße[/quote]

[isotopp]

Liegt wohl darin begründet dass MySql die User ja auch per SQL abfragt, also in etwas so:

Code: Select all

select * from users where user like "user@hostname"

MySQL fragt die User nicht per SQL ab.

MySQL lädt bei FLUSH PRIVILEGES die mysql.user, mysql.db, mysql.tables_priv, mysql.columns_priv und mysql.procs_priv in den Speicher und verwendet dazu die Lowlevel-MyISAM-Handler Funktionen um die Tabelle zu dumpen. Daher ist es nicht möglich, den Table Type für diese Tabellen zu ändern.

Beim Login werden die im Speicher befindlichen Daten der mysql.user Tabelle durchsucht, um den User reinzulassen oder nicht. Für jedes Kommando werden die im Speicher befindlichen Daten aller fünf Tabellen geprüft um die effektiven Rechte für das Kommando zu prüfen.

CREATE USER, RENAME USER, DROP USER, GRANT und REVOKE implizieren ein internes FLUSH PRIVILEGES.

[knebb]

Das liegt daran, daß es merkwürdig ist. Das Rechtesystem ist einer der ältesten Teile von MySQL und bisher noch nie modernisiert worden.

Danke für die Erklärung. Ich glaube, jetzt habe ich es auch verstanden. Zur Ergänzung habe ich noch in der MySQL-Doku etwas gefunden, was mir das Ganze auch etwas besser verdeutlicht hat:
http://dev.mysql.com/doc/refman/4.1/en/dns.html

EOT

Christian

[knebb]

1. Wie stellt MySQL den Hostteil fest? Woher bekommt es die Daten eben für "user@host1", anstelle von "user@192.168.0.3".

MySQL holt sich mit getpeername() die Adresse zur Verbindung und dann mit gethostbyaddr() den Namen zu dieser Adresse aus dem DNS. Dadurch wird die Sicherheit von MySQL an die Sicherheit von DNS gebunden, was für viele Zwecke eine schlechte Idee ist.

Jetzt dachte ich, daß ich es endlich kapiert hätte. Scheint aber nicht so. :oops: Das Teil bringt mich zur Verzweiflung.

Folgende Systeme stehen hier:
1x lokaler DNS
1x mysql-Server
2x client

Der Verbindungsversuch an mysql scheitert wegen fehlender Benutzerberechtigung:

Code: Select all

mail:/ # mysql -h mysql1 -u user -pxxxxxx
ERROR 1045 (28000): Access denied for user 'user'@'client1.domain.de' (using password: YES)
mail:/ #

Er löst also nach Host "client1.domain.de" auf. Ein paar Tests ergeben folgendes Bild:

Code: Select all

mysql1:~ # ping client1.domain.de
PING client1.domain.de (2.3.4.5) 56(84) bytes of data.
64 bytes from reverse.your-server.de (2.3.4.5): icmp_seq=1 ttl=246 time=14.3 ms

D.h. er löst client1.domain.de auf eine externe, öffentliche IP auf. Was für das ping ja auch korrekt ist.
Weiter geht's ohne fqdn:

Code: Select all

mysql1:~ # ping client1
PING client1.int.domain.de (192.168.0.4) 56(84) bytes of data.
64 bytes from client1.int.domain.de (192.168.0.4): icmp_seq=1 ttl=64 time=0.117 ms

Daraus ist erkennbar, daß er mit Hilfe der Resolver-lib den richtigen internen Hostnamen an "client1" ranhängt. Ok, muß eigentlich nur noch die Reverse-Auflösung geprüft werden:

Code: Select all

mysql1:~ # dig -x 192.168.0.4

; <<>> DiG 9.2.3 <<>> -x 192.168.0.4
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56702
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;4.0.168.192.in-addr.arpa.       IN      PTR

;; ANSWER SECTION:
4.0.168.192.in-addr.arpa. 86400  IN      PTR     client1.int.domain.de.

;; AUTHORITY SECTION:
0.168.192.in-addr.arpa.   86400   IN      NS      ns2.int.domain.de.

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jun 27 08:30:34 2006
;; MSG SIZE  rcvd: 113

Zeigt, daß auch die Reverse-Auflösung funktioniert. Somit läuft der DNS vollständig korrekt.

Nur:
Wo, um alles in der Welt hat mysql den externen Hostnamen her? :evil:

[Joe User]

Code: Select all

mail:/ # mysql -h mysql1 -u user -pxxxxxx

mysql1 != client1

[knebb]

Code: Select all

mail:/ # mysql -h mysql1 -u user -pxxxxxx

mysql1 != client1

Klarm sind ja auch zwei unterschiedliche Rechner. Liefert der Client den Hostnamen mit? Hmmmm....

Gerade nochmal überprüft- ja, es gab ein DNS-Problem auf dem Client. Obwohl, der client2 (von dem aus es problemlos geht) greift auf den gleichen DNS zu. :roll: :?:

Auf jeden Fall bekomme ich bei der Fehlermeldung jetzt den internen Hostnamen geliefert. Ein Schritt weiter.

Das ist echt eine /&$&%§$%

Auf jeden Fall scheint es jetzt zu gehen...

Danke für den Tip, daß es wohl am DNS des Clients lag.