Mariadb 10.1.20 und drüber

fueber

New Member
Hallo die Runde,
falls jemand das Problem hat das nach dem SQL Update die Datenbank zwar angelegt wird aber der Benutzer nicht
hat das möglicherweise mit der https://mariadb.com/kb/en/mariadb/simple_password_check/ zu tun
strict_password_validation = OFF in der /etc/my.cnf behebt das Problem vorerst durch deaktivieren

eventuell kann Till etwas dazu sagen ob der Code nicht bereits dahingehend angepasst wurde

lg
Bernhard
 

florian030

Well-Known Member
Das Problem ist, dass der Paßwort-Check / das generierte Paßwort nicht (immer) zu https://mariadb.com/kb/en/mariadb/simple_password_check/ passt.
Also mindestens: eine Zahl, ein Großbuchstabe, ein kleiner Buchstabe, ein Sonderzeichen und min. 8 Zeichen (es sei denn, man ändert die Default-Werte).

Unter System-Konfiguration sollte dann wenigstens Minimale Passwortstärke = gut und Minimale Passwortlänge = 8 stehen.
 

Till

Administrator
Soweit ich sehe ist das ja nur ein optionaler passwort checker in MariaDB, Du musst also nur ein Passwrt verwenden das dem entspricht wie Du ihn bei Dir konfigurert hast. Ist der denn an gewesen bei Dir nach dem Update per default?
 

fueber

New Member
Soweit ich sehe ist das ja nur ein optionaler passwort checker in MariaDB, Du musst also nur ein Passwrt verwenden das dem entspricht wie Du ihn bei Dir konfigurert hast. Ist der denn an gewesen bei Dir nach dem Update per default?

leider ja (steht auf der verlinkten Seite über den Example)
Note that passwords can be directly set as a hash, bypassing the password validation, if the strict_password_validation variable is OFF (it is ON by default).
 

Till

Administrator
Aber ISPConfig setzt Passworte immer als Hash, das heißt dass es egal ist ob diese Funktion an ist denn sie findet nie Anwendung. Dein Problem liegt also vermutlich an etwas anderem.
 

Till

Administrator
Ok, vermutlich mein Verständnisfehler, nochmal gelesen :) Also scheinber deaktiviert MariaDB die Möglichkeit Passworte als hash zu setzen komplett, wenn die Option an ist? Also muss sie grundsätzlich auf off gestellt werden, denn Passworte als Hash zu setzen ist ein Muss, denn ansonsten müsste iSPConfig alle Passworte im Klartext speichern was ein no-go ist.
 

fueber

New Member
Ok, vermutlich mein Verständnisfehler, nochmal gelesen :) Also scheinber deaktiviert MariaDB die Möglichkeit Passworte als hash zu setzen komplett, wenn die Option an ist? Also muss sie grundsätzlich auf off gestellt werden, denn Passworte als Hash zu setzen ist ein Muss, denn ansonsten müsste iSPConfig alle Passworte im Klartext speichern was ein no-go ist.
Jep nach den Deaktiveren funktionierte das ganze ohne weitere änderungen....

was aber komisch ist das der Status nicht ausgewertet wird eventuell ein bug? obwohl der user nicht angelegt wird
bzw. wenn man einen user ändert dieser danach auch nicht mehr existiert (kann ja nicht mehr angelegt werden)

18.04.2017-18:12 - DEBUG - Calling function 'check_phpini_changes' from plugin 'webserver_plugin' raised by action 'server_plugins_loaded'.
18.04.2017-18:12 - DEBUG - Found 2 changes, starting update process.
18.04.2017-18:12 - DEBUG - Replicated from master: REPLACE INTO `web_database_user`
(`database_user_id`,`sys_userid`,`sys_groupid`,`sys_perm_user`,`sys_perm_group`,`sys_perm_other`,`server_id`,`database_user`,`database_user_prefix`,`database_password`,`database_password_mongo`)
VALUES
('89','13','2','riud','riud','','26','c1xxx','c1','*E17AB18C114C4FC23510E8CA8F0D1C59861E7406',NULL)
18.04.2017-18:12 - DEBUG - Calling function 'db_user_update' from plugin 'mysql_clientdb_plugin' raised by event 'database_user_update'.
18.04.2017-18:12 - DEBUG - Processed datalog_id 56029
18.04.2017-18:12 - DEBUG - Replicated from master: REPLACE INTO `web_database`
(`database_id`,`sys_userid`,`sys_groupid`,`sys_perm_user`,`sys_perm_group`,`sys_perm_other`,`server_id`,`parent_domain_id`,`type`,`database_name`,`database_name_prefix`,`database_quota`,`quota_exceeded`,`last_quota_notification`,`database_user_id`,`database_ro_user_id`,`database_charset`,`remote_access`,`remote_ips`,`backup_interval`,`backup_copies`,`active`)
VALUES
('584','1','2','riud','riud','','26','336','mysql','c1test','c1','0','n',NULL,'89','0','','y','xxx.x.xxx.xxx','none','1','y')
18.04.2017-18:12 - DEBUG - Calling function 'db_insert' from plugin 'mysql_clientdb_plugin' raised by event 'database_insert'.
18.04.2017-18:12 - DEBUG - Created MySQL database: c1test
18.04.2017-18:12 - DEBUG - Calling GRANT for c1test with access rw and hosts xxx.x.xxx.xxx, localhost
18.04.2017-18:12 - DEBUG - GRANT for user c1xxx at host xxx.x.xxx.xxx
18.04.2017-18:12 - DEBUG - GRANT ALL PRIVILEGES ON `c1test`.* TO 'c1xxx'@'xxx.x.xxx.xxx' IDENTIFIED BY PASSWORD '*E17AB18C114C4FC23510E8CA8F0D1C59861E7406' success? no
18.04.2017-18:12 - DEBUG - GRANT for user c1xxx at host localhost
18.04.2017-18:12 - DEBUG - GRANT ALL PRIVILEGES ON `c1test`.* TO 'c1xxx'@'localhost' IDENTIFIED BY PASSWORD '*E17AB18C114C4FC23510E8CA8F0D1C59861E7406' success? no
18.04.2017-18:12 - DEBUG - Processed datalog_id 56030
18.04.2017-18:12 - DEBUG - Remove Lock:
/usr/local/ispconfig/server/temp/.ispconfig_lock
 

Werbung

Top