Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Determining Database Object Authorization

IP.com Disclosure Number: IPCOM000099871D
Original Publication Date: 1990-Feb-01
Included in the Prior Art Database: 2005-Mar-15
Document File: 3 page(s) / 126K

Publishing Venue

IBM

Related People

Banning, WL: AUTHOR [+3]

Abstract

A relational database is implemented by software that provides a Structured Query Language (SQL) programming interface and other programming interfaces as necessary to define an application environment. This software has been implemented in IBM's Operating System/2* (OS/2*) Extended Edition and is called the Database Manager.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 46% of the total text.

Determining Database Object Authorization

       A relational database is implemented by software that
provides a Structured Query Language (SQL) programming interface and
other programming interfaces as necessary to define an application
environment.  This software has been implemented in IBM's Operating
System/2* (OS/2*) Extended Edition and is called the Database
Manager.

      A relational database consists of a set of objects (tables,
views, indexes, and access plans).  Access to these objects is
controlled by the Database Manager.  Access privilege is determined
based on a user's identification (userid).  There are two types of
SQL statements: static and dynamic.  A dynamic SQL statement is
interpreted and access privilege determined each time the statement
is executed. The userid used to determine privilege is that of the
person executing the program containing the statement.  SQL
statements can be interpreted and access privileges determined before
program execution.  This process is called binding, and it results in
the creation of an access plan. SQL statements handled in this manner
are called static SQL statements.  The userid of the person
performing the bind operation is the userid used to determine access
privilege for static SQL statements.

      There are general-purpose programs that access database objects
(tables, for example) and allow users to perform a variety of
functions.  A common technique used by these programs is to provide
the user with a list of database tables that can then be manipulated.
 This technique is called an object-action paradigm and is a
fundamental construct of IBM's Common User Access (CUA) definition.

      Programs that provide user functions for SQL database objects
have considerable difficulty in determining the exact set of objects
to which the user has access.  Users are given access to objects
using the SQL GRANT/REVOKE statements.  It is important to present
the user only those objects they can access for two reasons.  First,
it is very annoying to an user to see an object, then attempt to
perform some function and fail because they do not have access
privileges.  Second, in situations where security is a paramount
concern, a user should never even be aware of an object for which
they have no access privileges.

      It is difficult to determine the list of user objects because
the user may have access to an object indirectly. Indirect access can
occur in two different ways.  First, the user may have access
implicitly to all objects in a database because of some access rights
to the database itself. Second, the user may have access to an object
due to their membership in a group.  It is convenient for those who
control access to database objects to GRANT access to a group rather
than to each individual in the group.  This reduces the job of
controlling object access.

      The definition of who belongs to the group is usually done
through ano...