Tim,

I see that a few people here have already fallen into the
catalog trap. The design is... questionable to say the least...
and the question is:
When we create a database to point to an existing database
folder, do we have to guess the database name?

If the database is not named the same as the catalog file
in the folder, it will create a new catalog and we won't
see existing files. What's worth, is that I've been able to
corrupt a database this way easily, because it doesn't seem
to care that edbtbl file belongs to a different catalog -
there was no warning, I was able to append data to a edbtbl
file with different structure.

What if a database with same name already exists in
a different folder? How will it be handled by the same
session - it will result in two duplicate databases?

The solution (e.g. Nexus) is either not to have catalog
file, or have it with a standard name, not related to
the database name. E.g. you always call catalog file catalog.edb.
This way, when you open a folder, it already knows that there
are data in it. Database name is irrelevant here.


Michael

Michael,

<< I see that a few people here have already fallen into the catalog trap.
The design is... questionable to say the least... and the question is:

When we create a database to point to an existing database folder, do we
have to guess the database name? >>

You don't do the above.  If you want to use an existing database, then it
either has to have been created on your system within the confines of the
configuration file that you're using or you need access to the configuration
file that was used to create it.  There are relationships between uses,
roles, etc. that require that the configuration information and the
databases be kept in synch.

<< If the database is not named the same as the catalog file in the folder,
it will create a new catalog and we won't see existing files. What's worth,
is that I've been able to corrupt a database this way easily, because it
doesn't seem to care that edbtbl file belongs to a different catalog -
there was no warning, I was able to append data to a edbtbl file with
different structure. >>

You shouldn't be able to open a database that was created using a different
configuration file.  If you can, let me know how you did it.  The
configuration file and the database file are intertwined and both need each
other.

<< What if a database with same name already exists in a different folder?
How will it be handled by the same session - it will result in two duplicate
databases? >>

The database name is irrelevant and only used for naming purposes.  What
matters is the internal ID used by the configuration file that connects a
database to a specific catalog.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> You don't do the above.  If you want to use an existing database, then it
> either has to have been created on your system within the confines of the
> configuration file that you're using or you need access to the configuration
> file that was used to create it.  
This is going to be MAJOR PITA! I think you should reconsider this
design before it's too late.
If you need to protect the database, store the security info inside
the folder. In any case, it's all too easy to move folders around,
so there's no way to protect it really. You are just creating problems
for nothing...
My 2c and ho.

Even MS SQL actually allows to specify any database file name and
map it to any database name in the connection string:
Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;
Initial Catalog=mydatabase2;Data Source=\SQLEXPRESS;
Initial File Name=E:\temp\mydatabase.mdf

> There are relationships between uses,
> roles, etc. that require that the configuration information and the
> databases be kept in synch.
Then keep them in the database. What's a config file in case of
local access mode?

I think it's the same problem as with DatabaseName property.

> << If the database is not named the same as the catalog file in the folder,
> it will create a new catalog and we won't see existing files. What's worth,
> You shouldn't be able to open a database that was created using a different
> configuration file.  If you can, let me know how you did it.  The
> configuration file and the database file are intertwined and both need each
> other.
Create 2 sessions: Default & Remote.
In default session create database Test -> e:\temp\db
Create table T (i int, a varchar(100))
Add some rows of data.
Close it all.

In remote session create database Test2 -> e:\temp\db
Create table T (i int, a float)
No errors or warnings so far.
Open table and view data - see binaries groups for screenshot.
It's obviously corrupt. (not physically yet).
Execute statement
insert into "T" values (0, 1, 1)
This actually ruins it.

Btw, there's something strange with inserts. It seems like it
is expecting RowID column as first column, because the table is
only 2 columns.

Also, I did manage to create database with the same name and
folder under different sessions and now I'm unable to neither
open it nor drop it.

> << What if a database with same name already exists in a different folder?
> How will it be handled by the same session - it will result in two duplicate
> databases? >>
> The database name is irrelevant and only used for naming purposes.  What
> matters is the internal ID used by the configuration file that connects a
> database to a specific catalog.
It seems, that the catalog file must have the same name as the database,
isn't it? I'd rather name it catalog.edb and kill all these problems
altogether. You don't need to allow two databases in the same folder.
This can become major source of problems.


Michael

Michael,

<< This is going to be MAJOR PITA! I think you should reconsider this design
before it's too late. >>

For who besides us ?  How often do you need to move around a configuration
file for a DBISAM database server today ?  It's the same thing.

<< If you need to protect the database, store the security info inside the
folder. In any case, it's all too easy to move folders around, so there's no
way to protect it really. You are just creating problems for nothing... >>

If the internal catalog ID doesn't match, then a database can't be opened.
Moving around the configuration file will break the relationship and make
the database unusable, similar to simply losing the password.  You're making
statements here without even understanding how the whole thing works.

<< Then keep them in the database. >>

So, if someone has 1000 databases on a system, you would rather have them
define the same users, roles, jobs, etc. for all 1000 databases ?

<< What's a config file in case of local access mode? >>

The same as with remote access.  It stores the users, roles, jobs, and
databases for the entire system.

<< I think it's the same problem as with DatabaseName property. >>

No, it's not.  The two aren't even close to being the same issue.

<< Create 2 sessions: Default & Remote.
In default session create database Test -> e:\temp\db
Create table T (i int, a varchar(100))
Add some rows of data.
Close it all.

In remote session create database Test2 -> e:\temp\db
Create table T (i int, a float)
No errors or warnings so far.
Open table and view data - see binaries groups for screenshot.
It's obviously corrupt. (not physically yet).
Execute statement
insert into "T" values (0, 1, 1)
This actually ruins it. >>

I'll try it here and let you know.

<< Btw, there's something strange with inserts. It seems like it is
expecting RowID column as first column, because the table is only 2 columns.
>>

You have to leave a NULL value for the RowID column.

<< It seems, that the catalog file must have the same name as the database,
isn't it? I'd rather name it catalog.edb and kill all these problems
altogether. You don't need to allow two databases in the same folder. This
can become major source of problems. >>

We had it this way originally.  Like I said, the database name is
irrelevant, therefore if I need to change it back to something hard-coded it
won't matter a bit in how EDB works other than to close down the hole that
you mention above.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> << This is going to be MAJOR PITA! I think you should reconsider this design
> before it's too late. >>
>
> For who besides us ?  How often do you need to move around a configuration
> file for a DBISAM database server today ?  It's the same thing.
Very simple example (I actually do this every day).
You have a local server and you have remote clients. You
download a database from client (as a folder) and you need to
register it on your local server. That's what I do with dbisam.
How do I accomplish that with ElevateDB?
(I need a physical database, not a backup copy, because I need to
test it, say, it could be corrupt or something).

Here's a list of databases, allowing this: ANY but Oracle.

> << If you need to protect the database, store the security info inside the
> folder. In any case, it's all too easy to move folders around, so there's no
> way to protect it really. You are just creating problems for nothing... >>
>
> If the internal catalog ID doesn't match, then a database can't be opened.
> Moving around the configuration file will break the relationship and make
> the database unusable, similar to simply losing the password.  You're making
> statements here without even understanding how the whole thing works.
No, I understand....

> << Then keep them in the database. >>
> So, if someone has 1000 databases on a system, you would rather have them
> define the same users, roles, jobs, etc. for all 1000 databases ?
Good idea, I shell create 1000 databases and see how it will affect
the system.

I actually have hundreds of databases. I am very glad I don't have to
see them all in my dbisam admin. I just connect the one(s) I need
to work with.

Registering database with server is a more logical option. You can
move databases back and forth. Server can store config for registered
databases. The way it use to be done in dbisam was perfect!

> << What's a config file in case of local access mode? >>
> The same as with remote access.  It stores the users, roles, jobs, and
> databases for the entire system.
Okey...

> << I think it's the same problem as with DatabaseName property. >>
> No, it's not.  The two aren't even close to being the same issue.
OKey, maybe I'm wrong.

> You have to leave a NULL value for the RowID column.
??? Okey, it's your design and all... I seriously don't understand it...


Cheers,
Michael

Michael,

<< Very simple example (I actually do this every day). You have a local
server and you have remote clients. You download a database from client (as
a folder) and you need to register it on your local server. That's what I do
with dbisam. How do I accomplish that with ElevateDB?
(I need a physical database, not a backup copy, because I need to test it,
say, it could be corrupt or something). >>

IOW, the same thing that we'll have to do, i.e. your coming at it from *our*
perspective, not our customers' perspectives.  In our case, we'll need to
have the configuration file in addition to the database.

<< Here's a list of databases, allowing this: ANY but Oracle. >>

And they all store the users/roles/etc. in the database itself or use
external methods of authorization of users (Windows).  And none of them
provide both client/server and local access like DBISAM and EDB do.
Therefore, your comparison is basically invalid to begin with.  There are
additional challenges to deal with when allowing direct local access to a
database.

<< Good idea, I shell create 1000 databases and see how it will affect the
system. >>

We do have customers that run processing service installations like payroll
services that have the thousands of separate databases, one for each client.
I actually kept this in mind while designing the system.

<< I actually have hundreds of databases. I am very glad I don't have to see
them all in my dbisam admin. I just connect the one(s) I need
to work with. >>

Yes, and DBISAM provides *zero* user security in terms of allowing a local
user to access a database without going through the database server.

<< Registering database with server is a more logical option. You can move
databases back and forth. Server can store config for registered
databases. The way it use to be done in dbisam was perfect! >>

Yes, but EDB isn't DBISAM, and it never will be.  If we wanted to create a
new DBISAM, we would have created a new DBISAM.

<<  ??? Okey, it's your design and all... I seriously don't understand it...
>>

I'm considering changing this.  After thinking about this last night, Ole
may have a point with the RowID column exposure.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> IOW, the same thing that we'll have to do, i.e. your coming at it from *our*
> perspective, not our customers' perspectives.  In our case, we'll need to
> have the configuration file in addition to the database.
I'm not sure how this will help, especially if I need to work
simultaneously on two databases made with two configuration files.
Also, I'm not sure what customer's perspective is - in my view customers
only see our software and can't care less what's behind. What's good for
me, is good for my customers...

There's something here, that I'm just not understanding. Seriously,
without trying to criticize the design or anything, I'm just trying
to imagine what is the value of such decision. Care to elaborate?
Is this because you see ElevateDB being a competitor of MS SQL or
Oracle? But even those allow to transfer physical database and
change config file manually (even Oracle allows you to adjust control
file to point to a different physical storage!).

My point here is that, please understand, that maybe you just
don't realize how much developers hate these things - and they
are the ones who will either love or hate your database, not
the customers.

From what I'm gathering, if you lost config file, you're cooked.
You will no longer be able to connect to your database. Is this
correct? If this is correct, then please, reconsider this
decision - the real data is so much more valuable then any config
file, that we must never make one dependent on the other, no
matter how logical or secure it may sound.

> << Here's a list of databases, allowing this: ANY but Oracle. >>
>
> And they all store the users/roles/etc. in the database itself or use
> external methods of authorization of users (Windows).
Nothing wrong with that.

> And none of them
> provide both client/server and local access like DBISAM and EDB do.
Firebird/Yaffil (btw, your major competitors!).
I'm not sure about Nexus2 - I don't remember how they handle security
but they definitely provide local access.

> Therefore, your comparison is basically invalid to begin with.  There are
> additional challenges to deal with when allowing direct local access to a
> database.
I don't see how you can validate security for local access. Period.
You can password protect (scramble) files, but that's it.
I think it would be sufficient to store object_access_permissions
(i.e. which objects can be accessed by which role) in the database,
while storing Users and Roles on the server. Server then authenticates
the login, i.e. it says, that the user Mike is really Mike. Then you
can apply security restrictions stored in database catalog for each
object - this seem pretty natural. In case of local access, you cannot
authenticate users, so the program must do it itself, so you must
trust it. If it says, this user is Mike, then that's who he is.

One may prevent local access, by starting server as service and locking
all the registered databases right away for read access. Some databases
do that (not MS SQL, btw). Most database servers consider the following
to be true: if you can get a hold of the file, then security won't help
you.

> << Good idea, I shell create 1000 databases and see how it will affect the
> system. >>
> We do have customers that run processing service installations like payroll
> services that have the thousands of separate databases, one for each client.
> I actually kept this in mind while designing the system.
So, when they open database manager, they will see 1000 databases...
Not a pretty sight

> << I actually have hundreds of databases. I am very glad I don't have to see
> them all in my dbisam admin. I just connect the one(s) I need
> to work with. >>
> Yes, and DBISAM provides *zero* user security in terms of allowing a local
> user to access a database without going through the database server.
Sure, what's the problem? If you provide local access, then that's pretty
natural. Moreover, if you have local access to a file and the file is
not encrypted, then you can use Mike Shkolnik's utility to read it
without dbisam at all (same will be true for ElevateDB, I'm sure).
There's no such database, that can enforce security in local access mode
except by using encryption, which is rather slow.

> <<  ??? Okey, it's your design and all... I seriously don't understand it...
> I'm considering changing this.  After thinking about this last night, Ole
> may have a point with the RowID column exposure.
Thank you



Michael

Tim Young [Elevate Software] wrote:

> After thinking about this last night, Ole
> may have a point with the RowID column exposure.

Absolutely!  Just in case more voices help...

Michael,

<< I'm not sure how this will help, especially if I need to work
simultaneously on two databases made with two configuration files. >>

You can't.  You can only use one configuration file per application.

<< Also, I'm not sure what customer's perspective is - in my view customers
only see our software and can't care less what's behind. What's good for me,
is good for my customers... >>

My point was that moving around entire systems/configurations and databases
manually occurs most often for *our* support purposes, and would occur very
rarely for actual EDB customers.

<< There's something here, that I'm just not understanding. Seriously,
without trying to criticize the design or anything, I'm just trying to
imagine what is the value of such decision. Care to elaborate? >>

I've alread stated the design goal behind it - to not force customers to
duplicate user/role/job definitions across hundreds or thousands of
databases.  Even having to duplicate these objects across 10 databases is a
major synchronization issue.  In addition, the existing design works in the
same way as DBISAM did, thus allowing for the same type of session logins
and not forcing an entirely different database-centric architecture on
DBISAM customers migrating to EDB.  Moving users and roles to the databases
would require a completely different type of connection architecture where
logins would occur at the TEDBDatabase level instead of the TEDBSession
level.

<< My point here is that, please understand, that maybe you just don't
realize how much developers hate these things - and they are the ones who
will either love or hate your database, not the customers. >>

What "things" are you referring to ?

<< From what I'm gathering, if you lost config file, you're cooked. >>

How would you "lose" a configuration file ?

<< You will no longer be able to connect to your database. Is this correct?
>>

Well, we could get someone back up and running manually if necessary.
However, I doubt very much that this would be an issue.  We never saw an
issue with DBISAM's server configuration file going missing constantly in
the customers' installations.

<< If this is correct, then please, reconsider this decision - the real data
is so much more valuable then any config file, that we must never make one
dependent on the other, no matter how logical or secure it may sound. >>

This is nonsense.  What if someone deletes (or loses) a single-file database
?  Would you then claim that the data needs to be spread around a bit and
completely separated from the catalog information so as to avoid such a
situation ?  Any configuration you come up with is going to have exposures
to accidental deletion where all of the data is either inaccessible or lost.
There's no way around this, and it certainly isn't a reason to discount one
structure over another.

<< Nothing wrong with that. >>

Yes, there is.  I've pointed out twice that this is a major problem for
customers that have many databases defined in their systems.

<< Firebird/Yaffil (btw, your major competitors!). I'm not sure about
Nexus2 - I don't remember how they handle security but they definitely
provide local access. >>

I'm talking about multi-user local access.  Single-user access is basically
just compiling the database server into the application.  There's a big
difference.

<< I don't see how you can validate security for local access. Period. >>

Well, we're doing it with EDB.  If you don't login with a valid user
ID/password then you're out of luck.  The configuration file is encrypted
and cannot be read without knowing the encryption password used by the
system (same as with DBISAM).

<< You can password protect (scramble) files, but that's it. I think it
would be sufficient to store object_access_permissions (i.e. which objects
can be accessed by which role) in the database, while storing Users and
Roles on the server. Server then authenticates the login, i.e. it says, that
the user Mike is really Mike. Then you can apply security restrictions
stored in database catalog for each object - this seem pretty natural. In
case of local access, you cannot authenticate users, so the program must do
it itself, so you must trust it. If it says, this user is Mike, then that's
who he is. >>

You're not thinking this through at all.  What you just described is exactly
how EDB handles C/S authentication.  How would you associate users and roles
"stored on the server" with objects in the database(s) ?  You can't very
well have permissions piling up in the database for non-existent users or
roles.  There has to be some kind of relationship between the two.

EDB handles server access and local access identically in terms of user
security.   Both authenticate users using the configuration file.  The only
difference is that one does it over the wire via the server.  The local
security could be broken by listening on the network connection, but that's
simply solved by using C/S access instead.

<< One may prevent local access, by starting server as service and locking
all the registered databases right away for read access. Some databases do
that (not MS SQL, btw). Most database servers consider the following to be
true: if you can get a hold of the file, then security won't help you. >>

EDB is not just a database server, hence it has to take into account local
access also.

<< So, when they open database manager, they will see 1000 databases... Not
a pretty sight >>

Perhaps, but such installations certainly exist.

<< Sure, what's the problem? If you provide local access, then that's pretty
natural. Moreover, if you have local access to a file and the file is
not encrypted, then you can use Mike Shkolnik's utility to read it without
dbisam at all (same will be true for ElevateDB, I'm sure). There's no such
database, that can enforce security in local access mode except by using
encryption, which is rather slow. >>

Any external utility won't be able to read EDB files without also reading
the catalog file.  Currently the catalog file is not encrypted, but if we
encrypted it, it would block off any external access without the proper
password.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

I will try to keep it brief and not steel too much of your time -
I won't comment inline for that purpose I will try to clarify the
argument and only focus on what seem important.
If it is feasible at all in current circumstances of the development
cycle, I'd vote for getting some kind of user input on the
current design and hear out what users have to say.
Discussing it here with colleagues I see two things (not so many and
they could even have same origin , that get negative response:

1. Binding database to a catalog file *not stored inside the database*.
Yes all information ideally should be protected, but the
actual data should not depend on configuration for its integrity
unless they are stored together and in this case configuration
should actually be regarded as data. The whole idea of having to
categories: config and data signifies exactly that - one is more
important then the other. I don't want to go into details on
how painful it could be to support this thing. Rather then
arguing I think we should ask users. I see that a few have already
experienced that first hand here.

2. Binding catalog file name to the database name. People tend to
use multiple databases, so one must be able to refer to the same
database by different names. Also people tend to name databases
the same ('Data' being used in 90% cases). Imagine two independent
applications sharing EDB server with both databases designed
and shipped to use catalog file named 'data'.

If you like to allow several catalog files within a folder, then treat
them as schemas, as Ole suggested. Although, I must agree, that this
feature won't be appreciated or understood by most users It's
important to be able to escape to having single default schema.

Regarding roles\users\jobs - they should be defined on server,
no doubt about it. However, I'd store their relationship to objects
in the database. You don't need to clone any information
for that purpose. When you create a new database, you grant
permissions to users and only this information is stored in
the database. IOW,
Catalog stores
  Users
    Mike
  Roles
    User
I.e. it stores the results of
grant <role> to <user>

Database
  Table1
    read\write by 'User'
I.e. database stores the results of
grant <privilege> on <object> to <user>\<role>
You can store user names a literals in the database and you
don't need to store passwords.

This way you don't have to bind the database so tight to
the config and it will solve the first issue. The second
issue is solved by naming all catalogs catalog.edb (virtually
same as done in Nexus).

Also, there was criticism of storing users and roles on server
level: if you deploy two applications and they both define
role power_user the name will collide and the user will gain
access to another database. It does make sense to store roles
within database (because this is where they really belong),
while mapping users to roles on server level. The fact that
someone has 1000 identical databases (possibly requires
refactoring?) doesn't really justify intentionally wrong
design. I'd give it more thought. Maybe it's possible to
define shared roles so that all databases could use them
or store them on server and then instruct developers to prefix
roles they use in database with uri (contextsoft_com_poweruser).

I've never had to deal with such cases, so it's hard to tell
how important they are. These are mostly handled by DBAs for
large databases, but if EDB is aiming at the market of zero
config databases, then it could become a problem (or the
security will not be used - which is more likely if we read
poll results on your web site .

Server-side session authenticate users when user logs in
- both work in the same way as with dbisam.
The local session does not authenticate users, it takes whatever
user name you provide. For local access, application must
implement its own authentication scheme, whatever it could be.
It actually could be regarded as a great feature: I for once would
appreciate such opportunity immensely - I know that many database
apps don't really use database level security because it's hard
to coordinate with application-level security, which basically
doubles it anyway.
Also, in many serious cases, user authentication can be
related to the business logic (i.e. users are employee and
must be stored in database anyway, when you add user, you
only need to add her to database - the application then
could implement its own authentication). Also, you could
use Windows authentication - perhaps most adequate for
companies with a lot of users in Windows domain.

Damn, it's much longer then I intended to write... ;/.

> I'm talking about multi-user local access.  Single-user access is basically
> just compiling the database server into the application.  There's a big
> difference.
Are you saying that EDB supports file sharing mode?

Sincerely,
Michael


> << I'm not sure how this will help, especially if I need to work
> simultaneously on two databases made with two configuration files. >>
> You can't.  You can only use one configuration file per application.
>
> << Also, I'm not sure what customer's perspective is - in my view customers
> only see our software and can't care less what's behind. What's good for me,
> is good for my customers... >>
>
> My point was that moving around entire systems/configurations and databases
> manually occurs most often for *our* support purposes, and would occur very
> rarely for actual EDB customers.
>
> << There's something here, that I'm just not understanding. Seriously,
> without trying to criticize the design or anything, I'm just trying to
> imagine what is the value of such decision. Care to elaborate? >>
>
> I've alread stated the design goal behind it - to not force customers to
> duplicate user/role/job definitions across hundreds or thousands of
> databases.  Even having to duplicate these objects across 10 databases is a
> major synchronization issue.  In addition, the existing design works in the
> same way as DBISAM did, thus allowing for the same type of session logins
> and not forcing an entirely different database-centric architecture on
> DBISAM customers migrating to EDB.  Moving users and roles to the databases
> would require a completely different type of connection architecture where
> logins would occur at the TEDBDatabase level instead of the TEDBSession
> level.
>
> << My point here is that, please understand, that maybe you just don't
> realize how much developers hate these things - and they are the ones who
> will either love or hate your database, not the customers. >>
>
> What "things" are you referring to ?
>
> << From what I'm gathering, if you lost config file, you're cooked. >>
>
> How would you "lose" a configuration file ?
>
> << You will no longer be able to connect to your database. Is this correct?
>  >>
>
> Well, we could get someone back up and running manually if necessary.
> However, I doubt very much that this would be an issue.  We never saw an
> issue with DBISAM's server configuration file going missing constantly in
> the customers' installations.
>
> << If this is correct, then please, reconsider this decision - the real data
> is so much more valuable then any config file, that we must never make one
> dependent on the other, no matter how logical or secure it may sound. >>
>
> This is nonsense.  What if someone deletes (or loses) a single-file database
> ?  Would you then claim that the data needs to be spread around a bit and
> completely separated from the catalog information so as to avoid such a
> situation ?  Any configuration you come up with is going to have exposures
> to accidental deletion where all of the data is either inaccessible or lost.
> There's no way around this, and it certainly isn't a reason to discount one
> structure over another.
>
> << Nothing wrong with that. >>
>
> Yes, there is.  I've pointed out twice that this is a major problem for
> customers that have many databases defined in their systems.
>
> << Firebird/Yaffil (btw, your major competitors!). I'm not sure about
> Nexus2 - I don't remember how they handle security but they definitely
> provide local access. >>
>
> I'm talking about multi-user local access.  Single-user access is basically
> just compiling the database server into the application.  There's a big
> difference.
>
> << I don't see how you can validate security for local access. Period. >>
>
> Well, we're doing it with EDB.  If you don't login with a valid user
> ID/password then you're out of luck.  The configuration file is encrypted
> and cannot be read without knowing the encryption password used by the
> system (same as with DBISAM).
>
> << You can password protect (scramble) files, but that's it. I think it
> would be sufficient to store object_access_permissions (i.e. which objects
> can be accessed by which role) in the database, while storing Users and
> Roles on the server. Server then authenticates the login, i.e. it says, that
> the user Mike is really Mike. Then you can apply security restrictions
> stored in database catalog for each object - this seem pretty natural. In
> case of local access, you cannot authenticate users, so the program must do
> it itself, so you must trust it. If it says, this user is Mike, then that's
> who he is. >>
>
> You're not thinking this through at all.  What you just described is exactly
> how EDB handles C/S authentication.  How would you associate users and roles
> "stored on the server" with objects in the database(s) ?  You can't very
> well have permissions piling up in the database for non-existent users or
> roles.  There has to be some kind of relationship between the two.
>
> EDB handles server access and local access identically in terms of user
> security.   Both authenticate users using the configuration file.  The only
> difference is that one does it over the wire via the server.  The local
> security could be broken by listening on the network connection, but that's
> simply solved by using C/S access instead.
>
> << One may prevent local access, by starting server as service and locking
> all the registered databases right away for read access. Some databases do
> that (not MS SQL, btw). Most database servers consider the following to be
> true: if you can get a hold of the file, then security won't help you. >>
>
> EDB is not just a database server, hence it has to take into account local
> access also.
>
> << So, when they open database manager, they will see 1000 databases... Not
> a pretty sight >>
>
> Perhaps, but such installations certainly exist.
>
> << Sure, what's the problem? If you provide local access, then that's pretty
> natural. Moreover, if you have local access to a file and the file is
> not encrypted, then you can use Mike Shkolnik's utility to read it without
> dbisam at all (same will be true for ElevateDB, I'm sure). There's no such
> database, that can enforce security in local access mode except by using
> encryption, which is rather slow. >>
>
> Any external utility won't be able to read EDB files without also reading
> the catalog file.  Currently the catalog file is not encrypted, but if we
> encrypted it, it would block off any external access without the proper
> password.
>