Deze presentatie is gegeven tijdens de KScope conferentie 2012
Spreker: Patrick Barel
Titel: Should Invoker Rights Be Used?
Onderwerp: Developers Toolbox - Coding
Deze presentatie gaat over de vraag of het Invoker Rights model van de Oracle Database, voor verschillende gebruikers binnen dezelfde database, kan helpen bij het scheiden van de zichtbaarheid van de data. Door gebruik te maken van de techniek deze techniek kun je op een relatief eenvoudige wijze ervoor zorgen dat gebruikers alleen werken op hun eigen data en niet op die van anderen. Als het bijvoorbeeld gaat om een hosted applicatie, dan hoeft er nog maar één codebase te zijn, waardoor alle gebruikers direct profiteren van verbeteringen die aangebracht worden. Daarnaast leer je in deze sessie hoe je één set code kunt onderhouden voor verschillende gebruikers van de applicatie en hoe je je ‘gedeeltelijk’ kunt beschermen tegen SQL Injection.
1. Developers Toolbox – Coding
Should invoker rights be used?
Patrick Barel , AMIS, The Netherlands
Monday, June 25, 2012
ODTUG KScope 12
San Antonio, Texas, USA
2.
3. Definer Rights vs Invoker Rights
Prior to Oracle8i, whenever you executed a stored
program, it ran under the privileges of the account in
which the program was defined.
This is called the …
Definer Rights Model
With Oracle8i, you can now decide at compilation time
whether your program or package will execute in the
definer's schema (the default) or the schema of the invoker
of the code.
This is called the … Invoker Rights Model
6. Invoker Rights
Allows you to centralize
access to and control of
underlying data structures.
Uses roles and doesn’t rely
on directly-granted
privileges.
But it can be a source of
confusion and architectural
problems.
Note: Oracle built-in packages have
long had the capability of running
under the invoker's authority.
7. What’s wrong with Definer Rights
Deployment & maintenance
Must install module in all schemas where needed
In some databases, each user has own copy of
table(s), requiring copy of stored module
Security
No declarative way to restrict privileges on certain
modules in a package -- it's all or nothing, unless
you write code in the package to essentially
recreate roles programmatically.
Difficult to audit privileges
Sure would be nice to have a choice...and now you do!
8. Invoker Rights
For top level modules:
CREATE [ OR REPLACE ] <module type>
[ AUTHID { DEFINER | CURRENT_USER } ]
AS ...
For modules with separate spec and body,
AUTHID goes only in spec, and must be at the
package level.
Holds true for packages and object types.
9. Overview of Definer Rights
begin package y
x.foo; authid
package x definer
end;
authid
definer
package z
authid
definer
Emp Emp Emp
10. Overview of Invoker Rights
begin package y
x.foo; authid
package x definer
end;
authid
current_user
package z
authid
current_user
Emp Emp Emp
11. Overview of Invoker Rights
begin
x.foo;
end;
package y
Emp authid
package x definer
authid
current_user
begin package z
x.foo; authid
end; current_user
Emp Emp Emp
24. SQL Injection
Dynamic SQL
Modification (drop) of objects
You cannot drop what is not there
Modification of records
Will only affect current users data
You should always use binding
instead of concatenating in
Dynamic SQL Statements
25. Rules and Restrictions
AUTHID DEFINER Definer Rights Model
Uses directly granted
privileges
Default, so no need to change current code
AUTHID CURRENT_USER Invoker Rights Model
Uses ROLEs
On entire objects
Need for ‘mock’ objects
(at compile time it’s Definer Rights)