At 11:04 PM 5/07/2004 +0200, you wrote:

>Please take a look at the last two lines which substitute the
>GRANT EXECUTE ON PROCEDURE USERS2_TRG_BS TO PUBLIC
>of the first script. I think that's what you all the time wanted to tell
>me. I changed the script the first time you mentioned this (in fact I
>went far beyond this and additionally granted ALL rights to PUBLIC on
>ALL database objects) - still, the result was the same.

Did you know that ALL refers only to SELECT, INSERT, UPDATE, DELETE and
REFERENCES privileges? It does not include EXECUTE privileges.

Did you know that PUBLIC refers only to users that are in the security
database? It doesn't include views, stored procedures or triggers. You
must assign privileges explicitly ON SPs and TO database objects.

Or that giving strong powers to PUBLIC in the security database makes your
server vulnerable to attack?

>Finally there's still no explanation why the select on the users view
>works fine if you apply my script to a complete new database and
>not to a copy of the security database.

The security database *is* "just a database". However, it is a special
database that is created during the building of the server. It has stuff
in RDB$SECURITY_CLASSES that the server doesn't (can't) create in user
databases. Of course it has special handling of its Access Control List
(ACL), because it happens to be the DB that is used to authenticate server
users, i.e. it is not a user-created database. It's not documented,
because it's not intended for access by human users. If you really want to
know what's there, study the source code.

> > Are you sure it says this?
> > Then you haven't told us something.
> > ...
>It seems a bit that you want to call me an incompetent liar, but
>probably I am just a bit too sensitive.

You certainly are. I don't remember calling you an incompetent
liar....however, I and others have been trying to get you on track, but
this thread has been a catalogue of conflicting and missing
information. We are keen to help but none of us has ESP!!

/* the script again */

Does one dare to remind such a sensitive creature that failing to commit a
table definition before performing DML on the table will cause corrupt data
to be stored? Or that you *still* don't have the correct permissions to
enable the view to call the procedure?

No, one has already tried too many times...

>Even if you think this please be so polite and don't let me know.

Take comfort I'll not presume to trouble you further. For example, someone
else can explain to you why calling UDFs in the security database creates a
gross security exposure...

<sigh>

/heLen