Browse Prior Art Database

Compatibility of Access Control Lists and Permission Bits in AIXv3

IP.com Disclosure Number: IPCOM000122576D
Original Publication Date: 1991-Dec-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 3 page(s) / 161K

Publishing Venue

IBM

Related People

Camillone, NA: AUTHOR [+3]

Abstract

In most UNIX* systems, Discretionary Access Control (DAC) is provided by means of permission bits. These are nine bits which define the discretionary access control state of each storage object in the system. For each of three classes of users (the associated user (owner), the associated group and others), there are three bits which grant or deny read or write or execute permission. For directory objects, the execute permission bit is interpreted as directory search.

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

Compatibility of Access Control Lists and Permission Bits in AIXv3

      In most UNIX* systems, Discretionary Access Control (DAC)
is provided by means of permission bits. These are nine bits which
define the discretionary access control state of each storage object
in the system. For each of three classes of users (the associated
user (owner), the associated group and others), there are three bits
which grant or deny read or write or execute permission. For
directory objects, the execute permission bit is interpreted as
directory search. The permission bits are processed in a ternary
manner - if the process requesting access has an effective user ID
equal to the object owner, then it receives the associated user
permissions; if the process has a group ID equal to that of the
object group, then it receives the associated group permissions;
otherwise, the process receives the default permissions assigned to
'other'.

      Processes perform discretionary access control functions with
two interfaces: chmod(), which writes the permission bits and stat(),
which reads the permission bits. These two 'physical' functions are
used by processes to perform the following 'logical' functions:
         copy:   copy the DAC state from one object to another
         modify: modify the DAC state of an object
         set:    set the DAC state of an object
         query:  perform some logical query on the DAC state of an
object
         save/restore:
                 save the DAC state of an object temporarily and
restore it at some later time
For example, in order to copy the DAC information from one object to
another, a process would read the permission bits of the first object
with stat() and then set these permission bits on the second object
with chmod().

      A serious problem arises when adding Access Control Lists
(ACLs) to a UNIX system. An ACL allows the specification of
additional DAC information for an object. (Normally, ACLs allow the
specification of access permissions or denials for large numbers of
different users and groups.) Because existing applications perform
logical DAC functions using the physical interfaces, the addition of
ACLs can cause these applications to fail. Using our copy example
given above, it can readily be seen that this operation will at least
partially fail, since it will copy only the DAC information for the
associated user and group of the file and for others, but will not
copy the additional DAC in formation, if any. This loss of precision
can result in security failures, and thus the addition of ACLS can
decrease the overall security of the system instead of increasing it.

      An additional problem arises from the interaction of the
permission bits and ACLs specified by the IEEE standard P1003.1. This
standard requires conforming systems to either implement ACLs as
additional restrictions upon the permission bits or to disable the
AC...