Re: More on: trigger access control failure on NEW

Tobias Downer <[email protected]>
Newsgroups gmane.comp.db.mckoi
Message-ID <[email protected]>
The triggered procedure, when run, has the rights of the creator of the 
trigger.  The reason it's this way is because it makes it possible to 
create a trigger that has access to objects that the user who changed 
the database, causing the triggered event, may not have access to.

You should create a trigger and the triggered procedure from the admin 
user if you wish it to have access to the SYS_INFO tables.  I will look 
into the OLD/NEW table access problem reported.  If you create the 
procedure and trigger from admin it should not be an issue.

Toby.

R.W. Shore wrote:

> It turns out that ther only way to successfully define a trigger is to 
> have the distinguished database-owner userid be the one that executes 
> the create-trigger statement. Another userid can successfully run a 
> create-trigger statement, but when the trigger fires it throws an 
> access-control exception on SYS_INFO.NEW (or .OLD, I’m assuming). There 
> doesn’t seem to be any way to grant the other user access to schema 
> SYS_INFO, nor is there any way to grant that user access to SYS_INFO.NEW.
> 
> I’m not sure whether this is a feature or a bug, and depending on my 
> mood I can argue either way. If this behavior is a feature, I’d suggest 
> also limiting the CREATE TRIGGER statement to the DBO, so there’s no 
> confusion about who is allowed to create triggers.



---------------------------------------------------------------
Mckoi SQL Database mailing list  http://www.mckoi.com/database/
To unsubscribe, send a message to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.