Subject | Re: Firebird 1.5 for Linux -- database privileges |
---|---|
Author | Alexander V.Nevsky |
Post date | 2004-02-25T10:23:27Z |
--- In firebird-support@yahoogroups.com, Maciej Grzywocz <emgie@n...>
wrote:
them - RDB$USER_PRIVILEGES and RDB$SECURITY_CLASSES. After creation of
the table first immediately contains entries for all rights where
creator of the table (RDB$RELATIONS.RDB$OWNER_NAME) is mentioned as
both RDB$GRANTOR and RDB$USER. Entry in RDB$SECURITY_CLASSES appears
only after commit of transaction in which context table was created.
BTW, it is not safe in Firebird in general to access objects which
metadata is changed but not commited even in the same transaction
which performed metadata changes. Some necessary internal actions on
metadata changes engine perform on commit only.
improvement is sheduled for 2.0 version which is in pre-alpha stage
now. You can only trace who created objects using
Select RDB$OWNER_NAME From RDB$RELATIONS
Where RDB$RELATION_NAME='FOO'
Best regards,
Alexander.
wrote:
> For example, I can do:is
>
> $ isql localhost:employee.fdb
> SQL> create table foo (id int, name varchar(30));
>
> ...without any error. The table is then owned by the user whose name
> the same as system user name, although there is no entry in securityMaciej, you are mistaken about security table. Firebird have two of
> table, except for SYSDBA user.
them - RDB$USER_PRIVILEGES and RDB$SECURITY_CLASSES. After creation of
the table first immediately contains entries for all rights where
creator of the table (RDB$RELATIONS.RDB$OWNER_NAME) is mentioned as
both RDB$GRANTOR and RDB$USER. Entry in RDB$SECURITY_CLASSES appears
only after commit of transaction in which context table was created.
BTW, it is not safe in Firebird in general to access objects which
metadata is changed but not commited even in the same transaction
which performed metadata changes. Some necessary internal actions on
metadata changes engine perform on commit only.
> I would like to control which users create tables in specifiedpuzzled
> databases, but did not find information how to do it -- and I'm
> :/If under "control" you mean "rule" - you can't just now. Security
improvement is sheduled for 2.0 version which is in pre-alpha stage
now. You can only trace who created objects using
Select RDB$OWNER_NAME From RDB$RELATIONS
Where RDB$RELATION_NAME='FOO'
Best regards,
Alexander.