Notes on Some Similarities and Differences between Unix and Multics

By MIT – selfmade, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=88261340

Background

It is fairly well known that most modern operating systems are more-or-less derived from Unix. What is not so well known is that many concepts in Unix, in turn, are derived from an earlier operating system known as Multics. Multics was started as a joint research project by General Electric Company (which was in the computer business at one time), the Massachusetts Institute of Technology, and Bell Telephone Laboratories, the research arm of AT&T, back when AT&T was simply known as “the” telephone company,” or “Ma Bell”.

Eventually Bell Labs withdrew from the Multics project, and not long after that Ken Thompson, one of the Multics participants from Bell Labs, invented Unix (whose name is a deliberate play on “Multics”).

Because Unix has been such a major influence on operating-system design, it got me to wondering how much of Unix was in turn influenced by Multics. At various times I read various Multics articles and documentation and made notes in a simple text file. (See the references at the end of this paper for my sources.) What follows are those notes. I hope you will forgive the somewhat telegraphic style as well as the disorganized order of information; these are, after all, notes.

Notes on the Similarities and Differences between Unix and Multics

  • Multics had both “hard” links, referred to as “branches” and symbolic links, known in Multics simply as “links”. However, in Multics there may be only one “branch” to a given file, whereas in Unix there maybe be multiple “hard links” to a single file. (4)
  • Multics has standard input (“user_input” in Multics), standard output (“user_output”), standard error (“error_output”). (1)
  • Each user has one process that is created when they log in. When a new program is started, it runs in the same process. (1)
  • File permissions are handled by ACLs (Access Control Lists). (1) This is more general than the user/group/other mechanism used in Unix.
  • Subjects are identified via a three-part access identifier, where each part is separated from the others by a “.”:
    • person ID (cf. user in Unix),
    • project group (cf. group in Unix), and
    • instance tag, which has no analog in Unix, and identifies the type of access to the system:

a – interactive process (logged in via a terminal)
m – absentee processes
p – proxy
z – daemon
o – system operator

  • The word “daemon” is carried over into Unix as a conceptual term for a service process that runs in the background with no UI.
  • An ACL is associated with each of these three values (user, group, instance).
  • The permissions that can be specified in an ACL are:

r – read
w – write
e – execute or executive depending on the object type
s – status
m – modify
a – append
d – delete
o – own
w – wakeup
c – chairman or control depending on the object type
n – null
d – daemon

Not all permissions are applicable to a particular type of object.

The object types are:

segments
directories
multi-segment files
mailboxes

  • ACLs can be used to reproduce the permissions of a Unix file, but there are many additional possibilities that are not expressible in Unix. Here are some examples:

ls This command lists information about segments.

Segments = 2, Lengths = 1.

r w 1 Glenn.value
r w 0 card_input.acs

r 16:33 0.030 6

la Glenn.value This command lists ACLs
rw Glenn.SysEng.*
rw .SysDaemon.

r 17:10 0.067 1

la card_input.acs
rw Glenn.SysEng.*
rw Initializer.SysDaemon.*
re reader..
rw .SysDaemon.

r 17:10 0.046 0

(In the above examples, “*” is used as a wild-card, meaning “any
value”.)

  • The system evaluates ACLs, not necessarily in the order they are written, but rather based on whether and where wild-card components are specified.
  • There doesn’t appear to be a concept of “root user” that would effectively bypass permission checking.
  • The above description of security is what is generally called “discretionary access control” (DAC). Multics also has a system of what is today called “mandatory access control” (MAC), and what Multics calls “Access Isolation Mechanism” (AIM). MAC security is generally lacking from standard Unix.
  • Multics uses a “ring mechanism” for memory protection.(1) This is comparable to the four-ring mechanism used by the Intel X86 architecture. However in Multics, there are seven rings (presumably enforced by the hardware), and some of those rings can be used by applications to separate more-privileged from less-privileged access. Since files are generally memory-mapped as segments, this mechanism extends to files as well.
  • There is a hierarchy of directories as in Unix. Individual elements in a pathname are separated by “>” in Multics (1) or “:” (4), rather than “/” as in Unix and its derivatives.
  • In Multics is there the concept of a “working directory” which is conceptually identical to the “current working directory” in Unix. (4)
  • Multics has a concept of “logical volumes” which appears to be the same as logical volumes in modern volume managers. Note that Unix does not inherently contains logical volumes or volume managers. VERITAS was probably the first company to make a commercial volume manager for Unix (specifically Solaris initially, and later HP-UX, AIX, and Linux). Linux usually includes volume-manager software.
  • The reference (4) has an extensive discussion of backup and storage hierarchy. None of this can be found in the file-system itself within Unix, at least not within the kernel; rather backups and storage organization can be made available via user-mode programs. Reference(4) does not draw the distinction between the kernel vs. user-mode programs, so it is possible that some of the backup support is done from user-mode programs, as it is in Unix.

Other Multics features carried over to Unix: (2)

  • An explicit notion of a process as a locus of control
  • A tree-structured file system
  • Simple representation of text files
  • Generalized access to devices.
  • A shell as a user-mode OS user interface (2 and 3)

“The idea of implementing ‘system’ code and general user primitives
comes directly from MULTICS.” — Ken Thompson, quoted in (2)

References:

(1) Multics System Programming Manual https://multicians.org/mspmtoc.html

(2) “On the Evolution of Unix and the Automation of Telephone Support Operations (i.e. of Computer Automation)” by Ronda Hauben
http://textfiles.com/programming/25th_ann.uni

(3) “The Origin of the Shell” https://www.multicians.org/shell.html

(4) “A General-Purpose File System for Secondary Storage”, by R. C. Dailey, and P. G. Neumann https://www.multicians.org/fjcc4.html

There is another edition of the Programmer’s Reference at https://www.multicians.org/ag91toc.html

In general https://www.multicians.org is a rich source of material about Multics.

Thanks, also to Peter Neumann, one of the Multics file-system developers and co-author of reference (4) for reading these notes and correcting some of my misunderstandings.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.