> Allowing a stored procedure to run with permissions other than

those it

> has been specifically granted or those of the person who invokes it
> strikes me as a serious security hole

Here is one hole with 10 seconds of thought.

If someone dynamically generated the SQL statement based on input
parameters, and used the execute statement PSQL. I am sure someone
could come up with a better example.

procedure EmptySomeTable(tablename ) which builds a dynamic delete
from statement could effectively elevate someones privillege by
allowing them to bomb any table they want (plus foreign key cascades
I suppose). This is an extreme example, but an SQL injection attack
could be mounted in many cases where the execute statement is run
inside the SP. At least with database object permissions, even though
they could craft nasty queries, the SP itself can't do it.

Worse still if it is possible to dynamically generate a grant
statement (I haven't tried it and don't want to even think about it),
then you would be in all sorts of bother.

>, and I wouldn't want to see us do
> it in any general way. If you don't care particularly about the

issue,

> you could use the RDB$DEPENDENCIES table to identify the tables

used by

> each stored procedure and generate a list of grant statements that

grant

> all rights to the procedure on each table it references.

Not a bad idea Ann, for most stored procedures this would work a
treat. (DB Tool writers take note).

Adam