MDEV-39290 mytop use invoking login as default user on Unix#4918
Conversation
gkodinov
left a comment
There was a problem hiding this comment.
Thank you for your contribution! This is a preliminary review.
LGTM. I'd also explore the possibility of a regression test, but that's highly optional.
Please stand by for the final review.
|
This has two approvals. Why wasn't it merged? |
it needs to pass the buildbot tests first, Otto. In progress. |
Is there something you can to do trigger the buildbot tests? They seem to have been pending for 3 weeks? |
On non-Windows systems, use the invoking user's login name as the default MariaDB username instead of hardcoding root. Resolve the username from getpwuid($<), falling back to LOGNAME, USER, and finally root. Keep the existing root default on Windows. This makes mytop behave more like the mysql and mariadb clients and avoids confusing authentication failures on systems where local socket access is configured for the OS user rather than root. Also update the connection error text and POD to describe the actual default behavior.
I'm doing my best. And monitoring it actively. |
I was waiting for a 13.0 branch, but apparently that is getting forked off |
mytopdefaults the database user toroot.On Unix, the
mysqlandmariadbclients use the current OS login when no user is specified. Because of that difference,mytopmay try to connect asroot@localhostand fail on setups where localunix_socketaccess is configured for the normal user instead ofroot.This patch changes the default on non-Windows systems to the invoking login name, using
getpwuid($<)first, thenLOGNAME, thenUSER, and finallyroot. Windows keeps the existing default ofroot.It also updates the connection failure message and POD so the documented defaults match the actual behavior.
Jira ticket: Fixes MDEV-39290.
Testing
Manual checks on Debian 13 with MariaDB 11.8.6 client:
As non-root, with no
~/.mytopand no-u:mytop -h 127.0.0.1 -P 65534 -b -s 1Result: error text shows
username ... "testuser"and(default is "testuser").With both
root@localhostandtestuser@localhostusingunix_socket:su - testuser -c 'mytop -b -s 1'Result: connects and prints status.
As
testuser, forcing-u root:su - testuser -c 'mytop -b -s 1 -u root'Result: uses
rootas requested, message still shows(default is "testuser").As root:
sudo mytop -b -s 1Result: works with socket-authenticated
root.