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]