Databases 2012 Authorization

Transcription

1 Databases 2012 Christian S. Jensen Computer Science, Aarhus University

2 Controlling access to the database Identities owner, users, roles, public Objects tables or views (+ triggers, PSM code, types) Priviliges a range of different actions 2

3 Identities The owner of a database object unlimited priviliges to read and modify Users identified by their login identities explicitly assigned priviliges Roles hierarchical groups of users Public corresponds to the group of all users and roles 3

4 Objects Tables as objects the entire table a subset of the columns no row-based authorization Views as objects are treated like tables may provide a fine granularity 4

5 Priviliges SELECT the right to query a table INSERT the right to insert rows (or individual attributes) DELETE the right to delete rows UPDATE the right to update rows (or individual attributes) REFERENCES the right to include an attribute in a foreign key 5

6 Granting Priviliges GRANT priviliges ON object TO identity GRANT SELECT, UPDATE(office) ON People TO amoeller; GRANT INSERT, DELETE ON Exams TO engberg; 6

7 Transitive Granting GRANT priviliges ON object TO identity WITH GRANT OPTION; Now the grantee may pass on these (or weaker) priviliges to other identities GRANT SELECT, UPDATE ON Exams TO amoeller WITH GRANT OPTION; GRANT UPDATE(date, time) ON Exams TO schwarz; csj amoeller 7

8 Revoking Priviliges REVOKE priviliges ON object FROM identities CASCADE revoke priviliges, also remove transitive priviliges REVOKE priviliges ON object FROM identities RESTRICT revoke priviliges, fail if transitive priviliges are affected REVOKE GRANT OPTION FOR priviliges... revoke the right to grant future transitive priviliges 8

9 Derived Consequences A sequence of authorization changes: csj: amoeller: schwarz: csj: engberg: csj: GRANT SELECT ON Exams TO amoeller WITH GRANT OPTION; GRANT SELECT ON Exams TO schwarz WITH GRANT OPTION; GRANT SELECT ON Exams TO amoeller WITH GRANT OPTION; GRANT SELECT ON Exams TO engberg WITH GRANT OPTION; GRANT SELECT ON Exams TO schwarz WITH GRANT OPTION; REVOKE SELECT ON Exams FROM amoeller CASCADE; Which priviliges hold afterwards? 9

10 Grant Diagrams Nodes indicate identities and priviliges owner transitive with grant option transitive Edges indicate grant statements: csj UPDATE Exams amoeller UPDATE Exams schwarz UPDATE(date,time) Exams 10

11 Grant Diagram Well-Formedness Owners have all priviliges (implicit) All nodes are reachable from owner nodes No edges from nodes or to nodes: All edges lead to the same or weaker priviliges: amoeller UPDATE Exams jdn DELETE Exams 11

12 Revocation in Grant Diagrams (1/3) REVOKE priviliges ON object FROM identities CASCADE Remove the corresponding edge in the diagram Remove all nodes not reachable from nodes 12

13 Revocation in Grant Diagrams (2/3) REVOKE GRANT OPTION FOR priviliges ON object FROM identities CASCADE Change the target node from to : Remove edges from target to other nodes: Remove nodes not reachable from nodes 13

14 Revocation in Grant Diagrams (3/3) REVOKE priviliges ON object FROM identities RESTRICT Fail if any nodes become unreachable REVOKE GRANT OPTION FOR priviliges ON object FROM identities RESTRICT Fail if any nodes become unreachable 14

15 Derived Consequences A sequence of authorization changes: csj: amoeller: schwarz: csj: engberg: csj: GRANT SELECT ON Exams TO amoeller WITH GRANT OPTION; GRANT SELECT ON Exams TO schwarz WITH GRANT OPTION; GRANT SELECT ON Exams TO amoeller WITH GRANT OPTION; GRANT SELECT ON Exams TO engberg WITH GRANT OPTION; GRANT SELECT ON Exams TO schwarz WITH GRANT OPTION; REVOKE SELECT ON Exams FROM amoeller CASCADE; csj amoeller No priviliges are lost! engberg schwarz 15

16 The References Privilige CREATE TABLE Rooms ( room VARCHAR(15) PRIMARY KEY NOT NULL, capacity INT ); CREATE TABLE People ( name VARCHAR(40) NOT NULL, office VARCHAR(15) REFERENCES Rooms(room), userid VARCHAR(15) PRIMARY KEY NOT NULL, `group` CHAR(3) ); GRANT INSERT ON People TO amoeller; GRANT REFERENCES(room) ON Rooms TO amoeller; INSERT INTO People VALUE(...); Necessary to support foreign key references The validity of a foreign key yields information 16

17 Authorizing Queries INSERT INTO Participants ( SELECT AS meetid, pid, 'u' AS status FROM Meetings, Participants WHERE Meetings.meetid=Participants.meetid AND owner = 'amoeller' AND pid <> 'amoeller' AND pid NOT IN (SELECT room FROM Rooms)); Minimal requirements can be inferred: GRANT SELECT, INSERT ON Participants... GRANT SELECT ON Meetings... GRANT SELECT ON Rooms... 17

18 Restricted Inserts CREATE TABLE Payroll ( name VARCHAR(40), title VARCHAR(20), salary INT DEFAULT 1500 ); GRANT INSERT(name,title) ON Payroll TO amoeller; INSERT INTO Payroll VALUES('Anders Møller','beer taster'); amoeller INSERT INTO Payroll VALUES('Anders Møller','beer taster',8500); amoeller Default or NULL for missing values 18

19 Roles Combines groups of users with set of privileges CREATE ROLE Paymaster; GRANT UPDATE(salary) ON Payroll TO Paymaster; GRANT Paymaster TO amoeller WITH GRANT OPTION; kjensen SET ROLE Paymaster; GRANT Paymaster TO schwarz; amoeller SET ROLE Paymaster; UPDATE Payroll SET salary='8500' WHERE name='anders Møller'; schwarz All users and roles have the role public 19

20 Role Hierarchies CREATE ROLE Employee; CREATE ROLE Paymaster; CREATE ROLE Janitor; CREATE ROLE Boss; GRANT Employee TO Paymaster; GRANT Employee TO Janitor; GRANT Paymaster TO Boss; GRANT Janitor TO Boss; Boss Paymaster Janitor All priviliges are inherited Employee 20

21 Views CREATE VIEW Vips AS SELECT * FROM People WHERE group = 'vip'; GRANT SELECT ON Vips TO amoeller; Priviliges on the base tables are not considered they are neither implicitly granted nor required INSERT, DELETE, and UPDATE priviliges are meaningful for modifiable views 21

22 Granularity With Views SELECT priviliges are for the entire table Views allows finer granularity CREATE VIEW Employees AS SELECT name, title FROM Payroll; GRANT SELECT ON Employees TO amoeller; As if we could say: GRANT SELECT(name,title) ON Employees... 22

23 Row-Based Views allow priviliges on specific rows: CREATE VIEW SmallRooms AS SELECT * FROM Rooms WHERE Capacity <= 4; GRANT UPDATE(room) ON SmallRooms TO... Permission to change the names of small rooms 23

24 Field-Based Priviliges to change only individual data: CREATE VIEW AndersView AS SELECT title FROM Payroll WHERE name='anders Møller'; GRANT UPDATE ON AndersView TO amoeller; Too many views to maintain Really inefficient in pratice Some systems use special registers like CURRENT USER 24