next up previous
Next: Capability Lists Up: Protection Previous: Protection

A Model of Access Control

Access control concerns itself with the first question: how should we control the operations performed by a process on files and other resources supported by the OS? We study below a model of access control that provides such protection. The model we describe is quite general; it may be used protect not only files, but also directories, devices, segments and other shared entities.

Each shared entity will be called an object. An object provides certain operations, which a process may invoke to manipulate the object. A process can invoke an operation on an object only if it has appropriate access right or privilege to do so.

We can represent the state of all access rights by constructing an access matrix of the following form:

l l l l l.
	/dev/console	~fred/prog.c	~fred/letter	/usr/ucb/vi
fred's P	getc, putc, read, write	getc, putc, read, write	getc, putc, read, write	execute
fred's Q	getc, putc, read, write	getc, putc, read, write	getc, putc, read, write	execute
jane's R	getc, putc, read, write	getc, read		execute
In this table, there are four objects: the console, the text file "prog.c" in user fred's directory, the file `` fred/letter'', and the object file for an editor; and three processes: P, Q and R. Processes P and Q are running on behalf of user fred, whereas process R is running on behalf of user jane.

Each entry in the table indicates the access rights of a process on an object. Thus all three processes can invoke the execute operation on the editor but cannot read or modify it. Processes P and Q, running on behalf of user fred can both read and modify fred's prog, while process R, running on behalf of user jane, can only read the file.

In the above table, we have assumed that the access rights are defined in terms of the specific operations of an object. Thus the `getc' operation on an object is associated with the `getc' access right. It is often useful to define an object-independent set of access rights associated with a general set of operations to which the specific operations on an object are mapped. For instance the `Read' access right may be associated with the `getc' and `read' operations on a terminal device.

The following is a possible set of general access rights, when the objects are restricted to files, devices, and directories: Read Write Append Insert Execute Delete Lock Modify Rights Set Owner Create Group Add Member

The last two rights allow creation of user groups (discussed later) and addition of members to it, respectively. The mapping from specific operations on devices and files to this general set is obvious. The mapping from specific operations on directories to the general set is not obvious, and will be discussed later.

The following is the definition of the access matrix for our example in terms of the general set of access rights:

l l l l l.
	/dev/console	~fred/prog.c	~fred/letter	/usr/ucb/vi
fred's P	RW	RW	RW	X
fred's Q	RW	RW	RW	X
jane's R	RW	R		X

In several systems, all processes running on behalf of the same user have the same access rights defined by the access rights of the user. In such systems, the rows of the table describe the access rights of users instead of processes. Thus the access matrix changes to:

l l l l l.
	/dev/console	~fred/prog.c	~fred/letter	/usr/ucb/vi
fred	RW	RW	RW	X
jane	RW	R		X
In the rest of the discussion we shall assume this form of an access matrix.

Whenever a process attempts to access an object, the operating system can refer to the access matrix to validate the access. Checking for privileges on each access might be an expensive operation. For files and other objects associated with `open' and `close' calls, the system may ask the process to indicate which operations it will invoke when it opens the object. At this point, the system checks if the process has the appropriate access rights. Later, when the process actually makes an access, the system needs to only check if it is one of the accesses indicated by the `open' call.

It is important to note that the access matrix is purely a logical construct and is seldom stored in the form described (why?). It is often divided into smaller portions. Here are two popular methods of doing so.


next up previous
Next: Capability Lists Up: Protection Previous: Protection



Prasun Dewan
Mon Nov 4 12:08:34 EST 1996