That's right. In 10.4 mysql.user has been converted into a view, which has root@localhost for a definer. So, if you renamed root@localhost, the definer no longer exists.
I'll assign it to serg to provide thoughts on this.
Meanwhile, I suppose you can fix the view by re-creating it with your new account as a definer. Do SHOW CREATE VIEW mysql.user, copy the definition and run is as CREATE OR REPLACE ... DEFINER=... VIEW ....

IMO, this view should be moved to sys schema in future versions. (if and when we get sys schema)

Since 10.4, a root@localhost user must exist for mysql.user to be readable.

If you've renamed root@localhost for more security, you can create a new root@localhost user, for example, like this:

CREATE USER root@localhost ACCOUNT LOCK;

GRANT SELECT ON mysql.global_priv TO root@localhost;

That is you'll have an account that can only select from mysql.global_priv and that nobody can login into.

That root@localhust must exist is incompatible change in 10.4, but is not documented as such. In fact it does not seem to be documented anywhere at all.
https://mariadb.com/kb/en/library/mysqluser-table/ does not mention it.
https://mariadb.com/kb/en/library/authentication-from-mariadb-104/ does not mention it either.
https://mariadb.com/kb/en/library/changes-improvements-in-mariadb-104/ - no single word about that.

Re-opened for documenting

Serg's explanation is wrong. With such minimal privileges for root@localhost mysql_upgrade fails with errors when running mysql_fix_privilege_tables like:

...

Phase 4/7: Running 'mysql_fix_privilege_tables'
ERROR 1356 (HY000) at line 16: View 'mysql.user' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
ERROR 1356 (HY000) at line 68: View 'mysql.user' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
ERROR 1356 (HY000) at line 177: View 'mysql.user' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
ERROR 1356 (HY000) at line 190: View 'mysql.user' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
ERROR 1356 (HY000) at line 325: View 'mysql.user' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
ERROR 1356 (HY000) at line 398: View 'mysql.user' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
ERROR 1356 (HY000) at line 403: View 'mysql.user' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
ERROR 1356 (HY000) at line 412: View 'mysql.user' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
ERROR 1356 (HY000) at line 435: View 'mysql.user' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
FATAL ERROR: Upgrade failed

So root@localhost also needs UPDATE_priv on mysql.global_priv table because there are several

UPDATE user ...

statements in mysql_fix_privilege_tables.

@Alexander Keremidarski The fact that we dont't use the "root" username anymore in his original functions, an other user who have every privilege would be used to make the upgrade, like this :

$> mysql_upgrade -u myAdminUser -p

So I think that "root" doesn't need more privileges, since we can't login with it using @Sergei Golubchik's solution : `ACCOUNT LOCK`.

If it's a question of upgrades, perhaps mysql_upgrade can automatically create a minimal root@localhost if there isn't one?

salle, will that work for you?

Could a system user that can never be logged in (account lock) or have its grants changed fixed this? perhaps something like "dbo@localhost".

This would solve this problem going forward and allow flexibility for system defined views, triggers, routines etc for future features, such as sys_schema etc.

yes, it can be a solution (scripts should correctly remove root user)

May be it could be easier to create a dummy root@localhost user as I described above

I am trying to implement solution very similar to mysql one (with special user), so one will need to just run upgrade script to fix problem of absent root.

commit 15a750f2501b5ea8a5bc09c7047b8cef7e92d6ab (HEAD > bb-10.4MDEV-19650, origin/bb-10.4-MDEV-19650)
Author: Oleksandr Byelkin <sanja@mariadb.com>
Date: Wed Feb 19 17:50:30 2020 +0100

MDEV-19650: Privilege bug on MariaDB 10.4

Also fixes:
MDEV-21487: Implement option for mysql_upgrade that allows root@localhost to be replaced
MDEV-21486: Implement option for mysql_install_db that allows root@localhost to be replaced

Add user mariadb.sys to be definer of user view
(and has right on underlying table global_priv for
required operation over global_priv
(SELECT,UPDATE,DELETE))

Also changed definer of gis functions in case of creation,
but they work with any definer so upgrade script do not try
to push this change.

ok to push

For documentation sake :

A new user was added : mariadb.sys (script of creation new database or upgrade will create it).
mysql.user view belong now to it and executes with definer priveleges (SELECT,UPDATE,DELETE) which allow to remove root user without consequences.

main.upgrade_MDEV-19650 doesn't restore PROXY privilege for root, that's what makes perfschema.column_privilege test fail later. Something like this should fix it:

diff -u -r /data/src/bb-10.4-MDEV-19650/mysql-test/main/upgrade_MDEV-19650.result main/upgrade_MDEV-19650.result

--- /data/src/bb-10.4-MDEV-19650/mysql-test/main/upgrade_MDEV-19650.result	2020-05-05 21:28:40.733008297 +0300

+++ main/upgrade_MDEV-19650.result	2020-05-06 15:28:30.482277576 +0300

@@ -3,6 +3,7 @@

 use mysqltest1;

 create table save_global_priv as select * from mysql.global_priv;

 create table save_tables_priv as select * from mysql.tables_priv;

+create table save_proxies_priv as select * from mysql.proxies_priv;

 create table mysql.save_proc like mysql.proc;

 insert into mysql.save_proc select * from mysql.proc;

 set @save_sql_mode= @@sql_mode;

@@ -145,6 +146,7 @@

 mtr.test_suppressions                              OK

 mysqltest1

 mysqltest1.save_global_priv                        OK

+mysqltest1.save_proxies_priv                       OK

 mysqltest1.save_tables_priv                        OK

 performance_schema

 test

@@ -190,9 +192,11 @@

 # restore environment

 delete from global_priv;

 delete from tables_priv;

+delete from proxies_priv;

 delete from proc;

 insert into mysql.global_priv select * from mysqltest1.save_global_priv;

 insert into mysql.tables_priv select * from mysqltest1.save_tables_priv;

+insert into mysql.proxies_priv select * from mysqltest1.save_proxies_priv;

 rename table proc to bad_proc;

 rename table save_proc to proc;

 drop table bad_proc;

diff -u -r /data/src/bb-10.4-MDEV-19650/mysql-test/main/upgrade_MDEV-19650.test main/upgrade_MDEV-19650.test

--- /data/src/bb-10.4-MDEV-19650/mysql-test/main/upgrade_MDEV-19650.test	2020-05-05 21:28:40.733008297 +0300

+++ main/upgrade_MDEV-19650.test	2020-05-06 15:27:45.034838619 +0300

@@ -6,6 +6,7 @@

 use mysqltest1;

 create table save_global_priv as select * from mysql.global_priv;

 create table save_tables_priv as select * from mysql.tables_priv;

+create table save_proxies_priv as select * from mysql.proxies_priv;

 create table mysql.save_proc like mysql.proc;

 insert into mysql.save_proc select * from mysql.proc;

 set @save_sql_mode= @@sql_mode;

@@ -138,9 +139,11 @@

 delete from global_priv;

 delete from tables_priv;

+delete from proxies_priv;

 delete from proc;

 insert into mysql.global_priv select * from mysqltest1.save_global_priv;

 insert into mysql.tables_priv select * from mysqltest1.save_tables_priv;

+insert into mysql.proxies_priv select * from mysqltest1.save_proxies_priv;

 rename table proc to bad_proc;

 rename table save_proc to proc;

 drop table bad_proc;