Cover V05, I01
Article
Table 1
Table 2

jan96.tar


Handling Permissions between UNIX and NetWare

Emmett Dulaney

Connecting UNIX clients to a Novell NetWare network has become a routine responsibility for UNIX system administrators -- so much so that there's now abundant documentation on how to make make these two NOSs talk to each other. What has not been well documented is the problems encountered once they do. This article examines one of the most confusing of the issues -- file permissions\rights. Rights in UNIX are known as permissions, and they dictate what a user can do with a file on the basis of whether the user is the owner of the file, a member of the owner's group, or someone other. In the world of NetWare, permissions are known as rights, and the only item of concern is whether a user is a "trustee" of the file or not.

Permissions in UNIX

There are only three permissions available in UNIX:

r -- the right to read the contents of a file

w -- the right to write to a file

x -- the right to execute a file

These permissions are replicated three times -- once for the owner, once for the owner's group, and a third time for everyone else. Thus a permission set of

-rw-r--r--

means that the owner of the file can read and write to the file, while members of the owner's group can only read the file, and all other users can only read the file, as well.

Rights in NetWare

Rights in NetWare apply to both files and directories and restrict, or allow, users to do something with the entity. For example, the "read" right allows a user to read the contents of a file. Auser who doesn't have that right for a particular file cannot read the file.

Rights to a file or directory can be granted to an individual user or to a group, in which case all members of the group acquire the right. If you want all users to have similar rights to an entity, you merely grant those rights to the EVERYONE group, since all users are members of that group.

The rights that can be granted are:

  • Access Control
  • Create
  • Erase
  • File Scan
  • Modify
  • Read
  • Supervisory
  • Write

    Access Control allows a user to modify the rights to a file\directory and change the Inherited Rights Mask (IRM), discussed later. Giving a user Access Control rights, and then withholding any other rights is mindless. Users with Access Control rights can change the other rights assignments.. The only one they cannot assign themselves is Supervisory.

    Create within a directory allows a user to make a new file. Create for a file allows the user to recover that file with a utility called Salvage after it has been deleted.

    Erase gives the user the necessary permissions to delete the file. For a directory, it allows the user to delete files, subdirectories, and even the directory itself.

    File Scan on a directory allows a user to see the files within the directory. Without this right, the user sees only an empty directory. File Scan on a file specifically gives permission to see that file in a listing.

    Modify on a directory allows the changing of file attributes, as well as file and subdirectory names. On a file, Modify implicitly grants the rights for that file. In other words, you can remove Modify from the directory, but leave it in place on one file, so that only that file within that directory can be modified. Modify works only on names and attributes. In order to change or alter contents of a file, the user also needs Write permissions.

    Read is the right to open files and look at what is in them. This is also the right that a user must have in order to be able to execute an executable program.

    Supervisory gives all rights to the user. This allows the user to get past all other restrictions and avoid Inherited Rights Masks (discussed in the next section).

    Write allows a user to open a file and modify its contents.

    Inherited Rights Masks

    By default, when rights are placed on a directory, those same rights are inherited by every file and subdirectory beneath it. Therefore, if you create a directory called projects and assign rwc rights to EVERYONE, then when you create a subdirectory of projects called housing, all users on the system have rwc rights to the new subdirectory and the files contained within. Likewise, if a subdirectory of housing were created called redlight, the same rights would carry on down -- these are inherited rights.

    An Inherited Rights Mask simply sits in one of the subdirectories beneath the main directory and filters out (masks) rights that you do not want to be inherited. If housing had a mask of C, then the effective rights in that directory for EVERYONE would be rw.

    The most important thing to remember about IRMs is that they are masks, or filters. They cannot grant rights, but can only prevent rights you already have from filtering down. For example, if the mask in housing were cm, the effective rights for EVERYONE would be rw. The fact that all users did not have m in the first place is irrevelent.

    The only right that cannot be filtered out by an IRM is Supervisory. Having the Supervisory right allows you to completely circumvent any IRM and effectively gives you all rights.

    Combining NetWare and UNIX

    Looking at the permissions in UNIX and the rights in NetWare, it is easy to see that they do not match up one-for-one. Additional processes are required to provide translation between the two operating systems.

    Using UNIXWare as an example, on the NetWare server, there must be a process called nuc.nlm (NetWare Loadable Module) running. nuc.nlm's primary purpose is to provide for the proper translation of UNIX permissions to NetWare trustee rights.

    When a UNIX user issues a chmod command, nuc.nlm maps the changes to a rights call in NetWare. The translation of UNIX permissions to NetWare trustee rights is not precise. Table 1 shows the results when a UNIX user issues the chmod command on a file located on a NetWare server. The first column is the numerical permissions issued with chmod. The second column is what you would normally expect to result from the command; the third column lists the UNIX permissions the command actually effects; and the fourth column is the map to NetWare rights. The result is different from what it would be in the UNIX world in actual permissions, as well as in the underlying rights assigned.

    nuc.nlm provides the translation between the UNIX permission mask and NetWare trustee rights. Note that a command to chmod to 700, which one would think should be

    -rwx------

    in reality becomes

    -rwxrw-rw-

    because of the way the mapping is performed. Likewise, trying to chmod to 500 should result in a file permission of:

    -r-x------

    but instead generates:

    -rwxrw-rw-

    In short, if you have 7 or 6 in the chmod command, the result includes rwx. If you have 5 or 4, the Write right is removed. If you have a 3 or 2, the Read right is removed. If you have a 1 or 0, the Read and Write rights are removed. In all cases, the Supervisor right is granted, which results in all rights in any case.

    On directories, chmod operates somewhat differently. If you have a 5, 4, 1, or 0 in the permission, the Create right is removed. Otherwise, the user gains full rights. Again, the Supervisor right is assigned, which gives the user full effective rights. This is shown in Table 2 in four columns -- the numerical chmod command, what you would expect, and what you get on the UNIX machine and NetWare server.

    Not only is the result not what you expected, but what you get can make for interesting problems when you are trying to establish permissions and rights. Be mindful of security holes you may open in this manner when you connect operating systems. The only solution -- short of not connecting operating systems at all -- is to pay close attention to the effects on rights of such connections and keep a watchful eye on key files.

    References

    Steen, William. Managing the NetWare 3.x Server. Indianapolis, IN: New Riders Publishing, 1995. ISBN: 1-56205-514-3

    Steen, William. NetWare Security. Indianapolis, IN: New Riders Publishing, Forthcoming (January 1996). ISBN: 1-56205-545-3 n

    About the Author

    Emmett Dulaney is a publishing manager for New Riders Publishing and co-author of Inside Unix and Inside TCP/IP. He can be reached on CompuServe at 74507,3713.


     



  •