In short:
Windows Server with Terminal Service is running Firebird 4 (4.0.7 and 4.0.6) and our Middleware. Terminal clients run client software that connect to the middleware via named pipes. Middleware threads use Windows Impersonate API to assume calling client identity and try to open XNET connection to Firebird 4 server. This causes stack overflow error. TCPIP connection to FB4 opens normally. Straight XNET connection from the same user to FB4 also opens normally. It only crashes after impersonation.
AI after an investigation gave the following report:
====
Alexander Liberov
Jul 6, 2026, 5:23:32 PM (8 days ago)
to firebird-support
FB4 XNET/local attach stack-overflows in fbclient (gds__log recursion) when the calling thread impersonates another user's token
Hello,
We have hit what looks like an fbclient.dll defect on the XNET (local, Protocol=Local)
transport and would appreciate confirmation before we file a tracker issue.
Setup: a Windows service running as LocalSystem authenticates a client over a named
pipe, calls ImpersonateNamedPipeClient() to wear that client's token, and then opens a
Firebird 4 database over XNET with Win_Sspi trusted auth. The attach
(isc_attach_database / FireDAC TFDConnection.Connected := True) throws a Windows stack
overflow (exception C00000FD).
A full minidump shows the overflow is an infinite recursion ENTIRELY inside fbclient.dll,
cycling through gds__log (~5,400 frames). The same attach over TCPIP-to-localhost works
fine, and plain XNET (no impersonation) works fine. It fails only when the thread's
impersonation token differs from the process primary token:
TCPIP, any identity ....................................... OK
XNET, no impersonation, any identity (incl. SYSTEM) ....... OK
XNET, impersonating the SAME user (primary == impersonated) OK
XNET, LocalSystem impersonating a DIFFERENT user's token .. STACK OVERFLOW
Reproduced on Firebird 4.0.6.3221 and 4.0.7.3271 (x64, Super), fbclient matched to the
server and pinned by absolute path. WireCrypt Required vs Disabled, Providers=Remote,
and thread stacks up to 64 MB make no difference. IpcName=Global\FIREBIRD does not help
(the privilege check that fails runs before the object name is composed). Reverting
impersonation around the attach connects but as the machine account, which defeats
trusted auth.
Likely mechanism (from the v5 source, please correct): the XNET client attach calls
isGlobalKernelPrefix() -> OpenProcessToken/PrivilegeCheck(SeCreateGlobalPrivilege);
under the stripped impersonation token these fail, the failure path calls gds__log,
and gds__log's own path (resolving the log file) fails under the same token and
re-enters logging -> unbounded recursion -> C00000FD.
===
I used the latest FB4 build. I don't have FB5 yet.
Delphi small example package is attached. See Readme.
report-package.zip
In short:
Windows Server with Terminal Service is running Firebird 4 (4.0.7 and 4.0.6) and our Middleware. Terminal clients run client software that connect to the middleware via named pipes. Middleware threads use Windows Impersonate API to assume calling client identity and try to open XNET connection to Firebird 4 server. This causes stack overflow error. TCPIP connection to FB4 opens normally. Straight XNET connection from the same user to FB4 also opens normally. It only crashes after impersonation.
AI after an investigation gave the following report:
====
Alexander Liberov
Jul 6, 2026, 5:23:32 PM (8 days ago)
to firebird-support
FB4 XNET/local attach stack-overflows in fbclient (gds__log recursion) when the calling thread impersonates another user's token
Hello,
We have hit what looks like an fbclient.dll defect on the XNET (local, Protocol=Local)
transport and would appreciate confirmation before we file a tracker issue.
Setup: a Windows service running as LocalSystem authenticates a client over a named
pipe, calls ImpersonateNamedPipeClient() to wear that client's token, and then opens a
Firebird 4 database over XNET with Win_Sspi trusted auth. The attach
(isc_attach_database / FireDAC TFDConnection.Connected := True) throws a Windows stack
overflow (exception C00000FD).
A full minidump shows the overflow is an infinite recursion ENTIRELY inside fbclient.dll,
cycling through gds__log (~5,400 frames). The same attach over TCPIP-to-localhost works
fine, and plain XNET (no impersonation) works fine. It fails only when the thread's
impersonation token differs from the process primary token:
TCPIP, any identity ....................................... OK
XNET, no impersonation, any identity (incl. SYSTEM) ....... OK
XNET, impersonating the SAME user (primary == impersonated) OK
XNET, LocalSystem impersonating a DIFFERENT user's token .. STACK OVERFLOW
Reproduced on Firebird 4.0.6.3221 and 4.0.7.3271 (x64, Super), fbclient matched to the
server and pinned by absolute path. WireCrypt Required vs Disabled, Providers=Remote,
and thread stacks up to 64 MB make no difference. IpcName=Global\FIREBIRD does not help
(the privilege check that fails runs before the object name is composed). Reverting
impersonation around the attach connects but as the machine account, which defeats
trusted auth.
Likely mechanism (from the v5 source, please correct): the XNET client attach calls
isGlobalKernelPrefix() -> OpenProcessToken/PrivilegeCheck(SeCreateGlobalPrivilege);
under the stripped impersonation token these fail, the failure path calls gds__log,
and gds__log's own path (resolving the log file) fails under the same token and
re-enters logging -> unbounded recursion -> C00000FD.
===
I used the latest FB4 build. I don't have FB5 yet.
Delphi small example package is attached. See Readme.
report-package.zip