allow SESSION_READ_ONLY open a DBI book without write privileges

array_hourly_0u at icloud.com array_hourly_0u at icloud.com
Thu Jul 9 17:34:54 EDT 2026


Hello again,

  Obviously backend stuff is on my mind lately and there's been a
quirk impacting read-only access to SQL back-ed books that has
bothered me for a while.

Opening a book with SESSION_READ_ONLY through the SQL/DBI backend
still requires the database user to have permission to create a
temporary table. On every session_begin (regardless of mode),
dbi_library_test() runs the 64-bit round-trip guard from Bug #611936
-- CREATE TEMPORARY TABLE / INSERT / SELECT / DROP -- to detect a
15-year-old -ffast-math libdbi miscompilation. A least-privileged,
SELECT-only database user therefore cannot open the book at all: the
create fails and begin returns ERR_SQL_DBI_UNTESTABLE.
(SESSION_READ_ONLY already skips the gnclock lock, so this probe is
the only remaining reason a read-only open needs write-ish rights.)

I'd like to propose making a read-only open work without those
privileges. Two possible directions:

1. Skip dbi_library_test() when the session is opened SESSION_READ_ONLY.

2. Or, for read-only, replace it with a check that needs no write
privileges -- for example, verify the driver retrieves large
int64/uint64 and a high-precision FLOAT8 via a SELECT of
literals/casts (dbi_result_get_longlong / get_ulonglong / get_double),
so the reader's conversion path is still validated. I'd welcome
suggestions on the best minimal form.

The justification for either approach: the data already in the
database was written by a GnuCash session, and dbi_library_test() ran
for that session, so any book that was successfully saved was
necessarily saved by a driver that passed the round-trip test -- the
stored 64-bit and FLOAT8 values are therefore correct at rest. A
read-only session never writes back, so the only thing left to guard
against is a reader-side retrieval defect. For a modern 64-bit libdbi
that is the 2011, 32-bit / -ffast-math case from #611936, which is
essentially historical (or maybe never existed on the read)

If there is a preferred direction, I'm happy to prepare a PR.

Cheers,

Noah


More information about the gnucash-devel mailing list