nikitamalyavin, if we add a separate table it could make sense to address MDEV-27205 at the same time. And it could make sense to use a JSON field for the details.

Finding a good name is always tricky. Ideas are USER_DETAILS, USER_USAGE, USER_CONNECT_INFO, USER_STATUS

Thanks for another reference, ralf.gebhardt! Yes, MDEV-27205 absolutely makes sense to be put in the same table. As I can see by the code, we currently don't store last login time internally, so an extra effort will be required.

Since all these fields bend around user login details, my ideas are:
AUTH, USER_ACCESS, USER_LOGIN, LOGON

INFORMATION_SCHEMA.LOGON sounds the most decent to me, but we won't be able to add more general information about users there.

Finally I came across with the following implementation:

• The view will iterate through the acl_users array under a single critical section. Given the fact that nearly the same is done during other operations (like login, etc), it should be fine, and will not disrupt already logged in users' performance.
• The unprivileged user will see their own info. The access is optimized with binary search.
• The table name is LOGON.
• At the same time, password expiration timestamp has been added, so MDEV-32218 can be closed at once.

serg please review 9e5d4dfc, branch bb-11.5-password-errors

bb-11.5-password-errors d1ec5274161db821de7ae9ce9be2dd583ef23c2d is ok to push into 11.5.

Minor problem- if user has SELECT privileges to mysql.global_priv, then he should be able to see also all users after "select * from information_schema.users;" (similar to the situation when the user has SELECT privileges to the whole mysql.* database )

create user a@localhost;

connect(con1, localhost, a);

select * from information_schema.users ;

--connection default

grant select on mysql.global_priv to a@localhost;

--connection con1

select * from information_schema.users ;

select * from mysql.global_priv;

--connection default

grant select on mysql.* to a@localhost;

--connection con1

select * from information_schema.users ;

--connection default

drop user a@localhost;

serg, it seems that an access to mysql.global_priv is not done as we thought – not through show_global_privileges, which was a common sense, but rather as to a usual table...

Anyway, I don't see a problem. It's not consistent across implementations (SHOW GRANTS requires select on mysql.*), and we can require a privilege different from mysql.global_priv.