Hi Jim

Jim Starkey wrote:

>
>>
> Then let's go back and talk about what I proposed.
>
> In my scheme, whoever needs a configuration file looks for one by a
> fixed set of rules. For purposes of discussion, let's say the order is:
>
> 1. An environmental variable, say FB_CONFIG.
> 2. .firebird.conf in his login directory
> 3. Something appropriate HKEY_CURRENT_USER/Software/Firebird tree.
> 4. <hostname>.conf in the Firebird install directory
> 5. firebird.conf in the Firebird install directory
>

Jim, before commenting on this, Im not entirely clear on some of your
firebird configurations.

As I see it from what you've outlined previously, ignoring wire
protocols, you are looking at three access modes:

1. embeded access
- generally the db file is owned by the user
- server and client run in the same process.
- and that process runs as the user.
(embeded only available in classic)

2. remote server access
- the server and client are on seperate machines.
- the db file is owned by a remote system user.
- server and client run as seperate processes.
- the client runs as the user,
- the server runs as the server uid (firebird/root).
(available in both classic and super)

3. local server access
- As per 2, but here the server and client run on the
same machine (and the access is not embeded).
- the server and client run as seperate processes
- the client runs as the user
- the server runs as ?
- the db file is owned by ?
(available in both classic and super)

Previously with suid, super vs classic, embeded mode, and servers
running as root, the "local server access" did a variety of things, some
good some bad.

I was thinking we remove it altogether and just leave the client with
the choice (though a Y value) of either direct 'embeded' access or
secure 'server' access. But you seem to have some other ideas for
'local server access', do you mind explaining what your thinking is?


Cheers

Mark