Unix & Multics

[Ken Raeburn]

>Unix is based on Multics, right?  Well, what did Multics have that
>Unix doesn't have, and what does Unix have that Multics didn't?

I'd like to add a few things to what Rex Sanders
(RSanders at USGS2-Multics) said on the issue, although they're a bit
one-sided.  I've had more experience with Multics.

...  Temporary files have been one of the issues buzzing around the net
lately.  Multics eliminates some of the problems of temporary files that
have been discussed.  Since all of Multics memory is located in the file
hierarchy, each user's process is allocated a "process directory" in
which various things such as stacks and temporary files are kept.  The
directory is inaccessible to anyone but yourself or a sufficiently
priveleged system maintainer.

...  Access control is much more complicated on Multics than on Unix,
giving it some advantages and disadvantages.  Each user in each login
session has an identifier associated with him that tells his name, the
project (sort of similar to groups) that he is logged in under, and
whether he is logged in interactively, as an absentee job (sort of like
a batch job or a Unix "at" job), or a daemon (more explanation on that
later).  Access is controlled by any or all of these, listed in an
Access Control List.  ACLs can get extremely long (I'm not sure exactly
how long, I've never reached the limit), and therefore can be extremely
precise about who gets what access.  So you can have yourself, Joe,
people on the SysAdmin project, and Larry's absentee jobs able to write
to a file, prevent Curly from even reading it, and let everyone else
read it at will, simply by setting up the ACL correctly -- which is very
easy to do.

Multics does not have "setuid" or "setgid" programs.  Instead, it uses
ring protection.  Some processors have two states, a user state and a
supervisor state.  The hardware Multics runs on goes beyond this.  A
user's process can be running in any ring from 0 to 7.  Users start out
in ring 4 generally, and can call "gates" to execute one of a limited
set of subroutines in an inner (more priveleged) ring, after which the
process returns to the outer ring.  This leads to segments called
"mailboxes" being protected so that they can be manipulated in ring 1
only, with a number of gate entrypoints to read data out or put it in in
particular formats.  Mail on Multics is secure.  You cannot fake a
message from another user without going through the network SMTP
handler, which is in itself insecure.  (Just telnet to your machine's
port number 25 if you're on the arpanet, and talk to your own mailer.
If you know what to do, you can easily fake it out.)

There is also an access-class attribute, but I don't think anyone
outside of the DOD uses it.

...  A "process" in Multics is a lot more involved than in Unix.  There
is no facility for creating a new process of your own or anything like
that.  Every program that gets run must be run in a process with a
userid, project, etc.  There is a particular type of process, called a
daemon, which gets logged in with no terminal attachment.  It's purpose
is to run the various programs and servers that you might find in an
"/etc/rc" file.  This includes any network implementation,
unfortuantely.  Here at MIT-MULTICS, any TCP connections have to be
handled through a daemon (our name for it is "Internet").  This causes
problems sometimes.

The "PATH" idea is used more in Multics.  There are "search rules" used
to find programs and subroutines.  There are also "search paths" for
finding info files, search paths for finding include files, etc.  In
Unix, if you want to add a directory to be searched by "man", you need a
revised program.  (**BTW, if anyone has a program that does something
similar on Unix, please send it to me.  We have a need for something
like this here at MIT with some of the software development groups, each
having directories for binaries, info, etc, separate from all the
others.**)

Unix does have some things which I would like to see in Multics.  One of
these is relatively easy multi-tasking.  There is some makeshift
software to do this on Multics, but it doesn't quite cut it.  (Though
there is more in development that we haven't got here at MIT yet.)
Another is the ability to temporarily give a user the priveleges of
another (via "su"), although that's not such a big issue.


I have not had much experience with either system (about a year with
both), but so far, I have found Multics easier to use.  The user
interface, although there's quite a bit of it to get used to, and many
people I know don't like it, seems more reasonable to be.  Which makes
more sense, "accept_messages", or "biff y"?  Also, error messages are a
lot more helpful.  A "linkage_error referencing foo_|bar" is a lot
easier to understand and track down (once you understand the format)
than "Segmentation fault (core dumped)", is it not?  (Yes, I know you
could try to get some info out of the core image, but can you resume its
execution afterwards?) And while PL/1 may be rather wordy, I can read it
an awful lot easier than some of the C code I've seen (no flames,
please).


--        Ken Raeburn
          (Raeburn.PDO at MIT-MULTICS)

----------------------------------------------------------------
-                                                              -
-   The opinions above are mine, and might be totally          -
-   unrelated to those of anyone you will ever meet.           -
-                                                              -
----------------------------------------------------------------