5.9.1 Dual Universes

Throughout this book, you will find that we often mention how the behavior of a command or action may be different if your version of UNIX is derived from BSD or AT&T UNIX. These differences are not so great as they once were, as SVR4 is the result of a merger of the majority of these two lines into one system.

However, in years gone by, the two systems were separate. This presented an interesting puzzle for some vendors who wanted to cater to both markets. Thus, someone came up with the idea of universes. The idea itself was fairly simple. Create a per-process "switch" in memory that would be set to either BSD or AT&T. The behavior of various system calls might depend on the value of the switch. Furthermore, certain special directories could be set up so that the directory you'd actually see would depend on the switch setting. Thus, you could have /usr/bin full of user programs, but it would really be two /usr/bin directories  - one of BSD and one of AT&T!

Several companies adopted variations of the universe concept, including Pyramid, Apollo, Masccomp, and Sequent. In some of these systems, the switch from one environment to another was almost seamless, from the user's point of view. However, the scheme had several problems:

• It took more disk space for standard configuration. The standard system needed two copies of libraries, man pages, commands, and more.

• In most environments all the users stayed in a single universe. Shops were seldom heterogeneous in environment, so users preferred to stay with a familiar interface on everything they did.

• Patching and maintaining the programs took more than twice the effort because they required that users consider interactions between software in each universe.

• System administration was often a nightmare. You didn't necessarily know where all your commands were; you might need to worry about configuring two different UUCP systems; you couldn't always tell which version of a program was spawning jobs; and so on.

Also important to all of this was the problem of security. Often, clever manipulation of interactions between programs in the two universes could be used to break security. Additionally, a bug discovered in one universe was often mirrored in the software of the other, but usually only one got fixed (at first).

Eventually, everyone supporting a dual-universe system switched back to a single version of UNIX. Nevertheless, Solaris perpetuates some of these problems. For example, Solaris has two versions of the ls command, one in /usr/bin/ls, one in /usr/ucb/ls. It also has two versions of head, more, ln, ps, and many other commands. Thus, you need to check your search path carefully to know which version of a command you may be using.

5.9.2 Context-Dependent Files

To support diskless workstations, Hewlett-Packard developed a system called Context Dependent Files, or CDF. CDFS allow for multiple configurations to reside on a single computer. The goal of CDFS was to allow one master server to maintain multiple filesystems that will be viewed differently by different clients. This mechanism thus allows a single server to support a group of heterogeneous clients.

A CDF is basically a hidden directory whose contents are matched against the current context. HP explains it as follows:[28]

[28] From the HP man page for CDF.

A CDF is implemented as a special kind of directory, marked by a bit in its mode (see chmod). The name of the CDF is the name of the directory; the contents of the directory are files with names that are expected to match one part of a process context. When such a directory is encountered during a pathname search, the names of the files in the directory are compared with each string in the process's context, in the order in which the strings appear in the context. The first match is taken to be the desired file. The name of the directory thus refers to one of the files within it, and the directory itself is normally invisible to the user. Hence, the directory is called a hidden directory.

When a process with a context that does not match any filenames in the hidden directory attempts to access a file by the pathname of the hidden directory, the reference is unresolved; no file with that pathname appears to exist...

A hidden directory itself can be accessed explicitly, overriding the normal selection according to context, by appending the character `+' to the directory's file name.

Thus, HP-UX had directories that were invisible unless they contained a file that matched the running processes' current context.

CDFS are a powerful abstraction, but they were sometimes exploited by attackers. For example, the following sequence of commands will create a CDF directory:

% mkdir ./Hidden 
% chmod +H ./Hidden

This resulted in a directory that was normally invisible unless the -H option was used with the ls or find commands. A clever attacker could store all kinds of tools, stolen data files, and other interesting bits in such a directory. If the system administrator was not in the habit or was not trained to use the ls command with the -H option, then the directory might go unnoticed. The cracker could also find an existing CDF and store things in among the other files! As long as none of the filenames matched an existing context, they would probably never be noticed.

Even worse, tools the system administrator obtained for checking the system's overall security might not be aware of the -H flag, and not invoke it.

HP has dropped support for CDFS and moved to the use of NFS in version 10 of HP-UX, released in the spring of 1995. If you are not using version 10 or later, you should be sure to use the -H option on all ls and find commands!