allow SESSION_READ_ONLY open a DBI book without write privileges

[John Ralls]

> On Jul 9, 2026, at 14:34, array_hourly_0u at icloud.com wrote:
> 
> 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.

Your premise that the database was necessarily written by a GnuCash session is false. Anybody with db write access (and for a SQLite3 database that means anyone with write access to the filesystem) can write (or delete) whatever they want into the database. There is at least one public Python library that reads and writes GnuCash SQLite3 files (https://github.com/sdementen/piecash). The databases have no integrity checks enabled: Any integrity checking (and it’s pretty minimal) is in GnuCash’s engine.

The ffastmath problem underlying bug 611936 was on the write side of libdii so a read-only test wouldn’t find the problem. I think it unlikely that anyone is using that version of gcc anymore so it’s probably safe to remove the test.

That said, I have my doubts about the value of having users without database write access. Access control hasn’t ever been a consideration in GnuCash’s design and trying to bolt it on 30 years later isn’t likely to produce a satisfactory result.

Regards,
John Ralls