DOCSLIB.ORG

Forensic Attribution Challenges During Forensic Examinations of Databases

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Forensic Attribution Challenges During Forensic Examinations of Databases Forensic Attribution Challenges During Forensic Examinations Of Databases by Werner Karl Hauger Submitted in fulfilment of the requirements for the degree Master of Science (Computer Science) in the Faculty of Engineering, Built Environment and Information Technology University of Pretoria, Pretoria September 2018 Publication data: Werner Karl Hauger. Forensic Attribution Challenges During Forensic Examinations Of Databases. Master's disser- tation, University of Pretoria, Department of Computer Science, Pretoria, South Africa, September 2018. Electronic, hyperlinked versions of this dissertation are available online, as Adobe PDF files, at: https://repository.up.ac.za/ Forensic Attribution Challenges During Forensic Examinations Of Databases by Werner Karl Hauger E-mail: [email protected] Abstract An aspect of database forensics that has not yet received much attention in the aca- demic research community is the attribution of actions performed in a database. When forensic attribution is performed for actions executed in computer systems, it is nec- essary to avoid incorrectly attributing actions to processes or actors. This is because the outcome of forensic attribution may be used to determine civil or criminal liabil- ity. Therefore, correctness is extremely important when attributing actions in computer systems, also when performing forensic attribution in databases. Any circumstances that can compromise the correctness of the attribution results need to be identified and addressed. This dissertation explores possible challenges when performing forensic attribution in databases. What can prevent the correct attribution of actions performed in a database? The first identified challenge is the database trigger, which has not yet been studied in the context of forensic examinations. Therefore, the dissertation investigates the impact of database triggers on forensic examinations by examining two sub questions. Firstly, could triggers due to their nature, combined with the way databases are forensically acquired and analysed, lead to the contamination of the data that is being analysed? Secondly, can the current attribution process correctly identify which party is responsible for which changes in a database where triggers are used to create and maintain data? The second identified challenge is the lack of access and audit information in NoSQL databases. The dissertation thus investigates how the availability of access control and logging features in databases impacts forensic attribution. The database triggers, as defined in the SQL standard, are studied together with a number of database trigger implementations. This is done in order to establish, which aspects of a database trigger may have an impact on digital forensic acquisition, anal- ysis and interpretation. Forensic examinations of relational and NoSQL databases are evaluated to determine what challenges the presence of database triggers pose. A num- ber of NoSQL databases are then studied to determine the availability of access control and logging features. This is done because these features leave valuable traces for the forensic attribution process. An algorithm is devised, which provides a simple test to determine if database triggers played any part in the generation or manipulation of data in a specific database object. If the test result is positive, the actions performed by the implicated triggers will have to be considered in a forensic examination. This dissertation identified a group of database triggers, classified as non-data trig- gers, which have the potential to contaminate the data in popular relational databases by inconspicuous operations, such as connection or shutdown. It also established that database triggers can influence the normal flow of data operations. This means what the original operation intended to do, and what actually happened, are not necessarily the same. Therefore, the attribution of these operations becomes problematic and incorrect deductions can be made. Accordingly, forensic processes need to be extended to include the handling and analysis of all database triggers. This enables safer acquisition and analysis of databases and more accurate attribution of actions performed in databases. This dissertation also established that popular NoSQL databases either lack sufficient access control and logging capabilities or do not enable them by default to support attribution to the same level as in relational databases. Keywords: Digital Forensics, Database Forensics, Forensic Attribution, Database Trig- gers, Relational Databases, NoSQL Databases. Supervisor : Prof. Martin S. Olivier Department : Department of Computer Science Degree : Master of Science \We choose to ... do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win." John F. Kennedy (1963) \Quod scripsi, scripsi (What I have written, I have written)" Pontius Pilate (AD 36) Acknowledgements I wish to express my sincere thanks and gratitude to: • My parents who supported my decision to return to academia and continue with my studies. You supported and encouraged me throughout this endeavour; • Professor Martin S. Olivier for reactivating my academic mindset and his help, guidance and support over all the years; • All the members of the ICSA research group with whom I could exchange ideas and discuss my research (Victor, Stacy, Richard, Avinash). This dissertation is dedicated to my late father who unfortunately could not see its conclusion. Contents List of Figuresv List of Tables vi 1 Introduction1 1.1 Motivation...................................2 1.2 Objective...................................7 1.3 Problem Statement..............................9 1.4 Approach................................... 10 1.5 Dissertation Outline............................. 11 2 Database Systems Overview 14 2.1 Database History............................... 14 2.1.1 Network Era.............................. 15 2.1.2 Hierarchical Era............................ 16 2.1.3 Relational Era............................. 16 2.1.4 Object Oriented Era......................... 18 2.1.5 Object Relational Era........................ 18 2.1.6 NoSQL Era.............................. 19 2.2 Relevant Database Models.......................... 19 2.2.1 Relational Databases......................... 19 2.2.2 NoSQL Databases.......................... 20 2.2.3 NoSQL Database Types....................... 22 2.3 Database Triggers............................... 24 i 2.4 Conclusion................................... 27 3 Digital Forensic Science Overview 28 3.1 Forensics.................................... 28 3.1.1 Digital Forensics........................... 29 3.1.2 Database Forensics.......................... 31 3.2 Attribution.................................. 32 3.2.1 General Attribution.......................... 32 3.2.2 Forensic Attribution......................... 34 3.3 Conclusion................................... 37 4 Database Forensics Research 39 4.1 Research Classification............................ 40 4.2 Literature Survey............................... 42 4.3 Discussion................................... 48 4.4 Possible Explanations............................. 51 4.5 Conclusion................................... 56 5 Database Trigger Implementations 58 5.1 Investigation Context............................. 58 5.2 Specification.................................. 60 5.3 Standard Triggers............................... 61 5.4 Non-standard Triggers............................ 63 5.4.1 DDL Triggers............................. 64 5.4.2 Non-data Triggers........................... 65 5.5 Trigger Objects................................ 68 5.6 Conclusion................................... 68 6 Forensic Examination of Relational Databases 70 6.1 Forensic Acquisition and Analysis Implications............... 70 6.1.1 SQL Server Examination....................... 71 6.2 Forensic Interpretation Implications..................... 75 6.2.1 Identification and Forensic Attribution............... 75 ii 6.3 Discussion of Implications.......................... 80 6.4 Conclusion................................... 81 7 Trigger Identification Algorithm 82 7.1 Trigger Identification Considerations.................... 82 7.2 Top-Down Approach............................. 85 7.3 Bottom-Up Approach............................. 88 7.4 Conclusion................................... 90 8 Algorithm Implementation 91 8.1 Implementation Considerations....................... 91 8.2 Prototype Design............................... 93 8.3 Prototype Implementation Details...................... 95 8.4 Implementation Challenges.......................... 99 8.4.1 Scope/Visibility............................ 99 8.4.2 Encryption.............................. 99 8.4.3 Case Sensitivity............................ 100 8.4.4 False-Positive Errors......................... 100 8.4.5 Data Types.............................. 101 8.4.6 Recursion............................... 101 8.4.7 Performance.............................. 102 8.5 Prototype Test Details............................ 103 8.6 Conclusion................................... 104 9 Forensic Examination of NoSQL Databases 106 9.1 Survey Context................................ 107 9.2 Surveyed NoSQL databases......................... 108 9.2.1 MongoDB..............................
Load more

Recommended publications
  • Create Trigger Schema Postgresql
    Create Trigger Schema Postgresql Diligent Gallagher sometimes gallants any harp reinforms single-mindedly. Lumpier and exarate Scott tongue limitedly and isolated his interactions approvingly and incorruptly. Tinniest and unabolished Berkie never opaquing quiveringly when Morton fall-back his duress. The legitimate unique identifier for house person. Now is are going to supervise an SQL file for adding data argue the table. You might declare a CURSOR, use case query. The privileges required by postgres function level, more triggers are processed by a predefined set of a particular order to store structured data. Use bleach if exists option and remove one arm more views from pan database database in not current. This is considered more consistent. Already loaded into different schemas live inside hasura became a create triggers and creates a couple of creating user? We can prevent all kinds of looping code in procedures with aggregate queries to a client like where tp where not a logical view! CREATE then REPLACE FUNCTION public. This way to be buffered to delete on geometry columns changes have created in postgresql create trigger against by trigger automatically drops an insert and occasional baby animal gifs! This is impossible except by anyone, check before insert or functions in which takes a create trigger postgresql create additional tables are enabled when date? For application that makes their first. We did with respect to spot when a system section provides an audit table belongs to remove trigger is used inside their twin daughters. Such as mentioned in postgresql create schema objects scripted would not. Many explanations from this document have been extracted from there.
    [Show full text]
  • Part 1 Digital Forensics Module Jaap Van Ginkel Silvio Oertli
    Part 1 Digital Forensics Module Jaap van Ginkel Silvio Oertli July 2016 Agenda • Part 1: Introduction – Definitions / Processes • Part 2: Theory in Practice – From planning to presentation • Part 3: Live Forensics – How to acquire a memory image – Investigate the image • Part 4: Advanced Topics – Tools – Where to go from here – And more 2 Disclaimer§ • A one or two-day course on forensics will not make you a forensics expert. – Professionals spend most of their working time performing forensic analysis and thus become an expert. • All we can offer is to shed some light on a quickly developing and broad field and a chance to look at some tools. • We will mostly cover Open Source Forensic Tools. 3 Introduction Forensics in History 4 Forensics – History 2000 BC 1200 BC 5 Introduction Definitions / Processes 6 Forensics – The Field digital forensics Computer Forensics Disk Forensics Mobil Forensics Memory Forensics Datenbase Forensics Live Forensics Network Forensics 7 Forensics - Definition • Digital Forensics [1]: – Digital forensics (sometimes known as digital forensic science) is a branch of forensic science encompassing the recovery and investigation of material found in digital devices, often in relation to computer crime. • Computer Forensics [2]: – Computer forensics (sometimes known as computer forensic science) is a branch of digital forensic science pertaining to legal evidence found in computers and digital storage media. The goal of computer forensics is to examine digital media in a forensically sound manner with the aim of identifying, preserving, recovering, analyzing and presenting facts and opinions about the information. 8 Forensics - Definitions • Network Forensics [3]: – Network forensics is a sub-branch of digital forensics relating to the monitoring and analysis of computer network traffic for the purposes of information gathering, legal evidence, or intrusion detection.[1] Unlike other areas of digital forensics, network investigations deal with volatile and dynamic information.
    [Show full text]
  • Cruise Shipboard Property Management System Security Guide Release 19.1 F20778-01
    Oracle® Hospitality Cruise Shipboard Property Management System Security Guide Release 19.1 F20778-01 February 2020 Copyright © 1995, 2020, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government. This software or hardware is developed for general use in a variety of information management applications.
    [Show full text]
  • Creating Triggers with Trigger-By-Example in Graph Databases
    Creating Triggers with Trigger-By-Example in Graph Databases Kornelije Rabuzin a and Martina Sestakˇ b Faculty of Organization and Informatics, University of Zagreb, Pavlinska 2, 42000 Varazdin,ˇ Croatia Keywords: Trigger-By-Example, Graph Databases, Triggers, Active Databases. Abstract: In recent years, NoSQL graph databases have received an increased interest in the research community. Vari- ous query languages have been developed to enable users to interact with a graph database (e.g. Neo4j), such as Cypher or Gremlin. Although the syntax of graph query languages can be learned, inexperienced users may encounter learning difficulties regardless of their domain knowledge or level of expertise. For this reason, the Query-By-Example approach has been used in relational databases over the years. In this paper, we demon- strate how a variation of this approach, the Trigger-By-Example approach, can be used to define triggers in graph databases, specifically Neo4j, as database mechanisms activated upon a given event. The proposed ap- proach follows the Event-Condition-Action model of active databases, which represents the basis of a trigger. To demonstrate the proposed approach, a special graphical interface has been developed, which enables users to create triggers in a short series of steps. The proposed approach is tested on several sample scenarios. 1 INTRODUCTION Example approach has been introduced to simplify the process of designing database triggers. The The idea of active mechanisms able to react to a spec- approach uses the Query-By-Example (QBE) as a ified event implemented in database systems dates graphical interface for creating triggers (Lee et al., from 1975, when it was first implemented in IBM’s 2000b), and makes the entire trigger design process System R.
    [Show full text]
  • Tools User Guide Release 8.0 E84869-03
    Oracle® Hospitality Cruise Shipboard Property Management System Tools User Guide Release 8.0 E84869-03 December 2019 Copyright © 1995, 2019, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
    [Show full text]
  • Chapter 10. Declarative Constraints and Database Triggers
    Chapter 10. Declarative Constraints and Database Triggers Table of contents • Objectives • Introduction • Context • Declarative constraints – The PRIMARY KEY constraint – The NOT NULL constraint – The UNIQUE constraint – The CHECK constraint ∗ Declaration of a basic CHECK constraint ∗ Complex CHECK constraints – The FOREIGN KEY constraint ∗ CASCADE ∗ SET NULL ∗ SET DEFAULT ∗ NO ACTION • Changing the definition of a table – Add a new column – Modify an existing column’s type – Modify an existing column’s constraint definition – Add a new constraint – Drop an existing constraint • Database triggers – Types of triggers ∗ Event ∗ Level ∗ Timing – Valid trigger types • Creating triggers – Statement-level trigger ∗ Option for the UPDATE event – Row-level triggers ∗ Option for the row-level triggers – Removing triggers – Using triggers to maintain referential integrity – Using triggers to maintain business rules • Additional features of Oracle – Stored procedures – Function and packages – Creating procedures – Creating functions 1 – Calling a procedure from within a function and vice versa • Discussion topics • Additional content and activities Objectives At the end of this chapter you should be able to: • Know how to capture a range of business rules and store them in a database using declarative constraints. • Describe the use of database triggers in providing an automatic response to the occurrence of specific database events. • Discuss the advantages and drawbacks of the use of database triggers in application development. • Explain how stored procedures can be used to implement processing logic at the database level. Introduction In parallel with this chapter, you should read Chapter 8 of Thomas Connolly and Carolyn Begg, “Database Systems A Practical Approach to Design, Imple- mentation, and Management”, (5th edn.).
    [Show full text]
  • IDUG NA 2007 Michael Paris: Hitchhikers Guide to Data Replication the Story Continues
    Session: I09 Hitchhikers Guide to Data Replication The Story Continues ... Michael Paris Trans Union LLC May 9, 2007 9:50 a.m. – 10:50 a.m. Platform: Cross-Platform TransUnion is a global leader in credit and information management. For more than 30 years, we have worked with businesses and consumers to gather, analyze and deliver the critical information needed to build strong economies throughout the world. The result? Businesses can better manage risk and customer relationships. And consumers can better understand and manage credit so they can achieve their financial goals. Our dedicated associates support more than 50,000 customers on six continents and more than 500 million consumers worldwide. 1 The Hitchhiker’s Guide to IBM Data Replication • Rules for successful hitchhiking ••DONDON’’TT PANICPANIC •Know where your towel is •There is more than meets the eye •Have this guide and supplemental IBM materials at your disposal 2 Here are some additional items to keep in mind besides not smoking (we are forced to put you out before the sprinklers kick in) and silencing your electronic umbilical devices (there is something to be said for the good old days of land lines only and Ma Bell). But first a definition Hitchhike: Pronunciation: 'hich-"hIk Function: verb intransitive senses 1 : to travel by securing free rides from passing vehicles 2 : to be carried or transported by chance or unintentionally <destructive insects hitchhiking on ships> transitive senses : to solicit and obtain (a free ride) especially in a passing vehicle -hitch·hik·er noun – person that does the above Opening with the words “Don’t Panic” will instill a level of trust that at least by the end of this presentation you will be able to engage in meaningful conversations with your peers and management on the subject of replication.
    [Show full text]
  • SUGI 23: an Investigation of the Efficiency of SQL DML Operations Performed on an Oracle DBMS Using SAS/Accessr Software
    Posters An Investigation of the Efficiency of SQL DML Operations Performed on an ORACLE DBMS using SAS/ACCESS Software Annie Guo, Ischemia Research and Education Foundation, San Francisco, California Abstract Table 1.1: Before Modification Of Final Records Id Entry MedCode Period1 Period2 Indication AG1001 Entry1 AN312 Postop Day1 Routine AG1001 Entry2 AN312 Postop Day1 Routine In an international epidemiological study of 2000 cardiac AG1001 Final AN312 Postop Day1 Non-routine ← To be updated surgery patients, the data of 7000 variables are entered AG1001 Final HC527 Intraop PostCPB Maintenance ← To be deleted AG1002 Entry1 PV946 Intraop PreCPB Non-routine ← To be inserted through a Visual Basic data entry system and stored in 57 AG1002 Entry2 PV946 Intraop PreCPB Non-routine as ‘Final’ large ORACLE tables. A SAS application is developed to Table 1.2: After Modification Of Final Records automatically convert the ORACLE tables to SAS data sets, Id Entry MedCode Period1 Period2 Indication AG1001 Entry1 AN312 Postop Day1 Routine perform a series of intensive data processing, and based AG1001 Entry2 AN312 Postop Day1 Routine AG1001 Final AN312 Postop Day1 Routine ← Updated upon the result of the data processing, dynamically pass AG1002 Entry1 PV946 Intraop PreCPB Non-routine AG1002 Entry2 PV946 Intraop PreCPB Non-routine ORACLE SQL Data Manipulation Language (DML) AG1002 Final PV946 Intraop PreCPB Non-routine ← Inserted commands such as UPDATE, DELETE and INSERT to ORACLE database and modify the data in the 57 tables. A Visual Basic module making use of ORACLE Views, Functions and PL/SQL Procedures has been developed to The modification of ORACLE data using SAS software can access the ORACLE data through ODBC driver, compare be resource-intensive, especially in dealing with large tables the 7000 variables between the 2 entries, and modify the and involving sorting in ORACLE data.
    [Show full text]
  • Chapter 1 - Introduction to Pl/Sql
    CHAPTER 1 - INTRODUCTION TO PL/SQL TRUE/FALSE 1. A programming language allows the actions of an end user to be converted into instructions that a computer can understand. ANS: T PTS: 1 REF: 2 2. Structured Query Language (SQL) is considered a procedural language. ANS: F PTS: 1 REF: 2 3. PL/SQL fully supports SQL data types. ANS: T PTS: 1 REF: 3 4. PL/SQL allows blocks of statements to be sent to Oracle in a single transmission. ANS: T PTS: 1 REF: 4 5. Database security can be increased with application processing supported by PL/SQL stored program units. ANS: T PTS: 1 REF: 4 6. Program units can enable the access of database objects to users without the users being granted privileges to access the specific objects. ANS: T PTS: 1 REF: 4 7. If you have a piece of code that has the potential of being used by various applications, saving this code on the server allows it to be shared by several applications. ANS: T PTS: 1 REF: 5 8. A database model is a general framework or design that describes how the various components of an application will be addressed. ANS: F PTS: 1 REF: 5 9. The three-tier application model is also referred to as a client/server application. ANS: F PTS: 1 REF: 5 10. The term named program unit indicates that the program is saved in a database and, therefore, can be used or shared by different applications. ANS: F PTS: 1 REF: 6 11. An event can range from a user action, such as clicking the button on the screen, to a table update statement that automatically calls a database trigger.
    [Show full text]
  • Ten Years of Critical Review on Database Forensics Research
    Digital Investigation 29 (2019) 180e197 Contents lists available at ScienceDirect Digital Investigation journal homepage: www.elsevier.com/locate/diin Ten years of critical review on database forensics research * Rupali Chopade , V.K. Pachghare Department of Computer Engineering & IT, College of Engineering, Pune, India article info abstract Article history: The database is at the heart of any digital application. With the increased use of high-tech applications, Received 22 January 2019 the database is used to store important and sensitive information. Sensitive information storage leads to Received in revised form crimes related to computer activities. Digital forensics is an investigation process to discover any un- 30 March 2019 trusted or malicious movement, which can be presented as testimony in a court of law. Database fo- Accepted 7 April 2019 rensics is a subfield of digital forensics which focuses on detailed analysis of a database including its Available online 11 April 2019 contents, log files, metadata, and data files depending on the type of database used. Database forensics research is in its mid age and has not got awareness as compare to digital forensics research. The reason Keywords: Database forensics behind this is the internal complications of the database as well as the different dimensions to be Digital forensics considered for analysis. This review paper is focusing on the last ten years of research related to forensic Artifact analysis of relational and NoSQL databases along with the study of artifacts to be considered for database Recovery forensics. This review of the current state of database forensics research will serve as a resource to move SQL forward as far as research and investigation are concerned.
    [Show full text]
  • Lighting Application Suite
    Lighting Application Suite 7.0 System Manual Lighting Application Suite 7.0 System Manual (original version) Edition: 04.03.15 Published by: Traxon Technologies Europe GmbH Karl Schurz-Strasse 38 Paderborn, Germany ©2014, Traxon Technologies Europe GmbH All rights reserved Comments to: [email protected] Available for free download from www.traxontechnologies.com Subject to modification without prior notice. Typographical and other errors do not justify any claim for damages. All dimensions should be verified using an actual part. Except for internal use, relinquishment of the instructions to a third party, duplication in any type or form - also extracts - as well as exploitation and/or communication of the contents is not permitted. e:cue Lighting Application Suite: - Contents 1 Changes in LAS 7.0 9 1.1 Programmer .................................................................................................. 9 2 Introduction 11 2.1 The Lighting Application Suite ....................................................................... 11 2.2 About this book ............................................................................................. 11 3 How to use this manual 12 3.1 Previous knowledge ...................................................................................... 12 3.2 Levels............................................................................................................ 12 4 About the LAS 13 4.1 Objectives ....................................................................................................
    [Show full text]
  • Postgresql Replication Second Edition
    www.allitebooks.com PostgreSQL Replication Second Edition Leverage the power of PostgreSQL replication to make your databases more robust, secure, scalable, and fast Hans-Jürgen Schönig BIRMINGHAM - MUMBAI www.allitebooks.com PostgreSQL Replication Second Edition Copyright © 2015 Packt Publishing All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information. First published: August 2013 Second edition: July 2015 Production reference: 1240715 Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK. ISBN 978-1-78355-060-9 www.packtpub.com www.allitebooks.com Credits Author Project Coordinator Hans-Jürgen Schönig Vijay Kushlani Reviewers Proofreader Swathi Kurunji Safis Editing Jeff Lawson Maurício Linhares Indexer Priya Sane Shaun M. Thomas Tomas Vondra Graphics Sheetal Aute Commissioning Editor Kartikey Pandey Production Coordinator Komal Ramchandani Acquisition Editor Larissa Pinto Cover Work Komal Ramchandani Content Development Editor Nikhil Potdukhe Technical Editor Manali Gonsalves Copy Editors Dipti Mankame Vikrant Phadke www.allitebooks.com About the Author Hans-Jürgen Schönig has 15 years of experience with PostgreSQL.
    [Show full text]