RemoteAccess parameter

[Alex Peshkoff]

This is tightly related with https://github.com/FirebirdSQL/firebird/issues/9056 - but I wanted it to be discussed more widely before backporting. 

Fix for #9056 is trivial and committed to master branch (7706c999cfd). But problem of security.db backup on SS with default config remains - to do it one need to stop server or temporarily modify databases.conf. Not good.

What if we add new configuration parameter with directory name which may be used to place backups of not accessible remotely databases? Such backup may be started only as service (in that case we may trust backup code) and if .fbk  goes to such directory engine will ignore RemoteAccess=false when attaching database to be backuped. With correct access rights to such directory (full access for firebird server, no access to others) this appears to be safe approach.

[Basil A. Sidorov]

28.06.2026 00:31, 'Alex Peshkoff' via firebird-devel пишет:

> Fix for #9056 is trivial and committed to master branch (7706c999cfd).
> But problem of security.db backup on SS with default config remains - to
> do it one need to stop server or temporarily modify databases.conf. Not
> good.

Not problem at all on windows: gbak -b xnet://security.db
On POSIX, some time ago exist hack (clean file copy, not worked now).
On all system should work dirty file copy, gfix -mend && gbak -b
--
Basil A. Sidorov <ba...@irk.ru>

[Mark Rotteveel]

I have rarely (if ever) heard complaints about that on the lists, so I'm
not sure if that is really that big a problem. Additionally, wouldn't
this be a solved problem once Unix domain socket support lands (assuming
concurrent use of TCP/IP and Unix domain sockets is supported, which it
wasn't the last time I checked)?

Mark
--
Mark Rotteveel

[Vlad Khorsun]

27.06.2026 19:31, 'Alex Peshkoff' via firebird-devel:

> This is tightly related with https://github.com/FirebirdSQL/firebird/issues/9056 - but I wanted it to be discussed more widely
> before backporting.
>
> Fix for #9056 is trivial and committed to master branch (7706c999cfd).

I'm not sure the fix is correct. First, it disables access using XNET whish is definitely **not**
a remote access.

Second, it is wrong way to detect **remote** access by presence of dpb_auth_block, imho.
I see no guarantee that empty dpb_auth_block means embedded access. In any case it is not related things.

Next, I'm pretty sure we must allow any kind of **direct** access from local host - i.e. using
any network protocol. By **direct** access I mean explicit connect from user application, i.e.
without intermediary as ES.

Before this change xnet://security.db was allowed and now it is not.
inet://security.db was not allowed and I consider it as a wrong thing.

The setting RemoteAccess was introduced to control access to the database from non-local hosts.
And its implementation always was a bit not correct, now it is even more wrong.

> But problem of security.db backup on SS with default config
> remains - to do it one need to stop server or temporarily modify databases.conf. Not good.

This is just consequence of said above.

> What if we add new configuration parameter with directory name which may be used to place backups of not accessible remotely
> databases? Such backup may be started only as service (in that case we may trust backup code) and if .fbk  goes to such directory
> engine will ignore RemoteAccess=false when attaching database to be backuped. With correct access rights to such directory (full
> access for firebird server, no access to others) this appears to be safe approach.

Looks ugly and wrong for me, sorry

Regards,
Vlad

[Dimitry Sibiryakov]

Vlad Khorsun wrote 28.06.2026 15:28:
>> Fix for #9056 is trivial and committed to master branch (7706c999cfd).
>
>   I'm not sure the fix is correct. First, it disables access using XNET whish
> is definitely **not**
> a remote access.

Consider Windows Terminal Server and two session, one from privileged user
that has file access to security.db and another from non-privileged user having
no such access. Is it really right to allow a non-privileged user to read
security DB?..

--
WBR, SD.

[Basil A. Sidorov]

28.06.2026 21:32, 'Dimitry Sibiryakov' via firebird-devel пишет:

>   Consider Windows Terminal Server and two session

Local security policy are out of scope of database security.

[Dimitry Sibiryakov]

Basil A. Sidorov wrote 28.06.2026 15:37:
> 28.06.2026 21:32, 'Dimitry Sibiryakov' via firebird-devel пишет:
>>    Consider Windows Terminal Server and two session
> Local security policy are out of scope of database security.

Exactly, that's why the whole point of RemoteAccess is to let connection only
by users who do have a file access to the database.

--
WBR, SD.

[Vlad Khorsun]

28.06.2026 16:32, 'Dimitry Sibiryakov' via firebird-devel:

How it is known that user is non-privileged ? What privileges you a reffers here ?
How Terminal Server affects this question at all ?

Vlad

[Dimitry Sibiryakov]

Vlad Khorsun wrote 28.06.2026 15:40:
>   How it is known that user is non-privileged ? What privileges you a reffers
> here ?

File system privileges.

> How Terminal Server affects this question at all ?

Terminal Server allows different remote users to share the same host.

But ok, forget Terminal Server and limit your mind to local sessions. Must an
user without file access to security database to be able to read it if they have
a Firebird account powerful enough?

--
WBR, SD.

[Vlad Khorsun]

28.06.2026 16:48, 'Dimitry Sibiryakov' via firebird-devel:

> Vlad Khorsun wrote 28.06.2026 15:40:
>>    How it is known that user is non-privileged ? What privileges you a reffers here ?
>
>   File system privileges.

Why file system privileges makes SQL user more or less privileged ? It is nonsence.

>> How Terminal Server affects this question at all ?
>
>   Terminal Server allows different remote users to share the same host.
>
>   But ok, forget Terminal Server and limit your mind to local sessions. Must an user without file access to security database to be
> able to read it if they have a Firebird account powerful enough?

Sure. Why SYSDBA should have special file-system permissions ?
I don't speak about embedded access here.

Vlad

[Basil A. Sidorov]

28.06.2026 21:39, 'Dimitry Sibiryakov' via firebird-devel пишет:

>   Exactly, that's why the whole point of RemoteAccess is to let
> connection only by users who do have a file access to the database.

Where is documented this strange statement???
And, if this true, on which Windows system you see "very strict" and
"very right" setup of filesystem access???

[Basil A. Sidorov]

28.06.2026 21:48, 'Dimitry Sibiryakov' via firebird-devel пишет:

> Must an user without file access to security database to be able to read
> it if they have a Firebird account powerful enough?

If such user know sysdba password - "Yes, it is!"

[Mark Rotteveel]

No it is not. XNET has always worked with this feature.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

Basil A. Sidorov wrote 28.06.2026 15:56:
> And, if this true, on which Windows system you see "very strict" and "very
> right" setup of filesystem access???

On every system that is administrated by an admin who does care about security.
Fine-grained File ACLs are very old thing. Running of Firebird server under a
restricted account is also very common recommendation, as well as restricting
everyone else from accessing Firebird files.

--
WBR, SD.

[Alex Peshkoff]

On 6/28/26 16:28, Vlad Khorsun wrote:
> 27.06.2026 19:31, 'Alex Peshkoff' via firebird-devel:
>> This is tightly related with
>> https://github.com/FirebirdSQL/firebird/issues/9056 - but I wanted it
>> to be discussed more widely before backporting.
>>
>> Fix for #9056 is trivial and committed to master branch (7706c999cfd).
>
>   I'm not sure the fix is correct. First, it disables access using
> XNET whish is definitely **not**
> a remote access.
>

Probably that's my fault. When I've understood that access using XNET
works for files with RemoteAccess = false I've decided that many years
ago when implementing RemoteAccess parameter I've checked it (as almost
always) only for TCP. And decided to fix - in one shot with ESOE bug.

BTW, can you attach to security database using xnet in fb 2.5? Using TCP
I can not.

> Second, it is wrong way to detect **remote** access by presence of
> dpb_auth_block, imho.
> I see no guarantee that empty dpb_auth_block means embedded access. In
> any case it is not related things.

Here I do not agree with you. To be precise - not empty but missing.
Yes, someone can add dpb_auth_block when performing embedded access -
but IMHO that's not our problem :) On the other hand any remote
(connected using remote server) attachment always has dpb_auth_block.
Without creation of it by server one can not attach. I.e. it's tightly

related things.

>
>   Next, I'm pretty sure we must allow any kind of **direct** access
> from local host - i.e. using
> any network protocol. By **direct** access I mean explicit connect
> from user application, i.e.
> without intermediary as ES.
>
>   Before this change xnet://security.db was allowed and now it is not.
> inet://security.db was not allowed and I consider it as a wrong thing.
>
>   The setting RemoteAccess was introduced to control access to the
> database from non-local hosts.
> And its implementation always was a bit not correct, now it is even
> more wrong.

OK, we can enable local connection by using any protocol. But do we have
reliable way to distinguish it from ESOE one? Check PID in DPB? Will not
work for classic.

[Basil A. Sidorov]

29.06.2026 01:22, 'Alex Peshkoff' via firebird-devel пишет:

> BTW, can you attach to security database using xnet in fb 2.5?

In fb 2.5 only server/gsec can work with security.db and now way use
URL-based connection string.

But:
> "5.0.04c/fbsvcmgr" xnet://service_mgr user sysdba password masterke
info_server_version -z
Firebird Services Manager version WI-V5.0.4.1812 Firebird 5.0
Server version: WI-V2.5.9.27139 Firebird 2.5

[Vlad Khorsun]

28.06.2026 20:22, 'Alex Peshkoff' via firebird-devel:

> On 6/28/26 16:28, Vlad Khorsun wrote:
>> 27.06.2026 19:31, 'Alex Peshkoff' via firebird-devel:
>>> This is tightly related with https://github.com/FirebirdSQL/firebird/issues/9056 - but I wanted it to be discussed more widely
>>> before backporting.
>>>
>>> Fix for #9056 is trivial and committed to master branch (7706c999cfd).
>>
>>   I'm not sure the fix is correct. First, it disables access using XNET whish is definitely **not**
>> a remote access.
>>
>
> Probably that's my fault. When I've understood that access using XNET works for files with RemoteAccess = false I've decided that
> many years ago when implementing RemoteAccess parameter I've checked it (as almost always) only for TCP. And decided to fix - in one
> shot with ESOE bug.
>
> BTW, can you attach to security database using xnet in fb 2.5? Using TCP I can not.

No. But it change nothing.

>> Second, it is wrong way to detect **remote** access by presence of dpb_auth_block, imho.
>> I see no guarantee that empty dpb_auth_block means embedded access. In any case it is not related things.
>
> Here I do not agree with you. To be precise - not empty but missing. Yes, someone can add dpb_auth_block when performing embedded
> access - but IMHO that's not our problem :)

So, should we document that embedded connection **must** not perform any kind of user auth ?
Could you guarantee this will not be changed by us in the future - for some new functionality ?
Sorry, it doesn't sounds right to me.

> On the other hand any remote (connected using remote server) attachment always has
> dpb_auth_block. Without creation of it by server one can not attach. I.e. it's tightly related things.

What about nested ES calls ? Something like:

App
connect inet://server/user_database
call ES on 'user_database' -- embedded
call ES on 'security.db' -- embedded

>>   Next, I'm pretty sure we must allow any kind of **direct** access from local host - i.e. using
>> any network protocol. By **direct** access I mean explicit connect from user application, i.e.
>> without intermediary as ES.
>>
>>   Before this change xnet://security.db was allowed and now it is not.
>> inet://security.db was not allowed and I consider it as a wrong thing.
>>
>>   The setting RemoteAccess was introduced to control access to the database from non-local hosts.
>> And its implementation always was a bit not correct, now it is even more wrong.
>
> OK, we can enable local connection by using any protocol. But do we have reliable way to distinguish it from ESOE one? Check PID in
> DPB? Will not work for classic.

ES could pass in DPB anything required for our goal - such as properties (host, username, etc)
of original user connection.

Regards,
Vlad

[Basil A. Sidorov]

29.06.2026 01:53, Basil A. Sidorov пишет:

> 29.06.2026 01:22, 'Alex Peshkoff' via firebird-devel пишет:
>> BTW, can you attach to security database using xnet in fb 2.5?
>
> In fb 2.5 only server/gsec can work with security.db and now way use
> URL-based connection string.

"no way", of course. But:
SQL> connect 'xnet://security.db' user sysdba password 'masterke';
Statement failed, SQLSTATE = 28000
no permission for direct access to security database security.db
SQL> create database 'xnet://test' user sysdba password 'masterke';

Server version:
WI-V2.5.9.27139 Firebird 2.5

WI-V2.5.9.27139 Firebird 2.5/XNet (BASID)/P12
WI-V5.0.4.1812 Firebird 5.0/XNet (BASID)/P12

[Mark Rotteveel]

On 28-06-2026 15:28, Vlad Khorsun wrote:
>   Next, I'm pretty sure we must allow any kind of **direct** access
> from local host - i.e. using
> any network protocol. By **direct** access I mean explicit connect from
> user application, i.e.
> without intermediary as ES.

Although it is annoying, I think that disallowing any kind of TCP/IP
connection is a good thing for this feature. Even connections that
appear to be from localhost might not actually be localhost. As far as I
know, connections made through, for example, an SSH tunnel may appear to
be from localhost, but in practice they might not be.

(And no, people who can make an SSH tunnel to a certain port will not
necessarily have permissions to start a shell or other program to make a
truly local connection.)

Mark
--
Mark Rotteveel

[Mark Rotteveel]

On 28-06-2026 20:05, Vlad Khorsun wrote:
>   ES could pass in DPB anything required for our goal - such as
> properties (host, username, etc)
> of original user connection.

For this case, it might be sufficient that ES connections created by a
remote connection receive a (single) DPB item that cause that connection
to be considered remote, irrespective of the protocol used.

So, connections without that DPB item are considered remote or local
based on their protocol (XNET is local, TCP/IP is remote), and
connections with that DPB item are *always* considered remote,
irrespective of their connection (so also XNET and embedded connections
through ES).

This is safe, because users cannot control these connection properties
of an ES connections (and if a user does add that DPB item to their own
connection, it will be considered remote always, even if it's a local
protocol.)

Mark
--
Mark Rotteveel

[Vlad Khorsun]

28.06.2026 21:20, 'Mark Rotteveel' via firebird-devel:

It is not DBMS responsibility to control all possible ways app can use to pretend to be "local".
If sysadmin allowed it, he should understand consequences.

Also, perhaps we need to better specify what is "remote access" for Firebird specific security usage.

Regards,
Vlad

[Basil A. Sidorov]

29.06.2026 05:17, Vlad Khorsun пишет:

>   It is not DBMS responsibility to control all possible ways app can
> use to pretend to be "local".

Right.

> If sysadmin allowed it, he should understand consequences.

Right twice :)

>   Also, perhaps we need to better specify what is "remote access" for
> Firebird specific security usage.

IP-based connection: inet://, inet4://, inet6://, host/port - remote.
L(ocal)P(rocess)C(ommunication): xnet://, local sockets - local.

Well, local sockets may be used for communication between containers,
jails and so on, but "if sysadmin allowed it ...".

[Mark Rotteveel]

On 28-06-2026 23:17, Vlad Khorsun wrote:
>   It is not DBMS responsibility to control all possible ways app can
> use to pretend to be "local".
> If sysadmin allowed it, he should understand consequences.

That doesn't mean that we should make holes were there don't need to be
any. A tunnelled connection is remote, even though it may look to
originate on localhost to Firebird, and I wouldn't be surprised if
administrators creating such a connection would automatically consider
them to not be allowed to connect to databases with RemoteAccess =
false. As such, the consequences are not as easy to evaluate and
understand *correctly* as you seem to think.

Again, that localhost connections are considered remote by RemoteAccess
is IMHO a good thing and shouldn't be changed, even if it can be
annoying at times.

If Unix domain socket support is made to be used concurrently with
TCP/IP (instead of the either/or solution it has now), there is also
IMHO no need for it any more, as Linux et al will then have a solution
comparable to XNET to be able to connect to database with RemoteAccess =
false.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

Basil A. Sidorov wrote 29.06.2026 4:44:
> IP-based connection: inet://, inet4://, inet6://, host/port - remote.
> L(ocal)P(rocess)C(ommunication): xnet://, local sockets - local.
>
> Well, local sockets may be used for communication between containers, jails and
> so on, but "if sysadmin allowed it ...".

What can admin to do to disallow it?

Setting "RemoteAccess = true" allows to relax security if the admin wish to,
but now there no way to tighten it.

--
WBR, SD.

[Basil A. Sidorov]

29.06.2026 15:08, 'Dimitry Sibiryakov' via firebird-devel пишет:

>> Well, local sockets may be used for communication between containers,
>> jails and so on, but "if sysadmin allowed it ...".
>   What can admin to do to disallow it?

Out of scope SQL/db-server security.
Admin can, f.e., not use containers at all.
Admin can, f.e., isolate firebird process in one containers and
aplication, working with it db's - in another container.
Out of scope.

[Vlad Khorsun]

29.06.2026 10:08, 'Dimitry Sibiryakov' via firebird-devel:

Run Firebird with no corresponding listener.
Perhaps we need to implement SQL permission to access database, if it not exists already.

Vlad

[Dimitry Sibiryakov]

Basil A. Sidorov wrote 29.06.2026 9:40:
> Out of scope SQL/db-server security.
> Admin can, f.e., not use containers at all.
> Admin can, f.e., isolate firebird process in one containers and aplication,
> working with it db's - in another container.
> Out of scope.

Effectively you suggest to disable usage of XNET for all databases. Already
possible with command-line options, but subj is intended for more fine-grained
access control.

--
WBR, SD.

[Alex Peshkoff]

If we are anyway going to make related changes here and there we can
make RemoteAccess parameter more flexible.

[Basil A. Sidorov]

29.06.2026 15:45, 'Dimitry Sibiryakov' via firebird-devel пишет:

>   Effectively you suggest to disable usage of XNET for all databases.

Don't attribute your speculation to me.
At first - xnet has no ability work "via containers".
But, as L(ocal)C(ommunication)P(rocess), xnet are very consistent and
effective way work with all databases regardless of RemoteAccess parameters.
So it was and so it should remain.

--
Basil A. Sidorov <ba...@irk.ru>

P.S.
Thank translate.ru for your kind phrases.

[Dimitry Sibiryakov]

Basil A. Sidorov wrote 29.06.2026 10:14:
> Admin can, f.e., isolate firebird process in one containers and aplication, working with it db's - in another container.

> Don't attribute your speculation to me.
> At first - xnet has no ability work "via containers".

So, suggesting to isolate Firebird in a container you suggested to prevent
XNET from working completely. If your message had other meaning, please, be a
little more precise.

I'm sure that current behavior is right. If someone need access to a
high-security database via XNET, they can set RemoteAccess to true.

--
WBR, SD.

[Alex Peshkoff]

On 6/28/26 21:05, Vlad Khorsun wrote:

>>> Second, it is wrong way to detect **remote** access by presence of
>>> dpb_auth_block, imho.
>>> I see no guarantee that empty dpb_auth_block means embedded access.
>>> In any case it is not related things.
>>
>> Here I do not agree with you. To be precise - not empty but missing.
>> Yes, someone can add dpb_auth_block when performing embedded access -
>> but IMHO that's not our problem :)
>
>   So, should we document that embedded connection **must** not perform
> any kind of user auth ?

Document what? Currently it just can not perform such authentication and
does not do it. That was documented in FB3 relnotes (no need to provide
password for embedded connection). Do not forget that as long as user
has OS access to target database any attempt to seriously limit SQL
access to them is pure security through obscurity.

> Could you guarantee this will not be changed by us in the future - for
> some new functionality ?
> Sorry, it doesn't sounds right to me.
>

From security POV embedded connection first of all means that all
access rights are based on OS user name (or one specified explicitly
when attaching). If we add some authentication to it (makes no sense
with known to me OSes but who knows what may change in the future) such
connection starts to play by server security rules. And should not be
treated as embedded when dealing with it.

Well, certainly we can't guess what may happen. But that's not a reason
to stop playing current real rules.

>> On the other hand any remote (connected using remote server)
>> attachment always has dpb_auth_block. Without creation of it by
>> server one can not attach. I.e. it's tightly related things.
>
>   What about nested ES calls ? Something like:
>
>   App
>     connect inet://server/user_database
>     call ES on 'user_database' -- embedded
>       call ES on 'security.db' -- embedded
>

No matter how long chain of embedded connections is in use - auth block
will be present at all levels.

>
>>>   Next, I'm pretty sure we must allow any kind of **direct** access
>>> from local host - i.e. using
>>> any network protocol. By **direct** access I mean explicit connect
>>> from user application, i.e.
>>> without intermediary as ES.
>>>
>>>   Before this change xnet://security.db was allowed and now it is not.
>>> inet://security.db was not allowed and I consider it as a wrong thing.
>>>
>>>   The setting RemoteAccess was introduced to control access to the
>>> database from non-local hosts.
>>> And its implementation always was a bit not correct, now it is even
>>> more wrong.
>>
>> OK, we can enable local connection by using any protocol. But do we
>> have reliable way to distinguish it from ESOE one? Check PID in DPB?
>> Will not work for classic.
>
>   ES could pass in DPB anything required for our goal - such as
> properties (host, username, etc)
> of original user connection.
>

Yes that should be enough to have smart logic when deciding is
connection local enough or not. I specially use this "local enough"
cause looks like devel list does not have common understanding where is
the boarder between local and remote.

[Dimitry Sibiryakov]

'Alex Peshkoff' via firebird-devel wrote 29.06.2026 10:38:
> looks like devel list does not have common understanding where is the boarder
> between local and remote.

Isn't remote anything going through "Remote" provider?.. ;-) This name must
have some meaning...

--
WBR, SD.

[Basil A. Sidorov]

29.06.2026 16:20, 'Dimitry Sibiryakov' via firebird-devel пишет:

>   So, suggesting to isolate Firebird in a container you suggested to
> prevent XNET from working completely. If your message had other meaning,
> please, be a little more precise.

I didn't offer anything.
I pointed out the features of local sockets and how they can be (not) used.
All you "tighten security" and so on - out of scope SQL/database server
security.

Repeat one more.

IP-based connection - remote connection.
LPC-based connection (xnet and, in future - local sockets) - local
connection and they should work with any database, regardless of
RemoteAccess parameter.

Point-path should disable ESOE for LPC/embedded target, if such ESOE
initiated from remote (IP-based) connection.
But, ESOE for LPC/embedded target, initiated from local (LPC-based or
embedded) connection should work regardless of RemoteAccess parameter of
target db.

[Mark Rotteveel]

On 29-06-2026 10:20, 'Dimitry Sibiryakov' via firebird-devel wrote:
> Basil A. Sidorov wrote 29.06.2026 10:14:
>> Admin can, f.e., isolate firebird process in one containers and
>> aplication, working with it db's - in another container.
>
> > Don't attribute your speculation to me.
>> At first - xnet has no ability work "via containers".
>
>   So, suggesting to isolate Firebird in a container you suggested to
> prevent XNET from working completely. If your message had other meaning,
> please, be a little more precise.

That in no way follows from what Basil said.

>   I'm sure that current behavior is right. If someone need access to a
> high-security database via XNET, they can set RemoteAccess to true.

No it isn't. XNET is not a remote connection, and the recent change
committed breaks the expected and established behaviour that (direct)
XNET connections can connect to database with RemoteAccess = false.

Mark
--
Mark Rotteveel

[Mark Rotteveel]

You're assigning meaning to two separately intended features that just
happen to share the name remote. If anything, it means that either or
both features were poorly named.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-devel wrote 29.06.2026 11:18:
>>
>>    Isn't remote anything going through "Remote" provider?.. ;-) This name must
>> have some meaning...
>
> You're assigning meaning to two separately intended features that just happen to
> share the name remote. If anything, it means that either or both features were
> poorly named.

What does make you think so?

Remote provider is for establishing remote connections (connections to remote
Firebird servers), thus its name.
RemoteAccess is setting for preventing access to a particular database via
remote connections, thus it name.

"Remote connection" is exactly what makes these features not separated.

--
WBR, SD.

[Mark Rotteveel]

On 29-06-2026 11:32, 'Dimitry Sibiryakov' via firebird-devel wrote:

That would sooner suggest that XNET should not be part of the remote
provider.

In other words, both use a different partitioning for the term remote
and thus should not be conflated just because they happen to use the
same term.

Mark
--
Mark Rotteveel

[Mark Rotteveel]

More specifically, for providers, it seems that the term remote means
"outside the current process", while for RemoteAccess it means "from
outside this host".

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-devel wrote 29.06.2026 12:33:
> That would sooner suggest that XNET should not be part of the remote provider.

Yes, separate Inet, Wnet, Xnet providers was a good idea at v3 times and
still is. It would allow to designate which of them are "remote" and which are
"local" with exact precision.
Unfortunately the redesign of a monolithic fbclient into a modular one was
done in hurry and never finished since then.

--
WBR, SD.