At 05:53 PM 1/9/2003 -0200, IB/FB List wrote:

>Second one: Wich I think better for *the exposed problem*.
>Ignore records that are not "own" by the person (user/role/group) who sends
>as select statment. It's possible to do this using views, SP's, but I think
>will be a shorcut make some kind of "record hiding" as properties of a
>table like constraints, could be done in triggers but have a straight way
>if you do it on the table definition.

Triggers don't fire for select statements. The data masking is
easy to do with a view. Create the table, including a field called
OWNER. Create a trigger that sets OWNER = CURRENT_USER. Create
a view of the table with the condition WHERE OWNER = CURRENT_USER.
Set the view to be accessible by PUBLIC and the table to be accessible
only to the view.

> If you have an application written in
>VB, another on PHP that uses the database you should writen decrypt
>routines for the diferent client applications. For this reason I asked if
>server side encryption is a good thing.

I understand your argument, and there's commented out (ifdef'd to be
more precise) code in the engine to call encryption routines. My
guess is that the engineers at Borland began to include encryption
and discovered that the problem was a great deal more complex than
anticipated.

>Now the SYSDBA thing...
>
>I think it is discussed earlier... To have a SYSTEM user who can acces data
>for backup's but cannot connect to the database for normal use ? As Ann has
>said... If you have the GDB and Firebird sources everything can be done.

We could create a signed version of gbak that could securely identify
itself to the engine. That, of course, means that only one version of
gbak could be used with any particular version of the engine - given
the problems we already have with version skew, that's not terribly
appealing. The current mechanism for identifying a gbak connection is
entirely too weak to support reliable identification. Besides, if you've
got a backup, you've got the database. So, now instead of limiting access
to the database file, you've got to protect gbak. There just isn't an
answer there.

>But I think that not every one could read, understand, hack with the
>sources to overpass the security, of course, if one is REALLY interested on
>it they will do, but just for look at employees salary the work will be so
>hard...

What we've postulated here is an environment that allows the
malefactor access to the SYSDBA password and/or access to the
physical database file(s). We're going to be looking at many
aspects of security in V2. A quick fix now to increase confidence
without providing security is a mistake.

>... if the ALL the records that meat the search
>criteria are returned to the fb client (fb client not application client)
>and the fb client ignores the records that the user are not allowed to see,
>the work will be shared ...

Perhaps you should think that one through a bit more. The
client is a (relatively) small simple piece of code that
handles the remote protocol and a variety of application level
functions. It doesn't understand data at all.


Regards,

Ann
www.ibphoenix.com
We have answers.