Can't create new user or change passwd

[nunix2]

Hi

I just updated postfixadmin from 3.2.4 to 3.3.3. Ran upgrade.php to update sql db.
After login, i can see all domains, users, etc.
I tried to change a user (mailbox) passwd and got a blank page. Password is not changed.
I have deleted one mailbox account and it deletes OK.
I tried to create a new mailbox account and also got a blank page. I have checked the database, and this last process only creates an entry on table ALIAS. Nothing is created on MAILBOX table.

Rolled back to 3.2.4, and all back to normal.
Thanks

[DavidGoodwin]

Hi - thanks for the bug report.

What password backend are you using?

Are there any relevant messages in PHP's error log (perhaps Apache's error log?)

[nunix2]

Hi David,

I am using mysql_encrypt/SHA as backend.
Also associated to cyrus-imap

I tried to look for errors, but i found nothing.
Is there a way to increase debug level on postfixadmin?

Also, if you need I can arrange shell access to this server, by team viewer.

PHP 7.4.14
httpd-2.4.46
cyrus-imapd-3.2.4

Thanks

[DavidGoodwin]

Hm, OK ... this is a regression from 5151b86

I changed it from giving a fairly weak password (sha1) due to :

$res= db_query_one("SELECT ENCRYPT(:pw) as result", ['pw' => $pw]);

to using blowfish or whatever $6$ is meant to stand for -

$res= db_query_one("SELECT ENCRYPT(:pw, CONCAT('$6$', SHA2(RANDOM_BYTES(64), '256'))) as result", ['pw' => $pw]);

From testing that, it looks like RANDOM_BYTES() isn't supported by all MySQL variants, so that statement will fail and possibly cause a blank page?

I see this in my server's error log :

[16-Jan-2021 21:39:58 Europe/London] Invalid query: SQLSTATE[42000]: Syntax error or access violation: 1305 FUNCTION postfixadmin.RANDOM_BYTES does not exist caused by SELECT ENCRYPT(:pw, CONCAT('$6$', SHA2(RANDOM_BYTES(64), '256'))) as result
[16-Jan-2021 21:39:58 Europe/London] PHP Fatal error:  Uncaught Exception: DEBUG INFORMATION: SQLSTATE[42000]: Syntax error or access violation: 1305 FUNCTION postfixadmin.RANDOM_BYTES does not exist<br/> Check your error_log for the failed query in /home/david/src/...../functions.inc.php:1830
Stack trace:

See 910490e which should fix it.

If you can confirm that'd be great....

[nunix2]

Hi again,

Tried both possible solutions but still get the same issue. Blank page :(

btw, sql is:
mariadb-10.4.17

Once more, if you need to get in, please let me know
Thanks

[DavidGoodwin]

Hmm, just to make sure, does SQL like work when you're logged into mysql ?

select encrypt('foobar', CONCAT('$6$', SHA2('bazbaz', '256')));

work ?

I'm kind of surprised you're not seeing any errors logged anywhere. Does the virtual host you're using for Postfixadmin contain an ErrorLog definition?

[DavidGoodwin]

@nunix2 if you're still not seeing any error logged anywhere, try putting something like ini_set('error_log', '/tmp/error.log'); in your config.local.php file, and then check that file when it white-screens.

If you're using systemd, I have a feeling you might need to do find /tmp -name error.log to locate it.

[nunix2]

Hi, Tried all.
this system is made with 3 server: 1 mail server (postfix+cyrus-imap+pam-mysql), 1 sql server (mariadb), 1 apache server for postfixadmin and webmail.
Postfixadmin works well with version 3.2.4. Some new features are welcome on 3.3.3, the reason to upgrade.

About troubleshooting:
added ini_set('error_log', '/tmp/error.log'); at the begining to the file, just after global $CONF; . Still no errors on /tmp/error.log.

Vhost config as the line to write errors: ErrorLog /www/.../logs/error.postfixadmin.nunix-it.pt.log . Also no errors regarding this issue.

On functions.inc.php did the configs above. Tried several (some are commented, but tried them):
if ( $pw_db ) {
// $res = db_query_one("SELECT ENCRYPT(:pw,:pw_db) as result", ['pw' => $pw, 'pw_db' => $pw_db]);
// $salt = _php_crypt_generate_crypt_salt();
// $res = db_query_one("SELECT ENCRYPT(:pw, CONCAT('$6$', '$salt')) as result", ['pw' => $pw]);
$res = db_query_one("SELECT ENCRYPT(:pw, CONCAT('$6$', SHA2(RANDOM_BYTES(64), '256'))) as result", ['pw' => $pw]);

Also, at config.local.php change the $CONF['authlib_default_flavor'] = 'SHA'; to 'crypt'
did not work also. This should be used only it $CONF['encrypt'] == 'authlib', which is not the case !

Moved back do 3.2.4 again.

[DavidGoodwin]

Just to confirm - stick die('foobarbaz'); into the functions.inc.php just before the db_query_one() calls and try again ?

I'm wondering if you're editing the wrong code?

Failing that - can you message me on irc (GingerDog) and I'll try and help some other way.

[nunix2]

Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 415463
Server version: 10.4.17-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>
MariaDB [(none)]>
MariaDB [(none)]>
MariaDB [(none)]> select encrypt('foobar', CONCAT('$6$', SHA2('bazbaz', '256')));
+------------------------------------------------------------------------------------------------------------+
| encrypt('foobar', CONCAT('$6$', SHA2('bazbaz', '256'))) |
+------------------------------------------------------------------------------------------------------------+
| $6$d41621c1763fa3f2$3zFd5RiYuLroo.bb1EN0mv1pv273FKZ0w2CYBCTnSCjB1QoRTGnGYrWeauKqGQR/yTv9j2HQlJzqTwymGKxU00 |
+------------------------------------------------------------------------------------------------------------+
1 row in set (0.008 sec)

[nunix2]

Same effect: Blank page

IRC .... long long time that don't use it. Will try !

[DavidGoodwin]

In the above, the die(...) needed to be just before the other db_query_one() call ..... it would only have been triggered for existing users. You need it to be in the other half of the 'if' statement (somewhere around the stackexchange comment).

IRC - sorry - I can see we just "missed" each other.

If you want, you can email me (david-at-codepoets.co.uk) or twitter (@theGingerdog).

I'm mostly available during UK work hours .....

[nunix2]

Good morning,
Ok, tested as you said and got this page:

Regarding: "See 910490e which should fix it."
should I try also to add the code after the 2nd db_query_one() call?

Thanks

[DavidGoodwin]

I think this is now fixed. The underlying problem was that the MySQL server needed 'mysql_upgrade' running - to fix an error with the 'proc' table (error was viewable in the FPM error log).