I still argue that we should take the opportunity to not only fix this
issue, but to improve the FB product functionality.
The core requirement is to stop non-authorized users from viewing source
code. The current process is to delete the source code from the database.
There is also the common work around of inserting SYSDBA into the roles
table to prevent sysdba from connecting to the database. This
functionality is also being removed by locking off the system tables.
FB 3 is already working on stronger user authentication methods - sysdba
in newer versions of firebird does not necessarily mean the same as it did
in earlier releases.
On disk and over the wire encryption are also being worked on if not
implemented.
So, a database can theoretically have some items that are encrypted on the
database owners security authorization that even SYSDBA can not see, nor
can they decrypt since the on disk records are encrypted using the database
owners encryption key vs the regular users encryption key.
So, DDL statements such as GRANT VIEW which is used by MS SQL for metadata
security could be applied to FB.
This would not only answer the current problems of hiding the source code,
it would still allow authorized developers to check the source for version
comparisons.
It would also provide functionality which is provided by other database
engines and which would simplify the DBA's job.
-
GRANT VIEW DEFINITION TO public [WITH DECRYPTION KEY privatekey];
REVOKE VIEW DEFINITION TO public [WITH ENCRYPTION KEY privatekey];
This statement will override metadata-visibility limitations at the
database level. All metadata in the database will be
visible/invisible to *public
(or whoever you define)*.
-
GRANT VIEW DEFINITION ON OBJECT :: <object_name> TO public [WITH
DECRYPTION KEY privatekey];
REVOKE VIEW DEFINITION ON OBJECT :: <object_name> TO public [WITH
ENCRYPTION KEY privatekey];
This statement will override metadata-visibility limitations at the
object level. All metadata for the object will be visible/invisible to
*public*. If the object is a table, all the columns, indexes,
statistics, and constraints of the table will be visible to the *public*.
This behaviour also applies to GRANT VIEW DEFINITION ON ASSEMBLY and other
similar GRANT statements.
Obviously the encryption/decryption part would wait for later versions of
FB so as to not hold up on the release, but, for now, the behaviour could
be implemented. I believe such functionality for hiding columns/tables is
available in the redsoft version of firebird.
The extension to the parser could be provided now, while the hiding of an
objects source would delete the source until the encryption process is
properly thought through.
On 3 September 2014 07:44, Carlos H. Cantu <lis...@warmboot.com.br> wrote:
> I think we already reached a point where core developers can hit the
> hammer in what will be the chosen "solution" of this problem in FB 3.
> I would be satisfied with either relaxing rules in
> rdb$triggers/procedures, or with new syntax, or with last Jim's
> proposal of SET statement. I'll leave this to you (core developers)
> decide what one is more adequate for the time being.
>
> Another option (maybe not so simple) could be a flag in the database
> header that would tell Firebird if the source should be kept or not.
> The flag could be set with gfix, as we already do with forced writes,
> etc.
>
> About the other proposals, they can be discussed again for future
> releases, after FB 3 is finally out.
>
> []s
> Carlos
> http://www.firebirdnews.org
> FireBase - http://www.FireBase.com.br
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
