RE: More on: trigger access control failure on NEW
"R.W. Shore" <[email protected]>
| Newsgroups | gmane.comp.db.mckoi |
|---|---|
| Message-ID | <[email protected]> |
... and in fact things work just fine when the admin user is the one that issues the create-trigger command. It's just that nobody else can successfully execute a trigger. When a non-admin user issues the create-trigger command, the trigger gets the access-control violation on SYS_INFO.NEW, which I assume is the full name of the NEW table. You could make an argument that this is a security feature and not a bug, if fixing is in the too-hard category ;-) I didn't try issuing the create-procedure command from the non-admin user and the create-trigger command from the admin user, so I don't know if that would work or not. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tobias Downer Sent: Sunday, November 28, 2004 2:15 AM To: [email protected] Subject: Re: More on: trigger access control failure on NEW 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] --------------------------------------------------------------- Mckoi SQL Database mailing list http://www.mckoi.com/database/ To unsubscribe, send a message to [email protected]