Enhancement request: Add "entrypoint" as an option to sqlite3.load_extension()

[asg017]

Enhancement Request:

The current version of sqlite3.Connection.load_extension() takes in a single parameter path. However, the underlying C API sqlite3_load_extension has an additional entrypoint argument that I think should be added to the Python load_extension function.

Currently in connection.c, the entrypoint parameter is ignored with a null pointer:

cpython/Modules/_sqlite/connection.c

Line 1624 in f2e5a6e

rc = sqlite3_load_extension(self->db, extension_name, 0, &errmsg);

Pitch

We add a new second optional entrypoint parameter to the load_extension() Python function. If it is provided, it's passed along to the underlying sqlite3_load_extension C function as the extension entrypoint.

import sqlite3
db = sqlite3.connect(":memory:")
db.enable_load_extension(True)

# Currently, only a single path argument is supported on load_extension()
db.load_extension("./lines0")

# In this proposal, an optional 2nd entrypoint parameter would be added
db.load_extension("./lines0", "sqlite3_lines_no_read_init")

db.enable_load_extension(False)

I've been building several SQLite extensions, some of which use different entrypoints to enable/disable security sensitive features. For example, in sqlite-lines (A SQLite extension for reading files line-by-lines), there will be a secondary entrypoint called sqlite3_lines_no_read_init that disables all functions that read the filesystem, for use in Datasette or other security-sensitive environments.

Many of these extensions are also distributed as Python packages, so any extra customizable APIs for loading SQLite extensions is greatly appreciated!

Workaround

There technically is a workaround for this: A user can use the load_extension() SQL function to load an extension with an entrypoint, like so:

db = sqlite3.connect(":memory:")
db.enable_load_extension(True)
db.execute("select load_extension(?, ?)", ["path/to/extension", "entrypoint"])

However, doing so will circumvent the sqlite3.load_extension auditing event, as that's only trigged on calls to the python Connection.load_extension() function.

There's also some limitations to the pure SQL load_extension() function, mentioned here:

The load_extension() function will fail if the extension attempts to modify or delete an SQL function or collating sequence. The extension can add new functions or collating sequences, but cannot modify or delete existing functions or collating sequences because those functions and/or collating sequences might be used elsewhere in the currently running SQL statement. To load an extension that changes or deletes functions or collating sequences, use the sqlite3_load_extension() C-language API.
Source: https://www.sqlite.org/lang_corefunc.html#load_extension

Also in general, it's recommended to avould the SQL load_extension() function altogether:

Security warning: It is recommended that extension loading be enabled using the SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION method rather than this interface, so the load_extension() SQL function remains disabled. This will prevent SQL injections from giving attackers access to extension loading capabilities.
Source: https://www.sqlite.org/c3ref/enable_load_extension.html

It's also just a little awkward, having to "eject" to SQL to do something that the Python API could readily support.

Linked PRs

• gh-103015: Add entrypoint parameter to sqlite3.Connection.load_extension #103073

[erlend-aasland]

This sounds like a reasonable feature request to me. Adding entrypoint as a keyword only argument would be ok to me. If you have the time and resources, please create a PR. If not, I'll try to get it done before the feature freeze in May.

[erlend-aasland]

Thanks for the nice suggestion, @asg017!