[MDEV-9321] Client plugin dir not automatically determined Created: 2015-12-24  Updated: 2022-01-07  Resolved: 2022-01-07

Status: Closed
Project: MariaDB Server
Component/s: Scripts & Clients
Affects Version/s: 5.5, 10.0, 10.1
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Vladislav Vaintroub Assignee: Sergei Golubchik
Resolution: Cannot Reproduce Votes: 0
Labels: None

Attachments: File MDEV-9321-basedir.diff    

 Description   

At least on Windows, server is always able to correctly determine correct client plugin dir, no matter if it is started from unpacked ZIP or in MSI. It finds mysql_home, as parent of the directory where mysqld.exe is located (using GetModuleFileName to get mysqld.exe's path), then it sets the plugin_dir as $mysql_home/lib/plugin.

Clients do not have the same logic, so whenever I start

mysql -usome_user

which needs client plugin, it dies with rather unspecific message , like below

C:\work\gssapi\_CPack_Packages\win32\ZIP\mariadb-10.1.9-win32>bin\mysql -uwlad
 
ERROR 2059 (HY000): Authentication plugin 'auth_gssapi_client' cannot be loaded: The operation completed successfully.

Looking with ProcessMonitor, mysql.exe tries to load it from the hardcoded path PLUGINDIR
C:\MariaDB10.1\lib\plugin. That path is btw almost never correct, as we're installing MSI by default into C:\Program Files\MariaDB 10.1 , or, for 32bit on x64, into C:\Program Files(x86)\MariaDB 10.1 , but this is a different story.

It is a little awkward to start mysql.exe with "--plugin-dir=C:\Program Files(x86)\MariaDB 10.1\lib\plugin", and whatever the path needs to be for the unpacked ZIP.

Ideally, every client that can load plugins would implement the same logic as server, i.e resolving default path as _ ../${INSTALL_PLUGIN_DIR}_ relative to the location of the client binary.

 Comments   
Comment by Vladislav Vaintroub [ 2015-12-24 ]

Assigning to Serg for now. Not sure where this resolve path logic should go, clients e.g mysql, client_plugin.cc, my.ini's or elsewhere.
Also there might be equivalents on systems other than Windows to determine the path of currently running process (proc flle system on Linux for example)

Comment by Sergei Golubchik [ 2019-09-12 ]

Attached the patch. Please, review and suggest how to test it.

Note, that it's using GetFullPathName(argv[0]) now, not GetModuleFileName.

Can be used for clients too, but this patch doesn't do it.

Comment by Vladislav Vaintroub [ 2020-03-25 ]

Hi serg. This bug is about clients, not about the server.

As far as I'm concerned, on Windows, the server is not broken, and GetFullPathName() worked reliably this far.
Fixing server on Linux was not what this bug was about. I would not mind this addition personally, given there is another bug report about it, but this one is just about clients.

argv[0], I'm not so sure about it, I'd prefer something that works without this extra info. On Linux you could use /proc to get current executable (hopefully), on Windows you can use GetModuleFileName(). Perhaps, you'd need something for BSD, that requires argv[[0] and what not, but less reliance on argv[0], the better.

Why are environment variables looked up? I've never found any mentioning of them in the documentation. is it something that mysqld_safe is using, internally? But then again, mysqld_safe seems to start mysqld with the basedir parameter, so perhaps looking up basedir based on undocumented environment is not necessary?

I'm not sure how to test it generally, once the bug is fixed.

As for testing , I think the best is unpack bintar /ZIP , create user with authentication plugin (something that requires both client shared libraries) and execute some SELECT 'hello' as newly user, using command line client. maybe ed25519 can be used for this.

I do not have a good proposal how to test that in MTR, unless we start to create executables and libraries such that the directory layout is similar to the installation
Eg use
${CMAKE_BINARY_DIR}/out/${CMAKE_INTDIR}/bin as OUTPUT_DIRECTORY for executables, and ${CMAKE_BINARY_DIR}/out/${CMAKE_INTDIR}/lib/plugin f or plugins.
(But this is clearly be outside of the scope of this bug)

Comment by Sergei Golubchik [ 2020-04-02 ]

But then it should be done in C/C, for all clients, shouldn't it?

Comment by Vladislav Vaintroub [ 2020-04-02 ]

Hmm, not sure. Our clients, that are usually in "bin" directory under the installation root, could resolve the default plugins path as ../lib/plugin . For other clients , that may be using C/C indirectly, C/ODBC or C/Python and what not, perhaps it is not a good idea?
Maybe it can be done in common option parsing code for our clients, somewhere in mysys?

Comment by Sergei Golubchik [ 2020-04-03 ]

client plugins are part of C/C. Any client linked with C/C might implicitly use them without even knowing. Looks like it's C/C job to be able to find its plugins as needed

Comment by Vladislav Vaintroub [ 2020-04-03 ]

well, the bug is about being able to find plugin relative to current executable, because it is server's installer job to install our executables into bin and client plugins into lib/plugin. We can't do it right for any client, but for some we can.

Comment by Geoff Montee (Inactive) [ 2020-04-27 ]

This problem does not just affect Windows. It also affects binary tarball installations on Linux.

Comment by Sergei Golubchik [ 2021-01-09 ]

wlad,

  • what's the problem with arg[0] ?
  • environment variables were used before, I tried not to break the compatibility with existing scripts
  • ok, will use it in mysql client too
Comment by Vladislav Vaintroub [ 2021-01-09 ]

It works for me for Windows for the server, anytime so I do not see any reason to fix what is not broken. If you like to fix it on Linux, on server, it is just fine, yet outside of the scope for this bug. I do not think Windows needs any fixing.
If you can do something without extra bit of information which is arg[0], I would prefer to do it without extra bit of information, GetFullPathName always works correctly.

Comment by Sergei Golubchik [ 2022-01-07 ]

I've downloaded a ZIP archive of MariaDB 10.6.5 for Windows, unzipped it (on desktop), started the server, installed auth_ed25519 plugin. Created a user that is authenticated via this plugin.

After that no matter from where and how I invoked mysql.exe, I was always able to connect as long as the password was correct. Meaning mysql.exe was always able to find and load the client ed25519.dll plugin.

Generated at Thu Feb 08 07:33:47 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.