> -----Original Message-----
> From: Firebird-Architect@yahoogroups.com
> [mailto:Firebird-Architect@yahoogroups.com]On Behalf Of Alex Peshkov
>
> On the other hand, why are object names prefixed with 'SQL$' when
> building security class name? What is the magic of this prefix? What
> happens, if in ODS11 we simply use object name as it's security
> class name?

Is there someone enough brave to go to the Borland castle, kill the dragons
that surround it and ask the IB guys if someone remembers why this was done?

In v4, the old GDML model was changed. Probably "munged" is more accurate
than "changed".
Borland put rdb$user_privileges on top of rdb$security_classes since SQL
rights don't map 1:1 to GDML rights. For example, how do you express the
"control" GDML right in SQL?
:-)

Years later, Ann discovered that using GDML security commands and SQL
security commands didn't cause the same effect. Apparently Borland didn't
put all the needed triggers to go back and forth between the two tables.
Also, GDML logic is "allow everything by default" whereas SQL logic is "deny
everything by default". This causes "interesting" effects.

In an attempt to differentiate new security classes from the old ones that
can be manipulated through GDL -I think- Borland put SQL$ in front of
automatically created security classes in a trigger that belongs to
rdb$user_privileges. You will also see security classes like
SQL$DEFAULT<number>
This was done to give all fields in a relation a default sec class unless
you grant access to them specifically... in this case, each one is assigned
a specific sec class name and the corresponding class is created.

Also, I don't know who did the change, but in the old model, the security
class was held in the relation and in the field directly at run-time. Later,
only the class name is held in the run-time structures.

If you or our fellow Dima Sibiryakov think that the mess can be solved in a
few hours in the night it would be great.
:-)

C.