CentOS7 on Google Compute Engine

We have this one already, MDEV-4500. Please feel free to provide your input there.

Thank you Elena, I have commented there. That other submission I think was made generally for CONNECT, not specifically for the JDBC table type which has no apparent need for FILE permission.

Okay, I see. I'll re-open it and will keep it related to MDEV-4500 – maybe it will get fixed faster in the limited scope of JDBC than in the wide scope of the whole CONNECT world.

Is is yet possible to move forward on fixing this?
There is no obvious reason why CONNECT JDBC needs FILE priv.

I agree with you. This is the same for many other table types, for instance ODBC.

The issue is that it is handled by the function ha_connect::check_privileges that was written by Alexander Barkov when he was working with me.

It's not a trivial function and I'd prefer that he was the one to fix this.

What is the process to get him to take a look at this?

The reason why we added the requirement for the FILE privilege for ODBC tables was that when accessing such tables, ConnectSE loads local files, e.g. odbc.ini.

I agree that FILE privilege might be too strict for ODBC and JDBC, MYSQL, MONGO, MAC, WMI.
Loading system files through APIs could be less strict than generally loading an arbitrary file in the system (which the FILE privilege was originally designed to).

I can see three options from a glance:

1. Add a new MariaDB privilege, say "API", to control access to system files through APIs (like odbc.ini in case of ODBC).

2. Add new CONNECT system variables to choose if the FILE privilege is required for certain table types, e.g.
--connect-file-priv-odbc=0|1
--connect-file-priv-jdbc=0|1
--connect-file-priv-mysql=0|1
--connect-file-priv-mongo=0|1
--connect-file-priv-mac=0|1
--connect-file-priv-wmi=0|1

3. Just allow to use these mentioned table types without the FILE privilege.

Robert, which do you think looks most reasonable? Do you have more ideas?

If I understand correctly (please confirm or correct) the different CONNECT types internally read system files. If for example, ODBC.ini is read and contains passwords, this should be OK so long as the database user can't directly access those passwords or read the file directly. On the surface, this is no different than Innodb reading its file tables, which does not require FILE priv.

I do think there needs to be very clear documentation, broken out by CONNECT type, that specifies which system files are read and/or written to. If they are just READ and never written, and if the info in them is not exposed by CONNECT directly, on the surface I can't see a problem.

If my understanding is correct, then I think option 3 is the best (do not require FILE priv for ODBC and JDBC, MYSQL, MONGO, MAC, WMI).

In addition, what about having an option to disable specific CONNECT types completely (a non-dynamic setting, so requires reboot to change). All existing CONNECT types can be enabled by default (for compatibility), and all future CONNECT types can be DISABLED by default so an upgrade doesn't cause unforeseen security issues by accident. Something like this:

--connect-odbc-enable=0|1 default 1
--connect-jdbc-enable=0|1 default 1
...
--connect-futuretype-enable=0|1 default 0

For example, our specific config would then enable only jdbc and disable everything else to prevent unforeseen security issues.

Alexander, your thoughts?

For your information:
ODBC loads odbc.ini on Linux. On Windows it uses the sytem defined Data Sources, which is not properly a file.
JDBC is using the JavaWrappers.jar file.
None of them are modifying any file.
All other types are not using external files.

Therefore, I think the better and easier solution is to permit using these table types without requiring the file privilege.

About enabling or disabling some table types, I had suggested this for the new MONGO table type (so the CONNECT engine could be rated GA) but this was refused by MariaDB.

Thank you for that clarification Olivier. I totally agree with you "the better and easier solution is to permit using these table types without requiring the file privilege"

No file privilege was not granted for the MYSQL and OEM table types because this would allow executing a table that need the privilege checking. And also not for the DIR, ZIP table types that are using files, even not modifying them.

I vaguely remember that one can read text and csv files via ODBC, using "Text Driver". Is that correct?
This was the reason for requiring FILE privilege for ODBC.

I think that is possible, but the person configuring the environment and install the drivers would be "responsible" for installing or not installing such a driver in this case. I don't think its a direct security concern of CONNECT, but could be a vulnerability if someone installed such a driver as the driver can run arbitrary code. Possibly worth documenting in a "Security Considerations" section.

Text Driver is a 32 bit Windows only driver incompatible with 64 bit applications. All servers on Linux are not concerned, only Windows 32 bit ones (unless accessed via the ODBC-ODBC Easysoft driver).
Eventually, file privilege could be restored for Windows servers for ODBC. What do you think?

better to not require it in my opinion.

I'm not seeing this as fixed in the 10.2.14 change log:

https://mariadb.com/kb/en/library/mariadb-10214-changelog/