⇓   ⇐
  ←Part 6  Part 8→
by Goerge Stacknik

Last month, we began a discussion of the MPE file access security mechanism. We saw that it was made up of two parts: a proprietary part, originally designed for the older 16-bit models of the HP 3000, and an open part, originally designed for UNIX.

When the PA-RISC version of the HP 3000 was first brought to market in the mid-1980s, its only file security mechanism was the proprietary security matrix that had been brought over from MPE V. We discussed this matrix in some detail in Part 6 of this series. In this issue, we're going to turn our attention to the open side of MPE security.

POSIX File Permissions

Figure 1 shows the output of a POSIX shell command. We produced this display by logging on to an HP 3000, invoking the POSIX shell program, and typing the command ls l. If you log on to an HP 9000 (or virtually any other UNIX-based system) and type the ls l command, you'll see output similar to that shown in Figure 1.

Figure 1: The POSIX shell and file Permissions

In a broad sense, that is the point of open systems. Whether you are using the POSIX shell on an HP 3000 or the default POSIX shell program on an HP 9000 system, the ls l command does essentially the same thing. You have only to learn one command, and it will work on a wide variety of computer systems.

The ls l command displays a detailed list of the files and directories that reside in your current working directory. The command displays a full line of information about each object in the current working directory. The command is analogous to MPE's proprietary listfile ,2 command, shown in Figure 2. The listfile command is proprietary because it can be used only on HP 3000s, but it is used for essentially the same purpose as the ls command.

Figure 2: Using the :LISTFILE,2 Command to display file information

Note that the ls command displays something the listfile command does not. For each object it finds, the UNIX command displays file permissions, the bits that determine what kind of access users have to the file. To get the same information from MPE, you have to resort to the listfile ,4 command shown in Figure 3. In Part 6 of this series of articles, we dissected the MPE security matrix and explained the information shown in Figure 3 in detail. Now we're going to give the same treatment to the information displayed by ls l as shown in Figure 1.

Figure 3: Using the :LISTFILE,4 command to display security information

The ls l command displays one line of information about each object. Some of this information is fairly self-explanatory. For example, filenames appear in the rightmost column, preceded by the dates on which these files were created or last modified. The file size (in bytes) is displayed to the left of the filenames, and to the left of that is information about the file's owner.

The information on which we want to focus now is the collection of letters and dashes in the leftmost column. These are called permissions. There are 10 permission characters displayed with each file or directory.

The Directory Bit

The first of these characters, called the directory bit, simply tells us whether the object we're looking at is a directory or a file. A directory is displayed with a letter d in the first position. A file is displayed with a dash (--) in this position instead. In the example in Figure 1, both objects listed have a -- in this position, indicating they are files.

It's worth noting that on an HP 3000, an object displayed with the directory bit on (that is, displayed as a d) is not necessarily a POSIX directory. In Part 1 of this series, we saw that MPE file systems are divided up into accounts, which are further subdivided into groups. Groups can be further subdivided, using POSIX directories. POSIX directories can also be created inside other directories, attached to accounts, or even attached to the file system's root (like accounts).

If you are looking at an MPE file system through proprietary eyes (which is to say, using proprietary commands like listfile, listacct, and listgroup), you'll be able to see all of these structures, and differentiate among accounts, groups, and POSIX directories.

But UNIX systems don't have accounts and groups; these concepts are unique to MPE, or are proprietary. Therefore, if you look at your HP 3000 through open systems eyes, using commands like ls l, you'll see quite a different picture.

The POSIX shell is intended to be a pair of open systems eyes for the HP 3000. It is available for use by UNIX applications that have been ported to MPE. Since UNIX applications were designed to run on UNIX systems, these applications would not be able to work properly unless they could see UNIX file systems. The POSIX shell does its best to make your HP 3000 appear to be a UNIX system, so that UNIX applications that have been ported to MPE/iX can work properly.

One difference between MPE file systems and UNIX file systems is that there is only one kind of directory on UNIX. In a UNIX file system, directories are used to contain other objects. MPE, by contrast, supports four kinds of directorylike objects: accounts, groups, POSIX directories, and the root. The root (named / in accordance with UNIX conventions) is the directory containing all the accounts. It's at the top of the file system hierarchy.

In order to allow UNIX applications ported to the HP 3000 to behave as if the proprietary MPE file system were actually a UNIX file system, all accounts, groups, and POSIX directories (including the root) are mapped into the UNIX concept of directories. So, for example, if you use the ls l command in the POSIX shell to display the SYS account, it will appear to be a directory called /SYS. The first character in the permissions display will be a d.

Using only the POSIX shell, you cannot tell whether an object whose directory bit is displayed as a d is an MPE account such as SYS, an MPE group such as PUB.SYS, or a POSIX directory. They all appear to be directories to the POSIX shell.

In the output of the ls l command, the directory bit is followed by three groupings of file permissions. Each grouping is made up of three characters (see Figure 1). The first of these groupings tells what kinds of access have been granted to the owner of the file (or directory). The second group of three tells what kinds of access have been granted to users that share the same Group ID (GID) as the file. (If you're not familiar with the term Group ID, or GID, sit tight. We'll explain it in just a moment.) And the third grouping tells what kinds of access have been granted to anybody on the system.

File Owner's Permissions

Every file has an owner. Typically, the user who creates a file is that file's owner, although on UNIX systems, the owner of a file can be changed using the chown command.

The file owner's permissions tell what kinds of access are granted to the owner of this file. They are made up of three characters. The first character is either an r or a -. The second is either a w or a -. And the third is either an x or a -.

If the first character in the grouping is an r, then the owner has read access to the file or directory. If read access has been denied to the file's owner, then a dash (-) appears in its place. The second character in the grouping is a w or a -, depending on whether or not the owner of the file has been granted write access to the file. Similarly, the third character is either an x or a -, depending on whether or not the file's owner has execute access.

For example, in Figure 1, this first grouping of three characters reads rwx. This means that the file's owner has read access, write access, and execute access to this file.

Just as accounts and groups have been mapped into the open systems concept of directories, the MPE concept of a file's creator has been mapped into the UNIX concept of a file's owner. A little later in this article, we'll look in some detail at how this mapping works.

Group Permissions and GIDs

The next three characters make up the second grouping of permissions. Like the first grouping, they use the same r, w, x, or - pattern, but they apply to users that share the file's Group-ID, or GID.

One has to tread carefully when defining a term like Group ID to an MPE user. The meaning of the word group in UNIX-jargon is very different from its meaning in MPE-speak. As we learned in Part 1 of this series, MPE uses the word Group to denote a directorylike structure that houses a collection of files. For example, every account has a PUB group, and there may be a number of files in that group.

But in UNIX, the word group is used to denote a collection of users rather than files. Every UNIX user belongs to a group that is identified by a unique Group ID, or GID.

When files are created on UNIX systems, GIDs are assigned to the files as well. Typically a file is assigned the GID of the user who creates the file. To minimize the confusion from this unfortunate collision of terminology, we'll adopt a convention for the remainder of this series of articles. We will continue to use the word group to refer to groups in the MPE sense of the term (that is, as collections of files), and we'll use the term GID to refer to groups in the UNIX sense of the word (that is, as collections of users). So, every file in a UNIX file system has a GID. And every user on a UNIX system belongs to a GID.

The second grouping of permissions displayed by ls l tells whether or not users who happen to share the same GID as the file being displayed have read, write, or execute access to the file. In the example in Figure 1, this grouping of characters is r-x, indicating that users who share this file's GID have read and execute, but not write, access.

GIDs on MPE

In MPE terms, which users share the same GID as a file? Remember that UNIX uses the GID to refer to a collection of related users. On MPE the concept that is the closest analog to a GID is the account. We saw in Part 1 of this series that each MPE account includes a collection of related users. For example, if you create an account called STACHNIK, you can also define a collection of related users in that account: GEORGE.STACHNIK, JOE.STACHNIK, ED.STACHNIK, and so forth. In this sense, accounts are roughly analogous to GIDs.

Of course, there is much more to the concept of an MPE account than a collection of users. For example, we've seen in earlier articles in this series that accounts can be used to keep track of resource utilization. They can also contain directories, MPE groups, logon passwords, and other things as well. In this sense, an MPE account is a superset of a GID. But in the sense that an account contains a number of users, it can be thought of as being analogous to the UNIX concept of a GID.

When HP brought POSIX functionality to the HP 3000, the idea was to bring a set of UNIX-like APIs to MPE/iX in order to make it easier to port UNIX applications to MPE/iX. The POSIX standards are fairly clear about the requirement that users must be grouped together under a GID.

On UNIX systems (including HP-UX), each GID is identified by an integer value. But the POSIX standards do not specify that each GID has to be represented by a numeric value. In fact, they don't specify any particular datatype at all for representing a GID. They specify only that users have to be grouped together into GIDs. Therefore, the MPE engineers who originally designed the POSIX functionality decided to take advantage of this ambiguity in the standard. So, on MPE/iX, each GID is represented by an ASCII string, namely the account name.

For example, looking back at Figure 1, we see that we've used the ls l command to display information about two files: GEOFILE and GEOJOB. If we had issued this command on a UNIX system, the GIDs for each of these two files would have been displayed as integers. But the command shown in Figure 1 was entered in the POSIX shell on an HP 3000. Under MPE/iX, the GID of a file is represented by the name of the account of the user who created this file. So Figure 1 tells us that both of these files were created by users who were logged onto the STACHNIK account.

The ls l command also displays the name of the file owner. On UNIX systems, each user ID is represented internally by a numeric value called the User ID, or UID, for short. On MPE systems, the ASCII user name is used in place of the numeric UID. So looking at Figure 1 once again, we see that GEOFILE is owned by a user who logged on as STUDENT.POSIX while GEOJOB is owned by GEORGE.STACHNIK.

File Owners

The original 16-bit version of MPE did not allow a user to own (that is, create) a file in any account other than his own. This was true regardless of the capabilities a user had. So, for example, even MANAGER.SYS could create files only in the SYS account.

This rule was carried over to the early releases of the PA-RISC version of MPE. On MPE V systems, and on PA-RISC versions of MPE up to 4.0, displaying the creator of a file would get you only the 8-character user name. So, for example, a file in the SYS account created by MANAGER.SYS showed the creator's name as MANAGER. It was assumed that the creator had to be in the SYS account.

But when POSIX functionality was added to the HP 3000, the 8-character username was no longer enough, because POSIX allows you to change to the owner of a file. So, for example, on Version 5.0 of MPE/iX, a file's owner is displayed as shown in Figure 4, with both the user and account name shown.

Figure 4: Using :LISTFILE ,-3 to display the creator name.

Because this is a relatively recent change to the HP 3000 operating system, some MPE system managers are getting caught by surprise by this feature. They mistakenly believe that it's an unbreakable rule that all the files in account A must have creators that are also in account A.

But it's possible to change the owner of a file to a user who is in another account. For example, if you were logged on to an older version of MPE (pre-POSIX) as GEORGE.STACHNIK, you would be able to create files in the STACHNIK account (assuming you had the appropriate capabilities and group access). But you could not under any circumstances create files in the JONES account, the SYS account, or in any other account.

On 5.0 (and subsequent releases), however, the owner of a file or the GID of a file can be changed. One way to do this is by using the MPE :ALTFILE command. For example, consider the following command: 
:ALTFILE MYFILE.PUB.STACHNIK;OWNER=USERJONES
This command will change the ownership of the file MYFILE.PUB.STACHNIK. The file's owner will become a user in the JONES account (namely USER.JONES). Keep in mind that the proprietary MPE security matrix allows the creator (that is, owner) of a file to do things that other users cannot do, such as assign lockwords, change the file level security, and so forth. (See Part 6 for details.)

This is an important change, because it could allow a user in the JONES account to do things with a file in the STACHNIK account. Ordinarily, users in one account are denied access to files in other accounts. Fortunately, there are restrictions on the use of this command: Permissions for Anybody

We must not forget the third and final grouping of permissions. Once again, the rwx or - pattern is used, but this time it applies to any and all users on the system. In other words, if the r is displayed in this grouping, then every user on the system has read access to the file. In the example shown in Figure 1, read, write, and execute access have all been denied to all users. In other words, these files are in no sense public.

It's worth drawing a couple of distinctions between MPE and UNIX at this point. We saw in Part 6 that MPE differentiates between five types of access for files, and one for groups. As you can see at the bottom of Figure 3, MPE differentiates between read, write, append, lock, and execute access for files, and save access for groups, whereas UNIX distinguishes only among read, write, and execute access, making that do for both files and directories.

Also, MPE divides up the user community differently from UNIX. We saw last month that MPE distinguishes between six clubs of users: ANY, CR, GU, AC, AL, and GL. In Figure 3, we see examples of all of these, with the exception of CR.

By comparison, UNIX differentiates only among three such clubs. The first club is made up of a single user: the file's owner. The second is made up of users who share the file's GID. Finally, there is the all club, which admits anybody who is able to log on.

I wanted to make these distinctions between MPE and UNIX, not out of some misguided effort to try to prove that one operating system is in any sense superior to the other. Operating systems are what they are, and comparisons between them are usually a waste of time.

Rather, I wanted to draw attention to the MPE lab's amazing work in bringing the two operating systems together. When POSIX functionality was brought to MPE in Release 4.5 some years ago, the lab was faced with the daunting challenge of making the MPE file system look like a UNIX file system when viewed through the eyes of any UNIX-based application ported to MPE. The hard part of implementing POSIX on the HP 3000 was not bringing the POSIX application program interfaces (APIs) to the HP 3000. The difficult part was implementing all the assumptions those APIs make about the system (such as file-naming conventions, security mechanisms, and file system architecture).

MPE architects took advantage of some similarities between the UNIX and MPE security systems. First, there's an obvious parallel between the MPE concept of a file creator and the UNIX concept of a file owner. Both represent an individual user who is singled out for special consideration by the security system. The only difference is that file owners can be changed. By enhancing MPE to allow the system manager to do the same thing, the architects brought together the two ideas.

In this way, the MPE architects were able to make the 3000's file system security matrix look sufficiently like UNIX file system security so that it was much easier to port UNIX applications to the HP 3000. For example, suppose you are the owner of a file and you have READ, WRITE, APPEND, LOCK, and EXECUTE access to the file, as shown in Figure 3. If you were to enter the POSIX shell and use the ls l command to display the permissions of the file (as we did in Figure 1), you would find that the file's owner had full rwx access to the file.

You may be wondering what happened to APPEND and LOCK access? Of course, you still have them. But these types of access are meaningless to UNIX applications. From a security perspective, the UNIX application program interfaces do not differentiate between appending data to the end of a file and replacing existing data. That is, if a UNIX application wants to APPEND records to the end of a file, it must have WRITE access to the file. If it wants to replace existing records, it still needs WRITE access. Similarly, LOCK access is meaningless to UNIX applications because UNIX doesn't have a file-locking mechanism like the one MPE uses.

When you use the POSIX ls l command to display file owner permissions, what you're really seeing is whether the file's creator has READ, WRITE, and LOCK access to the file.

If this article is your first exposure to the working of the UNIX file system security, you might be wondering how such a simple system can be used to support complex commercial applications. The answer is that it can't. The UNIX file security mechanism was extended in the 1990s to give it considerably more granularity than that allowed by the permission bits we've discussed in this article. The extension took the form of Access Control Lists. An analogous enhancement was brought to the MPE/iX file system around the time of the 4.0 release, called Access Control Definitions. We'll explore these in Part 8 of this series of articles.

George Stachnik, the director of Hewlett-Packard's Technology Closeup series of television broadcasts, holds the title of Chief of Customer Communications. He works at Hewlett-Packard's campus in Cupertino, California.
  ←Part 6  Part 8→
⇑   ⇐   [3khat]3kRanger   [3khat]3kMail   Updated