Repository navigation
Stock image cannot authenticate: security3.fdb lacks PLG$SRP tables for default Srp UserManager #47
Description
Summary
A stock container of firebirdsql/firebird:3.0.11 (no environment variables set) cannot authenticate any user over the network. The credentials advertised in /opt/firebird/SYSDBA.password do not work, and every login attempt fails with:
Install incomplete, please read the Compatibility chapter in the release notes for this version
Steps to reproduce
podman run -d --name fb3 docker.io/firebirdsql/firebird:3.0.11
PW=$(podman exec fb3 awk -F= '/^ISC_PASSWORD/{print $2}' /opt/firebird/SYSDBA.password)
podman exec fb3 /opt/firebird/bin/gsec -user sysdba -password "$PW" -diResult:
use gsec -? to get help
Install incomplete, please read the Compatibility chapter in the release notes for this version
unable to open database
The same error is returned for any network login with these credentials (e.g. isql -user SYSDBA -password "$PW" localhost:<db>), regardless of the target database.
Cause
The security3.fdb baked into the image contains only the legacy plugin structures:
PLG$USERS
PLG$VIEW_USERS
There is no PLG$SRP table. However, the server's default configuration uses UserManager = Srp, and the Srp user manager reads PLG$SRP. When that table is missing, the underlying "table unknown" (isc_dsql_relation_err) error is converted by checkStatusVectorForMissingTable() in src/auth/SecureRemotePassword/srp.cpp to isc_missing_data_structures — the "Install incomplete" message — which points nowhere near the actual problem.
Additionally, the PLG$PASSWD value stored for SYSDBA in PLG$USERS is an SRP-format verifier (44-char base64), which no default-configured plugin can verify: Srp reads PLG$SRP, and Legacy_UserManager is not in the default UserManager list.
Workaround
Setting FIREBIRD_ROOT_PASSWORD works around the problem: the entrypoint runs CREATE OR ALTER USER SYSDBA PASSWORD '...' USING PLUGIN Srp, which triggers prepareDataStructures() in the Srp user manager and creates the missing PLG$SRP table. This is presumably why the defect usually goes unnoticed.
Suggested fix
Initialize the SRP data structures during image build (e.g. run the password-set with USING PLUGIN Srp), so that a stock container authenticates with the credentials in SYSDBA.password under the default configuration.
Additional note
The SYSDBA password in SYSDBA.password is a build-time constant: it is identical for every container created from this image tag. Since the stock image cannot authenticate with it anyway this is currently moot, but if the initialization is fixed, generating the password at first container start (or documenting the fixed credential) would be worth considering.
Verified with firebirdsql/firebird:3.0.11 on podman 5.x, Linux x64.
Activity
fdcastel commentedon Sep 23, 2026
Thanks for the detailed report, @rredpoppy! Confirmed on every published Firebird 3 image (all tags and distros). Firebird 4 and 5 images are not affected.
What was wrong
The missing
PLG$SRPtable was a symptom, not the root cause. The real problem was the order of steps in our Dockerfile:gsec -add sysdba -pw <password>, and then writes that password to/opt/firebird/SYSDBA.password.gsecneedslibtommath.so.0andlibncurses.so.5. Our Dockerfile only provided these libraries in steps that ran afterinstall.sh.gsecfailed witherror while loading shared libraries: libtommath.so.0. The installer ignores that error, and it still wrote the (never applied) password toSYSDBA.password.The image therefore shipped the untouched
security3.fdbfrom the Firebird tarball: no Srp user and noPLG$SRPtable. Every Srp login then failed with the misleadingInstall incompletemessage. (ThePLG$USERSrow you found also comes from that pre-built database.)As you noticed,
FIREBIRD_ROOT_PASSWORDhides the problem.FIREBIRD_USERdoes too, because both create users through the Srp plugin when the container starts. All of our documented examples and tests use one of them, which is why this went unnoticed.The fix
PR #49 moves the Firebird 3 library setup before
install.sh, so the installer's owngseccall works andSYSDBA.passwordmatches the real SYSDBA password. It also adds tests that start a container with no environment variables and log in over the network with the credentials fromSYSDBA.password. Those tests fail on the currently published images and pass with the fix.Please test
I've published unofficial images with the fix to GitHub Container Registry (Debian Trixie, amd64). Your exact reproduction steps should now work:
Tags
3.0.9to3.0.14(and3) are available. Could you give it a try and let us know how it goes?About your additional note
Good point about the SYSDBA password being a build-time constant. It already applies to the Firebird 4 and 5 images, and it will apply to Firebird 3 once this fix is released. I've opened #48 to track it separately.
fdcastel commentedon Sep 26, 2026
@rredpoppy a new unofficial image is available with this fix, now combined with two other pending changes. Could you please test it and report back?
Unofficial test image
ghcr.io/fdcastel/firebird:3.0.14(also tagged3), Debian Trixie, amd64. It is for testing only and contains:FIREBIRD_ROOT_PASSWORDis not set, each container now generates its own random SYSDBA password on first start, instead of using the one baked into the image. It is stored in/opt/firebird/SYSDBA.passwordin the same format as before, so your steps still work unchanged.The
3.0.11tag published earlier still has only the fix for this issue. The new combined image is published for the latest release of each major version only.Examples
Your original reproduction, which should now succeed:
Network login with the same credentials:
Each new container gets a different password; restarting the same container keeps it:
Please let us know whether it works for you, including with podman.