At 10:50 10/01/2003 -0500, you wrote:

>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.

Yes.. When I told about triggers is to maintain the record ownership.

I think views (as you told) and SP's could filter out the records in a
select. I was just doing a brainstorming and sharing my thoghts with you. I
(until now) do not need to do this kind of filtering, I just think if doing
this as a table definition could make easier (and more documented).

> > 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.

As I suspect it is far more complex than I could imagine... :-)

> >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.

Yes... I agree with you, I do not think that any of this features
(encrytion, data hidding, security) are for version 1.X. I think that are
some big changes to be made... I was just asking if there are any ideas
like this to be implemented, and if is possible to do, and if this is ok
for the hole community, than this will be added as Feature Requests in
future versions of FB.

> >... 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.

Yes... I have never looked in the FB Sources. But I suspected the client do
not have the data to know if the user can or cannot see a record or decrypt
it... My thoughts is if the client know and can interpret metadata, then
this informations could be delivered togheter with the metadata to the client.

>Regards,
>
>Ann
>www.ibphoenix.com
>We have answers.

Thanks for your answers, I do not intend to say what have to be done
instead ask the "GUYS" who know what to do and how is a better way of do
this... By the way I think my English (that is very poor) are almost
suficient to express myself. ;-)


Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br

----------


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.437 / Virus Database: 245 - Release Date: 06/01/2003


[Non-text portions of this message have been removed]