1 Lecture 16: Data Storage Friday, November 5, 2004.

Slides:



Advertisements
Similar presentations
Storing Data: Disk Organization and I/O
Advertisements

Storing Data: Disks and Files
Physical DataBase Design
Storing Data: Disks and Files: Chapter 9
Database Management Systems, R. Ramakrishnan and J. Gehrke1 Storing Data: Disks and Files Chapter 7.
1 Lecture 13: Security Wednesday, October 26, 2006.
1 Storing Data: Disks and Files Yanlei Diao UMass Amherst Feb 15, 2007 Slides Courtesy of R. Ramakrishnan and J. Gehrke.
Murali Mani Overview of Storage and Indexing (based on slides from Wisconsin)
1 Storage Hierarchy Cache Main Memory Virtual Memory File System Tertiary Storage Programs DBMS Capacity & Cost Secondary Storage.
Physical Storage Organization. Advanced DatabasesPhysical Storage Organization2 Outline Where and How data are stored? –physical level –logical level.
©Silberschatz, Korth and Sudarshan11.1Database System Concepts Chapter 11: Storage and File Structure Overview of Physical Storage Media Magnetic Disks.
Introduction to Database Systems 1 The Storage Hierarchy and Magnetic Disks Storage Technology: Topic 1.
1 Lecture 15-16: Security Wednesday, May 17, 2006.
Layers of a DBMS Query optimization Execution engine Files and access methods Buffer management Disk space management Query Processor Query execution plan.
1 Lecture 14: Midterm Review Security Friday, February 4, 2005.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Storing Data: Disks and Files Chapter 9.
Lecture 11: DMBS Internals
Storage and File Structure. Architecture of a DBMS.
Physical Storage Organization. Advanced DatabasesPhysical Storage Organization2 Outline Where and How are data stored? –physical level –logical level.
1 Database Security Floris Geerts. Course organization One introductory lecture (this one) Then, a range of db security topics presented by you You will.
Physical Storage Susan B. Davidson University of Pennsylvania CIS330 – Database Management Systems November 20, 2007.
Introduction to Database Systems 1 Storing Data: Disks and Files Chapter 3 “Yea, from the table of my memory I’ll wipe away all trivial fond records.”
Database Management Systems, R. Ramakrishnan and J. Gehrke1 Storing Data: Disks and Files Chapter 7 “ Yea, from the table of my memory I ’ ll wipe away.
Lecture #19 May 13 th, Agenda Trip Report End of constraints: triggers. Systems aspects of SQL – read chapter 8 in the book. Going under the lid!
1 Lecture 14: Transactions in SQL Monday, October 30, 2006.
ICS 321 Fall 2011 Overview of Storage & Indexing (i) Asst. Prof. Lipyeow Lim Information & Computer Science Department University of Hawaii at Manoa 11/9/20111Lipyeow.
Database Management Systems,Shri Prasad Sawant. 1 Storing Data: Disks and Files Unit 1 Mr.Prasad Sawant.
File Processing : Storage Media 2015, Spring Pusan National University Ki-Joune Li.
Physical Storage Organization. Advanced DatabasesPhysical Storage Organization2 Outline Where and How data are stored? –physical level –logical level.
Chapter Ten. Storage Categories Storage medium is required to store information/data Primary memory can be accessed by the CPU directly Fast, expensive.
11.1Database System Concepts. 11.2Database System Concepts Now Something Different 1st part of the course: Application Oriented 2nd part of the course:
DMBS Internals I. What Should a DBMS Do? Store large amounts of data Process queries efficiently Allow multiple users to access the database concurrently.
CS4432: Database Systems II Data Storage 1. Storage in DBMSs DBMSs manage large amounts of data How does a DBMS store and manage large amounts of data?
Datalog Another formalism for expressing queries: - cleaner - closer to a “logic” notation - more convenient for analysis - equivalent in power to relational.
CS 540 Database Management Systems
DMBS Internals I February 24 th, What Should a DBMS Do? Store large amounts of data Process queries efficiently Allow multiple users to access the.
DMBS Internals I. What Should a DBMS Do? Store large amounts of data Process queries efficiently Allow multiple users to access the database concurrently.
DMBS Architecture May 15 th, Generic Architecture Query compiler/optimizer Execution engine Index/record mgr. Buffer manager Storage manager storage.
The Relational Model (cont’d) Introduction to Disks and Storage CS 186, Spring 2007, Lecture 3 Cow book Section 1.5, Chapter 3 (cont’d) Cow book Chapter.
CS411 Database Systems Kazuhiro Minami 09: Storage.
COSC 6340: Disks 1 Disks and Files DBMS stores information on (“hard”) disks. This has major implications for DBMS design! » READ: transfer data from disk.
1 Lecture 15: Data Storage, Recovery Monday, February 13, 2006.
What Should a DBMS Do? Store large amounts of data Process queries efficiently Allow multiple users to access the database concurrently and safely. Provide.
1 Lecture 16: Data Storage Wednesday, November 6, 2006.
Database Security Advanced Database Dr. AlaaEddin Almabhouh.
Data Storage and Querying in Various Storage Devices.
The very Essentials of Disk and Buffer Management.
CS222: Principles of Data Management Lecture #4 Catalogs, Buffer Manager, File Organizations Instructor: Chen Li.
CS522 Advanced database Systems
CS 540 Database Management Systems
Lecture 13: Midterm Review and Security
Lecture 16: Data Storage Wednesday, November 6, 2006.
Database Management Systems (CS 564)
End of XQuery DBMS Internals
Disks and Files DBMS stores information on (“hard”) disks.
File Processing : Storage Media
Lecture 11: DMBS Internals
Lecture 9: Data Storage and IO Models
Disk Storage, Basic File Structures, and Buffer Management
File Processing : Storage Media
CPSC-310 Database Systems
Lecture 15: Midterm Review Data Storage
What Should a DBMS Do? How will we do all this??
Basics Storing Data on Disks and Files
Lecture 18: DMBS Overview and Data Storage
Lecture 14: Security Friday, October 28, 2005.
Lecture 17: Data Storage and Recovery
Lecture 15: Data Storage Tuesday, February 20, 2001.
CS222/CS122C: Principles of Data Management UCI, Fall 2018 Notes #03 Row/Column Stores, Heap Files, Buffer Manager, Catalogs Instructor: Chen Li.
Presentation transcript:

1 Lecture 16: Data Storage Friday, November 5, 2004

2 Outline SQL Security – 8.7 Part II: Database Implementation Today: Data Storage –The memory hierarchy – 11.2 –Disks – 11.3

3 Discretionary Access Control in SQL GRANT privileges ON object TO users [WITH GRANT OPTIONS] privileges = SELECT | INSERT(column-name) | DELETE | REFERENCES(column-name) object = table | attribute

4 Examples GRANT INSERT, DELETE ON Customers TO Yuppy WITH GRANT OPTIONS Queries allowed to Yuppy: Queries denied to Yuppy: INSERT INTO Customers(cid, name, address) VALUES(32940, ‘Joe Blow’, ‘Seattle’) DELETE Customers WHERE LastPurchaseDate < 1995 INSERT INTO Customers(cid, name, address) VALUES(32940, ‘Joe Blow’, ‘Seattle’) DELETE Customers WHERE LastPurchaseDate < 1995 SELECT Customer.address FROM Customer WHERE name = ‘Joe Blow’ SELECT Customer.address FROM Customer WHERE name = ‘Joe Blow’

5 Examples GRANT SELECT ON Customers TO Michael No Michael can SELECT, but not INSERT or DELETE

6 Examples GRANT SELECT ON Customers TO Michael WITH GRANT OPTIONS Michael can say this: GRANT SELECT ON Customers TO Yuppi Now Yuppi can SELECT on Customers

7 Examples GRANT UPDATE (price) ON Product TO Leah Leah can update, but only Product.price, but not (say) Product.name

8 Examples GRANT REFERENCES (cid) ON Customer TO Bill Customer(cid, name, address, …..) Orders(..., cid, …) cid=foreign key Now Bill can INSERT tuples into Orders Bill has INSERT/UPDATE rights to Orders. BUT HE CAN’T INSERT ! (why ?)

9 Views and Security David has SELECT rights on table Customers John is a debt collector: should see the delinquent customers only: David says: CREATE VIEW DelinquentCustomers SELECT * FROM Customers WHERE balance < GRANT SELECT ON DelinquentCustomers TO John David says: CREATE VIEW DelinquentCustomers SELECT * FROM Customers WHERE balance < GRANT SELECT ON DelinquentCustomers TO John Views are an important security mechanism

10 Revokation REVOKE [GRANT OPTION FOR] privileges ON object FROM users { RESTRICT | CASCADE } Administrator says: REVOKE SELECT ON Customers FROM David CASCADE John loses SELECT privileges on DelinquentCustomers

11 Revocation Joe: GRANT [….] TO Art … Art: GRANT [….] TO Bob … Bob: GRANT [….] TO Art … Joe: GRANT [….] TO Cal … Cal: GRANT [….] TO Bob … Joe: REVOKE [….] FROM Art CASCADE Same privilege, same object, GRANT OPTION What happens ??

12 Revocation Admin JoeArt CalBob Revoke According to SQL everyone keeps the privilege

13 New Challenges in Data Security SQL Injection Data collusion View Leakage

14 Three Attacks SQL injection Chris Anley, Advanced SQL Injection In SQL Server Applications, Latanya Sweeney’s finding Leakage in Views

15 SQL Injection Go to your favorite shopping Website and login: Normal use: Search order by date: 9/15/04’; drop table user; -- Now this: Search order by date: 9/15/04 Search order by date:

16 SQL Injection The DBMS works perfectly. So why is SQL injection possible so often ?

17 Latanya Sweeney’s Finding In Massachusetts, the Group Insurance Commission (GIC) is responsible for purchasing health insurance for state employees GIC has to publish the data: GIC(zip, dob, sex, diagnosis, procedure,...)

18 Latanya Sweeney’s Finding Sweeney paid $20 and bought the voter registration list for Cambridge Massachusetts: GIC(zip, dob, sex, diagnosis, procedure,...) VOTER(name, party,..., zip, dob, sex) GIC(zip, dob, sex, diagnosis, procedure,...) VOTER(name, party,..., zip, dob, sex)

19 Latanya Sweeney’s Finding William Weld (former governor) lives in Cambridge, hence is in VOTER 6 people in VOTER share his dob only 3 of them were man (same sex) Weld was the only one in that zip Sweeney learned Weld’s medical records ! zip, dob, sex

20 Latanya Sweeney’s Finding All systems worked as specified, yet an important data has leaked How do we protect against that ? Some of today’s research in data security address breaches that happen even if all systems work correctly

21 Leakage in Views Employee(name, department, phone) CREATE VIEW Emp SELECT name, department FROM Employee CREATE VIEW Phons SELECT department, phone FROM Employee CREATE VIEW Emp SELECT name, department FROM Employee CREATE VIEW Phons SELECT department, phone FROM Employee Want to keep secret the employees’ phone numbers Does this work ? Important leakage !

22 New Trend: Fine-grained Access Control SQL provides only coarse-grained control Hence, implemented by the application. BIG PROBLEMS: –Security policies checked at each user interface –Easy to get it wrong: SQL injection !

23 Policy Specification Language CREATE AUTHORIZATION VIEW PatientsForDoctors AS SELECT Patient.* FROM Patient, Treats, Doctor WHERE Patient.pid = Treats.pid and Treats.did = Doctor.did and Doctor.uid = %userId and %accessMode in (‘local’, ‘ssh’) CREATE AUTHORIZATION VIEW PatientsForDoctors AS SELECT Patient.* FROM Patient, Treats, Doctor WHERE Patient.pid = Treats.pid and Treats.did = Doctor.did and Doctor.uid = %userId and %accessMode in (‘local’, ‘ssh’) [Oracle 7i], [Rizvi et al.2004] Context parameters [Oracle] Several policy languages for XML (Too) many exists. The good ones re-use a declarative query language, e.g. SQL, Xpath, XQuery

24 Enforcement by query analysis/modification SELECT Patient.name, Patient.age FROM Patient WHERE Patient.disease = ‘flu’ SELECT Patient.name, Patient.age FROM Patient WHERE Patient.disease = ‘flu’ SELECT Patient.name, Patient.age FROM Patient, Treats, Doctor WHERE Patient.disease = ‘flu’ and Patient.pid = Treats.pid and Treats.did = Doctor.did and Doctor.userID = %currentUser SELECT Patient.name, Patient.age FROM Patient, Treats, Doctor WHERE Patient.disease = ‘flu’ and Patient.pid = Treats.pid and Treats.did = Doctor.did and Doctor.userID = %currentUser e.g. Oracle

25 Semantics The Truman Model: transform reality –ACCEPT all queries –REWRITE queries –Sometimes misleading results The non-Truman model: reject queries –ACCEPT or REJECT queries –Execute query UNCHANGED –Subtle semantics: instance dependent or independent [Rizvi et al. SIGMOD 2004] SELECT count(*) FROM Patients

26 Part II of this Course: Database Implementation Outline: Buffer manager Transaction manager (recovery, concurrency) Operator execution Optimizer

27 What Should a DBMS Do? Store large amounts of data Process queries efficiently Allow multiple users to access the database concurrently and safely. Provide durability of the data. How will we do all this??

28 Generic Architecture Query compiler/optimizer Execution engine Index/record mgr. Buffer manager Storage manager storage User/ Application Query update Query execution plan Record, index requests Page commands Read/write pages Transaction manager: Concurrency control Logging/recovery Transaction commands

29 The Memory Hierarchy Main Memory Disk Tape Volatile limited address spaces expensive average access time: ns MB/S transmission rates 100s GB storage average time to access a block: msecs. Need to consider seek, rotation, transfer times. Keep records “close” to each other. 1.5 MB/S transfer rate 280 GB typical capacity Only sequential access Not for operational data Cache: access time 10 nano’s

30 Main Memory Fastest, most expensive Today: 2GB are common on PCs Many databases could fit in memory –New industry trend: Main Memory Database –E.g TimesTen, DataBlitz Main issue is volatility –Still need to store on disk

31 Secondary Storage Disks Slower, cheaper than main memory Persistent !!! Used with a main memory buffer

32 How Much Storage for $200

33 Buffer Management in a DBMS Data must be in RAM for DBMS to operate on it! Table of pairs is maintained. LRU is not always good. DB MAIN MEMORY DISK disk page free frame Page Requests from Higher Levels BUFFER POOL choice of frame dictated by replacement policy

34 Buffer Manager Manages buffer pool: the pool provides space for a limited number of pages from disk. Needs to decide on page replacement policy LRU Clock algorithm Enables the higher levels of the DBMS to assume that the needed data is in main memory.

35 Buffer Manager Why not use the Operating System for the task?? - DBMS may be able to anticipate access patterns - Hence, may also be able to perform prefetching - DBMS needs the ability to force pages to disk.

36 Tertiary Storage Tapes or optical disks Extremely slow: used for long term archiving only

37 The Mechanics of Disk Mechanical characteristics: Rotation speed (5400RPM) Number of platters (1-30) Number of tracks (<=10000) Number of bytes/track(10 5 ) Platters Spindle Disk head Arm movement Arm assembly Tracks Sector Cylinder

38 Disk Access Characteristics Disk latency = time between when command is issued and when data is in memory Disk latency = seek time + rotational latency –Seek time = time for the head to reach cylinder 10ms – 40ms –Rotational latency = time for the sector to rotate Rotation time = 10ms Average latency = 10ms/2 Transfer time = typically 40MB/s Disks read/write one block at a time (typically 4kB)

39 Average Seek Time Suppose we have N tracks, what is the average seek time ? Getting from cylinder x to y takes time |x-y|