Distributed database security with discretionary access control


Published on

Distributed database security with discretionary access control.. This was my my final year project. This is based on Bell Lapadula model

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Distributed database security with discretionary access control

  1. 1. 1 | P a g e Distributed Database Security using Discretionary Access Control A Project Report Submitted by SumitroBhaumik(Roll-000911001011) & JyotishkarDey (Roll-000911001036) Of B.E. IN INFORMATION TECHNOLOGY At FACULTY OF ENGINEERING AND TECHNOLOGY, JADAVPUR UNIVERSITY 2009-2013
  2. 2. 2 | P a g e Student Declaration We, ___________________________________________ ___________________________________________ of final year, declare that this report contains only work completed by us except for information obtained in a legitimate way from literature, company or university sources. All information from these other sources has been duly referenced and acknowledged. Signature of student : Date :
  3. 3. 3 | P a g e Certificate This is to certify that the project entitled “Distributed Database Security” is the work carried out by, __________________________________________________________________________________________, student of B.E. (IT) of Jadavpur University during the year 2012-2013,and that the project contains only work completed by them except for information obtained in a legitimate way from literature, company or university sources. All information from these other sources has been duly referenced and acknowledged. Signature of Guide: Date :
  4. 4. 4 | P a g e Acknowledgement We would like to express our special thanks of gratitude to our mentor Dr. Parama Bhaumik, who gave us the opportunity to work on this wonderful project on the topic of Distributed Database Security, which also helped us in doing a lot of Research and we came to know about so many new things. Finally, we would also like to thank our friends who helped us a lot in finishing this project within the limited time and our parents without whom this project might not have been possible. Sumitro Bhaumik Jyotishkar Dey
  5. 5. 5 | P a g e Contents 1. Introduction … 6 2. Objective … 8 3. Designing a secure Database …9 4. Multilevel Database Security …13 5. Granularity …17 6. Working Principle(Bell LaPadula Model) …18 7. Implementation …21 8. Limitations …22 9. Area of Use …23 10. Conclusion …24 11. References …25 12. Appendix …26
  6. 6. 6 | P a g e Introduction A conventional database management system does not consider the security aspect of the database. Consider an RDBMS designed using Oracle or MySQL. It only concerns with storage and organization of data. Standard RDBMS techniques like normalization, concurrency control are only considered. Database is designed by us considering normal forms to get rid of problems like insertion anomaly, deletion anomaly and incorrect summary problem. Concurrency control is done by the software. Sensitive data may be stored on such database and if we do not consider security aspects of these stored data then the security is compromised. In general case we have one centralised or distributed server storing data and clients in remote location access those data simultaneously. The data may be compromised on the way during transfer by Network security attacks like eavesdropping; decrypting the encrypted data. But in distributed database security we do not consider the security of the data in transit. What we are really interested about is the access control of different legitimate user. Suppose there are several tables and depending upon access rights different legitimate users should view some of the tuples and some of the columns of the tables. That is a part of the database is displayed to users depending upon access right. Here our goal is to implement such security level. In the security aspect of database we have to deal with several concerns. How do we protect the database from unauthorized access? Who should be able to see which part of tables? Who should be able to update? To solve the problem of eavesdropping, encryption may be used. But that is not the focus of our discussion. Our focus is on access and view of database according to privileges of users and sensitivity of security levels of the database. To solve the problem for unauthorised access, using a password is common practice. But it does not solve the whole problem as different users should view different parts of the database according to the sensitivity of security
  7. 7. 7 | P a g e levels. A higher authority has right to view more sensitive information’s than an ordinary employee who should be able to view only part of database. In computer security, Mandatory Access Control (MAC) is a type of access control in which only the administrator manages the access controls. The administrator defines the usage and access policy, which cannot be modified or changed by users, and the policy, will indicate who has access to which programs and files. MAC is most often used in systems where priority is placed on confidentiality. In computer security, Discretionary Access Control (DAC) is a type of access control in which a user has complete control over all the programs it owns and executes, and also determines the permissions other users have those files and programs. Because DAC requires permissions to be assigned to those who need access, DAC is commonly called described as a "need-to- know" access model
  8. 8. 8 | P a g e Objective The problem with MAC is that MAC provides tighter security because only a system administrator may access or alter controls.And also MAC policies reduce security errors.It reduces the degree of flexibility.MAC specifies the path of information flow.Multilevel security model is basically based on a finite state model known as Bell-Lapadula model.The Bell–LaPadula model defines a “secure state” through three multilevel properties • The Simple Security Property (ss Property) • The * (star) Security Property • The Discretionary Security Property The first two properties deal with MAC. Here in the first property a user with low privilege is not allowed to view an object with high privilege. In the second property a user with high privilege is not allowed to write on a n object having low privilege as he/she may write vital information there and the object of low priority being accessible to petty users there is a chance of security leak. Thus in MAC, we restrict the flow of information. But these property needs not to be followed always. Because we may trust few low privilege user to be able to read write upon sensitive information. Such situations are very common. Using MAC in such cases restricts our self to add these flexibilities. Also a super user has the legitimate rights to perform write operation on low privileged objects. But care has to be taken to avoid leakage of information. But unlike MAC, Discretionary Access Control(DAC )is more flexible.DAC is based on granting and revoking of privileges.Privileges here are assignedat two levels.Each user account is assigned rights or privileges and the relations are also assigned privileges is - the privilege to access a particular relation is controlled or restricted.
  9. 9. 9 | P a g e Designing a secure Database Step 1: Identification of subjects, objects and permitted actions (identification process). Substep 1.1: Identification of the subjects Characterization of the different user roles within the application must be performed in the first place. This is performed by studying the duties of the users within the application and the possible grouping of these duties into a user role that can have different sensitivities that depend on the need-to-know of the persons playing this role. The responsibilities of the individuals are characterized into two distinct levels of abstraction for the development of a User Role Hierarchy (URH): user roles and user categories. User roles allow the security designer to allow particular privileges to individual roles. To represent similarities that exist among user roles, a user category can be defined. Different categories can be grouped into categories of higher level. The highest category, represented as the root, contains all user roles. Privileges that are supplied to each role are passed on to its categories. The grouping of user roles into user categories is very application dependent. This step can be further divided into the following substeps: 1. Define all the user roles that exist within an application. 2. Group the existing user roles under the corresponding user category depending on the task of the user in the application. 3. Repeat step (2), grouping all user categories into higher category, until reaching the root category. As a result of these actions, the security designer obtains an initial characterization of the URH.
  10. 10. 10 | P a g e Substep 1.2: Identification of the objects. The security objects are the target of the security protection, and are in another sense the data contained in the application. Generally, data are characterized by high complexity and heterogeneity in both the nature and the sensitivity levels of the different data sets included in them. Organizing these data in a structured manner is necessary for the development of the appropriate user views, which in its turn is a required step in the design and implementation of the application. Data is grouped into data sets that will be target for the labelling process later. Data sets represent data with a common use. These data sets are grouped into a number of data categories. A data category characterizes common characteristics among related data sets. In turn, the different data categories can be grouped into one or more data categories of higher levels. Step 2: Assignment of security label (labeling process). Since our security policy supports MAC, the reading and writing of data by individuals is based on their authorized security clearance label. And since, the DAC security policy is supported too, a richer set of access modes that are specific to the particular type or category of information is granted to the individuals based on their need-to-know requirements. For this reason, we have first to define the security labels, assigned to users, data and sites, and then to define the type of permitted access. The security label has two parts: The level and the category. The category of a user depends on his position in the User Role Hierarchy (URH). The highest category that corresponds to the root of the URH tree contains all sub categories and roles defined in the application. The category of data depends on its usage and corresponds to the needs of some categories of users. The category of a site depends on its use (what categories of users use it and what categories of data they need to use) and on its type (whether it is standalone, internet connected, mobile, stationary, etc). The security levels assigned to each one of the users, data and sites are defined after an initial study that results in a rating of the clearance of users, the sensitivity of data and the trustworthiness of sites.
  11. 11. 11 | P a g e Substep 2.1: Assignment of security labels to the subjects Having obtained an initial characterization of the user roles (URH), this substep allows us to assign a security label to each user role starting from the root and moving to the last level before the leaves (that form the user roles) of the tree. More specifically: 1. Assign the category of the user role, as represented in the URH, then 2. Assign a level to the user role that represents the level part of the label. This level depends on the trustworthiness of the user and on his/her responsibility By completing this substep, the security designer obtains an initial characterization (overall structure) of the User Role Hierarchy, and a primary assignment of labels to users. Substep 2.2: Assignment of security labels to the objects After the overall structure of the User Role Hierarchy (URH) has been established, the security designer can then proceed to assign data sets to the URH leaves which correspond to the data that needs to be accessed by the user roles. In this process, the designer uses the information accessing requirements as a guide for ensuring that the correct privileges are given. The procedure is repeated until reaching the root. This step can be sub-divided into the following substeps: 1. Assign data sets starting with the user roles under a user category. 2. Move data sets shared by all user roles to their common user category. 3. Move data sets shared by all user categories to their common super categories. This procedure is repeated till reaching the root. 4. The label to be assigned to the data set then consists of : • A category that corresponds to the category of the node or the leaf already assigned in the URH. • A level that corresponds to the lowest clearance level of the user roles contained in the category. 5. Repeat this process for all the data sets within each user role, and then within their user categories. As a security check for this substep, a stand-alone classification of the sensitivity of the data can be processed. This classification is dependent on
  12. 12. 12 | P a g e both the content and the context of the data. In the case where the levels differ, the security designer must check and decide which level to assign. By completing this substep, the designer obtains an initial identification of privileges of each URH node and an initial label assigned to each data set.
  13. 13. 13 | P a g e Multilevel Database Security The security of a single element maybe different from other elements of the same record.The first layer corresponds to a model for a non-protected database. The second layer corresponds to a model for a multilevel database. In this second layer, we propose a list of theorems that must be respected in order to build a secure multilevel database. We also propose a new solution to manage cover stories without using the ambiguous technique of polyinstantiation. The third layer corresponds to a model for a MultiView database, that is, a database that provides at each security level a consistent view of the multilevel database In order to restrict the scope of the security related design problem, we have made a number of assumptions about the MLS-DBMS environment and operation. These assumptions and their consequences are discussed in this section. (The relational data model is discussed briefly in the next section) We have assumed that both the database and its access language conform to the relational model of data. This provides us with a well defined, regular language for defining the database structure and operations. We have assumed that it is necessary to provide data classification at a fine granularity; that is, at the tuple, attribute or even element level. We have also assumed that the results of functions applied to sets of data may need to be classified independently of the data itself. We have assumed that besides simply classifying each (arbitrary) unit of data, it will be necessary to classify data depending upon its value or content, and also the context in which it is seen. This need generalizes into the need to control the user’s inference of more sensitive information from less sensitive information.
  14. 14. 14 | P a g e Different views to different users having different security levels Relational Database Definitions The MLS-DBMS uses the relational data model and a query language based upon the relational algebra.In a relational database, the data may be thought of as being structured into tables. The columns of a relation are referred to as attributes. The degree of a relation is the number of attributes defined for that relation. The rows of a particular relation (table) are referred to as tuples. The cardinality of a relation is just the number of (unordered) tuples it contains. In a particular tuple, the field which corresponds to a particular attribute may contain any one of the values in the domain of that attribute.
  15. 15. 15 | P a g e Relational Algebra The five basic relational operators are: 1. Selection - The selection operator constructs a horizontal subset of a relation. The result of the selection operation is the subset of tuples within a relation, R, for which a specified predicate, P, is true. 2. Projection - The projection operator constructs a vertical subset of a relation. The result of the projection operation is the subset of R obtained by selecting specified attributes (A), and eliminating others (and also eliminating duplicate tuples within the attributes selected). 3. Union - The union of two relations of the same degree, R and S, is the set of tuples that are in R or S or both. 4. Set difference - The difference of two relations of the same degree, R and S, is the set of tuples in R but not in S. 5. Cartesian product - The Cartesian product of tworelations of degree m and n, R and S, is the set of (m x n)-tuples whose first m attributes form a tuple in R and whose last n attributes form a tuple in S. 6. Intersection - The intersection of two relations of the same degree, R and S, is the set of tuples in both R and S. 7. Join - The join of R and S is those tuples in the Cartesian product of R and S for which a specified join predicate, jp, is true. “View” Operation of a Multilevel Security System Apply projection,thenselection.Do this for another tuple. Then do join operation of these sets. Tuple granularity : Deletion Column granularity : Projection Join : Cartesian product followed by intersection
  16. 16. 16 | P a g e The different types of information in a Multilevel Security System Schema format for a Multilevel Security System Schema R(A1,C1,…,An,Cn,Tc) • R : relation name • Ai : attribute name • Ci : attribute security class • Tc : Tuple security classes
  17. 17. 17 | P a g e Granularity • Database: Different security levels are assigned to different database. Users having varied security levels are allowed only to access the granted database. • Tuple: Tuples are assigned different sensitivity levels of security. A user having a security level ‘x’ is allowed to access a tuple with security level y if ‘x>=y’. • Attribute: Attributes are assigned different sensitivity levels of security. A user having a security level ‘x’ is allowed to access an attribute with security level ‘y’ if ‘x>=y’. • Element: By using granularity on tuples as well as elements, we are able to achieve elemental level of granularity. A user with security level ‘x’ can see an element if he is able to access the corresponding tuple as well as the attribute. That is, we have to pass through both the tuple level as well as the attribute level security to access an element. Tuple and attribute granularity
  18. 18. 18 | P a g e Working Principle Bell – LaPadula Model Throughout the 1970s and 1980s, significant energy was exerted to address the problem of malicious and flawed software. The goal was to achieve MAC, where the basis of access control decisions was not at the discretion of individual users or even system administrators. We wanted to implement an organizational security policy to control access to objects that could not be affected by the actions of individual programs. The military funded most of this work, which focused on protecting the confidentiality of classified government data. In particular, the most common MAC mechanisms implemented to date address the problem of multilevel security, a simplified form of which is shown in Figure Multilevel security (MLS) is typically based on a formal model called the Bell- La-Padula model . In the MLS model, all subjects and objects are labelled with a security level. In our example, we have a PUBLIC and a SECRET sensitivity level. The levels represent the relative sensitivity of the data and the clearance of the user on whose behalf the subjects are operating (SECRET being data of "higher" sensitivity than PUBLIC). In MLS, subjects can always read and write objects at the same sensitivity. In addition, subjects can read lower-level objects ("read down") and write higher-level objects ("write up"). However, a
  19. 19. 19 | P a g e subject may never read higher-level objects ("no read up") nor write lower- level objects ("no write down"). The idea being that information can flow from lower levels to higher levels, but not the reverse, thereby protecting the confidentiality of the higher-level data. Unidirectional data flow The Bell-LaPadula model is built on the state machine concept. This concept defines a set of allowable states ( A i ) in a system. The transition from one state to another upon receipt of input(s) ( X j ) is defined by transition functions ( f k ). The objective of this model is to ensure that the initial state is secure and that the transitions always result in a secure state. The transitions between two states are illustrated in Figure 5-9. Figure 5.9: State transitions defined by the function f with an input X.
  20. 20. 20 | P a g e The Bell-LaPadula model defines a secure state through three multilevel properties. The first two properties implement mandatory access control, and the third one permits discretionary access control. These properties are defined as follows: 1. The Simple Security Property (ss Property): States that reading of information by a subject at a lower sensitivity level from an object at a higher sensitivity level is not permitted (no read up). In formal terms, this property states that a subject can read an object only if the access class of the subject dominates the access class of the object. Thus, a subject can read an object only if the subject is at a higher sensitivity level than the object. 2. The * (star) Security Property: States that writing of information by a subject at a higher level of sensitivity to an object at a lower level of sensitivity is not permitted (no write-down). Formally stated, under * property constraints, a subject can write to an object only if the access class of the object dominates the access class of the subject. In other words, a subject at a lower sensitivity level can write only to an object at a higher sensitivity level. 3. The Discretionary Security Property: Uses an access matrix to specify discretionary access control.
  21. 21. 21 | P a g e Implementation Our implementation has three different types of user • Manager • Employee • Public user Our implementation of a multilevel security system, has 3 basic functionalities • See database with a certain privilege • Delete a tuple with a certain privilege • Insert a tuple with a certain privilege See/ViewDatabases • After a user logs in, fetch security status according to login ID • According to login ID, use CURSOR to project necessary attributes which should be visible to the appropriate security level • SELECT the tuples which have security level equal to or lesser than the security of the logged in person Delete Tuple • If the logged in person is a manager, then and only then can the person delete a record Insert Tuple • If the logged in person is a manager or an employee, then and only then can the person insert a tuple • For an employee, certain attributes are mandatory but not visible to the security level of an employee. We have taken care of such attributes by setting them up as a function of user ID
  22. 22. 22 | P a g e Limitations • For every query, the security level of every element needs to be checked with the security level of the user. Hence, the process is a bit slow • Care has to be taken for some special conditions which might arise during “write up” operations
  23. 23. 23 | P a g e Area of Use • Banking- High level manager can see all data of all customers. Branch manager may see data of all customers in his/her branch. A customer can see only his data. An external audit agency may be allowed to see only final balance of all customers. • Defence- Higher authority can access top secret data. Mid level users can see those data which has been granted by higher authority. Outsiders are not allowed to access any data. • Office- Manager may access entire database. Ordinary users are allowed to access only a part of it. And publics who use the product of the company are allowed to see minimal information. • Public/Private Database systems- For database containing both public information (not at all sensitive) and private information (if leaked to outsiders will cause trouble) multilevel security is mandatory.
  24. 24. 24 | P a g e Conclusion This form of gradation of security has tremendous potential and is already being used by major companies and organization where information is accessed by both public users and members of the organization. However, it increases the minimum required hardware compared to a basic relational DBMS in order to calculate the extra security levels if we want to maintain the same order of efficiency. But since server hardware quality is increasing and cost per unit is decreasing, it is advisable for mid-tier to high-tier organizations to switch to this technology so save much hassle in the future regarding security. Multilevel security can be used in several areas in future. For instance, this concept may be implemented in the setop box of a TV. Before a person wants to view a TV program his/her age group is asked. Depending upon age group only appropriate programmes are allowed and the rest are discarded from the total set of channels which is being accessible to the setop box. Similar use can be used in online library. Depending upon age group and geographical locations books are filtered before being shown to the customer. A customer may not be allowed to read a book being banned by the government whereas the server is located outside the country. Search engines may filter search results like information on drugs, weapons for all age groups. But it may or may not allow contents on topics like violence, war depending upon age group. Whereas it may allow all results to defence or police use. Google earth blurs out areas sensitive to defence like map of Whitehouse to public whereas a for a top military official no ban is applied. In our project due to lack of time several functionalities are not implemented like updation function, use of a suitable interface at the front end with sql engine at back end.
  25. 25. 25 | P a g e References: • Wikipedia.org • J. McLean, “A General Theory of Composition for Trace Sets Closed under Selective Interleaving Functions,” Proceedings of 1994 IEEE Symposium on Research in Security and Privacy (IEEE Press, 1994), pp. 79–93. • Multilevel Security Issues in Distributed Database Management Systems II BhavaniThuraisingham
  26. 26. 26 | P a g e Appendix Different views to different users having different security levels
  27. 27. 27 | P a g e MAIN FUNCTION (Written in PL/SQL, tested in Oracle 9i) ------------------------------------------ -- -- -- . : FINAL YEAR PROJECT : . -- -- -- -- DISTRIBUTED SECURITY SYSTEM -- -- -- -- BY -- -- -- -- SUMITRO BHAUMIK ... 11 -- -- JYOTISHKAR DEY ... 36 -- -- -- ------------------------------------------ DECLARE l_privilegesecurity.val%TYPE; l_idinfo.id%TYPE; l_nameinfo.name%TYPE; l_telinfo.tel%TYPE; l_dobinfo.dob%TYPE; l_mailinfo.mail%TYPE; l_passwordinfo.password%TYPE; l_desinfo.designation%TYPE; l_temp number; l_option number; login_idinfo.id%TYPE; login_passwordinfo.password%TYPE; -- FOR INSERTING NEW TUPLES l_id_newinfo.id%TYPE; l_count integer; l_name_newinfo.name%TYPE; l_tel_newinfo.tel%TYPE; l_dob_newinfo.dob%TYPE; l_mail_newinfo.mail%TYPE; l_password_newinfo.password%TYPE; l_des_newinfo.designation%TYPE; --Selects rows of Manager CURSOR view_manager IS SELECT id FROM info WHERE Designation='Manager' OR Designation='Employee' OR Designation='Public'; --Selects rows of Employee CURSOR view_employee IS SELECT id FROM info WHERE Designation='Employee' OR Designation='Public'; --Selects rows of Public CURSOR view_public IS SELECT id FROM info WHERE Designation='Public'; ----------------------------------------------
  28. 28. 28 | P a g e -- -- -- . : FUNCTION see : . -- -- IT SELECTIVELY DISPLAYS THE DATABASE -- -- ACCORDING TO HIS OR HER SECURITY LEVEL -- -- -- ---------------------------------------------- FUNCTION see(l_privilege IN number) RETURN number IS z number; BEGIN --1 for manager, 2 for employee, 3 for public CASE l_privilege WHEN 1 THEN DBMS_OUTPUT.PUT_LINE('-------------------------------------------------------------------------------------- ----'); DBMS_OUTPUT.PUT_LINE(rpad('ID',3)||rpad('NAME',20)||rpad('TELEPHONE',12)||rpad('DOB',12)||r pad('MAIL',25)||rpad('DESIGNATION',20)); DBMS_OUTPUT.PUT_LINE('-------------------------------------------------------------------------------------- ----'); FOR iter_man IN view_manager LOOP SELECT id,Name,Tel,DOB,Mail,Designation INTO l_id,l_name,l_tel,l_dob,l_mail,l_des FROM info WHERE id=iter_man.id; DBMS_OUTPUT.PUT_LINE(rpad(l_id,3)||rpad(l_name,20)||rpad(l_tel,12)||rpad(l_dob,12)||rpad(l_mail, 25)||rpad(l_des,20)); END LOOP; WHEN 2 THEN DBMS_OUTPUT.PUT_LINE('------------------------------------------------------------------------'); DBMS_OUTPUT.PUT_LINE(rpad('NAME',20)||rpad('DOB',12)||rpad('MAIL',25)||rpad('DESIGNATION', 20)); DBMS_OUTPUT.PUT_LINE('------------------------------------------------------------------------'); FOR iter_emp IN view_employee LOOP SELECT Name,DOB,Mail,Designation INTO l_name,l_dob,l_mail,l_des FROM info WHERE id=iter_emp.id; DBMS_OUTPUT.PUT_LINE(rpad(l_name,20)||rpad(l_dob,12)||rpad(l_mail,25)||rpad(l_des,20)); END LOOP; WHEN 3 THEN DBMS_OUTPUT.PUT_LINE('--------------------------------------'); DBMS_OUTPUT.PUT_LINE(rpad('NAME',20)||rpad('DESIGNATION',20)); DBMS_OUTPUT.PUT_LINE('--------------------------------------'); FOR iter_pub IN view_public LOOP
  29. 29. 29 | P a g e SELECT Name,Designation INTO l_name,l_des FROM info WHERE id=iter_pub.id; DBMS_OUTPUT.PUT_LINE(rpad(l_name,20)||rpad(l_des,20)); END LOOP; END CASE; RETURN z; END; ------------------------------------------ -- -- -- . : FUNCTION del_tuple : . -- -- ALLOWS A PERSON TO DELETE A TUPLE -- -- IF HE OR SHE HAS THE PERMISSION -- -- -- ------------------------------------------ FUNCTION del_tuple(l_privilege IN number) RETURN number IS del_id number; BEGIN IF l_privilege> 1 THEN DBMS_OUTPUT.PUT_LINE('SORRY! YOU DONT HAVE PERMISSION TO DELETE'); ELSE DBMS_OUTPUT.PUT_LINE('ENTER THE ID OF THE PERSON YOU WANT DELETE'); del_id := &del_id; DELETE FROM info WHERE id = del_id; END IF; RETURN del_id; END; ------------------------------------------ -- -- -- . : FUNCTION insert_tuple : -- -- ALLOWS A PERSON TO INSERT A TUPLE -- -- -- ------------------------------------------ FUNCTION insert_tuple(l_privilege IN number) RETURN number IS insert_tuple number; BEGIN --Public are not allowed to inset IF l_privilege = 3 THEN DBMS_OUTPUT.PUT_LINE('PUBLIC USERS ARE NOT ALLOWED TO ENTER!'); --If not public ELSE SELECT max(id) INTO l_id_new FROM info; l_id_new :=l_id_new +1; l_password_new :=l_id_new; DBMS_OUTPUT.PUT_LINE(' ENTER NAME, DATE OF BIRTH, DESIGNATION AND MAIL ADDRESS'); l_name_new :='&l_name_new';
  30. 30. 30 | P a g e l_dob_new :=TO_DATE('&l_dob_new', 'DD.MM.YYYY'); l_des_new :='&l_des_new'; l_mail_new :='&l_mail_new'; DBMS_OUTPUT.PUT_LINE('NEW ID :'||l_id_new); DBMS_OUTPUT.PUT_LINE('NEW PASS :'||l_password_new); DBMS_OUTPUT.PUT_LINE('NEW NAME :'||l_name_new); DBMS_OUTPUT.PUT_LINE('NEW DOB :'||l_dob_new); DBMS_OUTPUT.PUT_LINE('NEW DES :'||l_des_new); --If manager IF l_privilege = 1 THEN DBMS_OUTPUT.PUT_LINE(' ENTER TELEPHONE'); l_tel_new :=&l_tel_new; INSERT INTO info VALUES(l_id_new,l_name_new,l_tel_new,l_dob_new ,l_mail_new,l_des_new,l_password_new); DBMS_OUTPUT.PUT_LINE('NEW TEL :'||l_tel_new); --If Employee ELSE INSERT INTO info VALUES(l_id_new,l_name_new,NULL,l_dob_new ,l_mail_new,l_des_new,l_password_new); END IF; END IF; RETURN insert_tuple; END; ---------------------------- -- -- -- . : MAIN SECTION : . -- -- -- ---------------------------- BEGIN DBMS_OUTPUT.PUT_LINE('ENTER USERNAME AND PASSWORD'); login_id := &login_id; login_password := '&login_password'; SELECT designation INTO l_des FROM info WHERE info.id=login_id; SELECT val INTO l_privilege FROM security WHERE designation=l_des; DBMS_OUTPUT.PUT_LINE('ENTER 1 TO VIEW'); DBMS_OUTPUT.PUT_LINE('ENTER 2 TO DELETE'); DBMS_OUTPUT.PUT_LINE('ENTER 3 TO INSERT'); l_option := &l_option; CASE l_option
  31. 31. 31 | P a g e WHEN 1 THEN l_temp := see(l_privilege); WHEN 2 THEN l_temp := del_tuple(l_privilege); WHEN 3 THEN l_temp := insert_tuple(l_privilege); END CASE; EXCEPTION WHEN no_data_found THEN DBMS_OUTPUT.PUT_LINE('NO SUCH RECORD ... INVALID INPUT!'); END; / DDL STATEMENTS INFO TABLE:: CREATE TABLE info ( id integer primary key, name Varchar2(20) NOT NULL, tel Number(10), dob DATE NOT NULL, mail Varchar2(30), designation Varchar2(20) NOT NULL, password Varchar2(20) NOT NULL ); SECURITY TABLE:: CREATE TABLE security ( designation Varchar2(20) NOT NULL, val integer NOT NULL, CONSTRAINT uc_value UNIQUE (val) );