|Subject||Re: stored procedures permissions question|
> Allowing a stored procedure to run with permissions other thanthose it
> has been specifically granted or those of the person who invokes itHere is one hole with 10 seconds of thought.
> strikes me as a serious security hole
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 doissue,
> it in any general way. If you don't care particularly about the
> you could use the RDB$DEPENDENCIES table to identify the tablesused by
> each stored procedure and generate a list of grant statements thatgrant
> 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).