Trotz gesetztem Root-Passwort Login ohne Passwort möglich

Mordor

Registered User
Hallo zusammen
Durch Zufall ist mir heute aufgefallen, dass ich mich auf meinem Entwicklungssystem ohne ein Root-Passwort in Mysql anmelden kann. Es funktioniert also ein
Code:
mysql -u root
Ein
Code:
mysql -u root -p
mit anschlissender Passworteingabe funktioniert aber auch.

Das Passwort ist in der Mysql User-Tabelle auch vorhanden. Ausserdem habe ich versucht es nochmals anzulegen. Sowohl über einen Updatebefehl mit anschliessendem Flush Privileges als auch über mysqladmin. Lege ich es neu mit mysqladmin an, und schreibe nur das neue Psasswort und nicht vorher das alte, wird es trotzdem übernommen.

Ich weiß gerade nicht mehr wo ich noch nachsehen soll. Vielleicht weiß jemand einen Rat.

Gruß Mordor
 
Sorry, fast vergessen:

Hier noch die my.cnf

Code:
#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
# 
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port            = 3306
socket          = /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket          = /var/run/mysqld/mysqld.sock
nice            = 0

[mysqld]
#
# * Basic Settings
#
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
language        = /usr/share/mysql/english
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address            = 127.0.0.1
#skip-networking
#
# * Fine Tuning
#
key_buffer              = 3M
max_allowed_packet      = 16M
thread_stack            = 128K
thread_cache_size       = 8
#max_connections        = 100
table_cache            = 90
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit       = 1M
query_cache_size        = 3M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
#log            = /var/log/mysql.log
#
# Error logging goes to syslog. This is a Debian improvement :)
#
# Here you can see queries with especially long duration
log_slow_queries        = /var/log/mysql/mysql-slow.log
long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
#server-id              = 1
log_bin                 = /var/log/mysql/mysql-bin.log
# WARNING: Using expire_logs_days without bin_log crashes the server! See README.Debian!
expire_logs_days        = 10
max_binlog_size         = 100M
#binlog_do_db           = include_database_name
#binlog_ignore_db       = include_database_name
#
# * BerkeleyDB
#
# Using BerkeleyDB is now discouraged as its support will cease in 5.1.12.
skip-bdb
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
# You might want to disable InnoDB to shrink the mysqld process by circa 100MB.
#skip-innodb
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem



[mysqldump]
quick
quote-names
max_allowed_packet      = 16M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition

[isamchk]
key_buffer              = 16M

#
# * NDB Cluster
#
# See /usr/share/doc/mysql-server-*/README.Debian for more information.
#
# The following configuration is read by the NDB Data Nodes (ndbd processes)
# not from the NDB Management Nodes (ndb_mgmd processes).
#
# [MYSQL_CLUSTER]
# ndb-connectstring=127.0.0.1


#
# * IMPORTANT: Additional settings that can override those from this file!
#
!includedir /etc/mysql/conf.d/
 
Hi,

ist dein mysqld zufälligerweise mit "skip-grant-tables" gestartet?

[EDIT] Da kam die Config doch etwas schneller ;) [/EDIT]

-W
 
Nein ist er nicht.

Ausserdem existiert das Problem nur beim root-login.
Alle anderen User haben nur Zugang mit ihren spezifischen Passwörtern. Ohne kommen diese nicht rein.
 
Das Problem hatte ich erst gestern, nachdem ich ein komplettes Dump aller Datenbanken auf einem neuen Server einspielen wollte - zwar war bei jedem User ein Passwort gesetzt, es wurde aber keins zum Login benötigt.

Letzten Endes habe ich das MySQL-Datenverzeichnis (/var/spool/mysql) verschoben und an den neuen Server angepasst, wonach alles wie gewohnt funktioniert hat.
 
1. Schau nach, ob das Initskript deinen mysqld ohne Rechteprüfung startet (ggf. auch einfach die Ausgabe von `ps aux|grep mysqld` ansehen).
2. Schau nach, ob die Zugangsdaten in ~/.my.cnf stehen.
 
Danke an Roger. Die Userdaten stehen wirklich in der .my.cnf drinnen. Seid wann ist das denn so. Ist mir noch nie aufgefallen. Bei allen anderen Systemen ist das nicht so.
 
Die Zugangsdaten werden (zumindest von MySQL aus) nicht automatisch in die ~/.my.cnf eingetragen. Das hast entweder du selbst vor einiger Zeit gemacht oder die Entwickler deiner Distribution sorgen dafür, dass das Administratorpasswort des MySQL-Servers bei der Installation des Pakets eingetragen wird.
 
Okay, da ich es nicht selber war, könnte es nur bei Update von Etch auf Lenny vorein paar tagen passiert sein. Komische Sache.
Na zum Glück war es nur der Entwicklungsserver hier zu Hause. Die anderen laufen zum Glück richtig.
 
Back
Top