Windows NT systems are moving into environments where UNIX platforms have traditionally reigned. Companies that add NT networks to their legacy UNIX installations usually need to share files between the two platforms. Because NT and UNIX use different file systems--NTFS for NT and NFS for UNIX--file sharing between NT and UNIX systems usually requires running a product on the NT system that converts NTFS-format files to NFS. In this article, I explain NFS and NTFS file and directory access permissions and how NFS file sharing works via NT NFS products. (The sidebar, "File Name Mapping," page 68, warns about the effect of naming conventions.)
NFS Permissions
NFS, which Sun Microsystems originally developed, provides a file-sharing
standard that lets users on UNIX workstations access centralized files on a UNIX
server or share files with other UNIX workstations. All major UNIX operating
systems have built-in NFS file-sharing capabilities.
For file and directory permissions, NFS uses a simple scheme that's somewhat limiting compared to NTFS permissions. For example, in NTFS, each file and directory has at least one access control list (ACL) entry that defines a user's or group's access to the file or directory. With liberal use of ACL entries, you can tailor access to one file for your entire user community, as Screen 1 shows. UNIX administrators don't have this level of control. Rather than offer a full set of ACLs that let you individually specify user and group permissions, UNIX's NFS provides three broad categories of access permissions: user, group, and other (or world) access permissions (this approach is different from NTFS, in which files have only one owner). UNIX systems also store an owner and group identifier (i.e., an entry) for each file or directory in the file system. These identifiers work with the three access permissions to determine a user's level of access.
User permissions, in the form of a numeric owner identifiers (or user IDs--UIDs), define access for a file's owner. When a user saves a file in NFS, the UNIX system automatically saves the UID in the file's directory entry, similar to a directory entry for a file under the NTFS or FAT file system. Later, if another user with the same UID attempts to access the file, that user receives the owner's access permissions for the file.
Group permissions, also in the form of a numeric group identifier, define access for all users who belong to a group. As with the owner identifier, when a user saves a file, UNIX automatically saves the user's current group ID (GID) as the group identifier in the file's directory entry. When another user with the same group identifier attempts to access the file, the user receives the group's permissions.
Note that group permissions are subordinate to owner permissions. For example, if you are both a file's owner and a member of the group the file belongs to, the owner permissions take precedence.
The third category of access permissions is other, or world, permissions. They define access for everyone who isn't either a file owner or a member of a group with access to a file.
Read, Write, and Execute
Each permissions type has three access flags, read (r), write
(w), and execute (x). You can set or unset a flag to control access to
files.
The read flag lets you view the contents of any file or directory in a UNIX file system. The write flag lets you update files. Update operations include editing, deleting, or renaming a file. UNIX does not differentiate among these functions--the write access flag grants all update privileges.
Ordinarily, anyone with write access to a file also has read access. However, it's possible to grant a user write access but not read access. This capability lets a user delete and rename a file and removes a user's ability to edit a file. Why? Because if you don't have read access, you can't read the file into an editor to edit it.
The final access flag, execute, determines whether you can execute a file. Usually, this flag is set on executable programs only; it lets administrators control who can and cannot execute programs.
Listing 1 contains a sample UNIX directory listing showing how file permissions are set. In this example, the first column represents the file permissions, the third column holds the owner's name (most people know their logon name rather than their UID), the fourth column represents the group name (again, rather than the numeric value), and the remaining three columns show the file size, creation date and time, and file name.
The first column, file permissions, contains one directory indicator (the first indicator) and slots for nine different permission flags. When you create a subdirectory, UNIX places a "d" in the first slot. This letter lets you know the entry is for a subdirectory. The remaining nine slots represent the read, write, and execute flags for the owner, group, and other (world) permissions, respectively.
In Listing 1, file deg.doc contains read and write permissions in the second and third slots. These flags grant read and write permissions for the file's owner, which is the user with logon ID mpd. File msg.txt contains similar owner file permissions and also includes read permissions for both the group (staff) and the rest of the world. Finally, the file glsystem is an executable program that the owner, group, and other (world) can execute, as indicated by the execute permission.
UNIX also has the equivalent of NTFS's No Access and Full Control permissions. You simulate No Access by merely not granting any permissions to the owner, group, or other (world) category. (Of course, systems administrators with super user--SU--access can still access any file, regardless of the file's permissions.) The absence of permissions for certain users means that those users have no access to the file or directory that has no permissions defined. You can simulate NTFS's Full Control by granting all three permissions--read, write, and execute. However, unlike with NTFS's Full Control, if you grant full control to nonowners (group and other) under UNIX, they do not have the ability to modify permissions--only a systems administrator or owner can modify a file's access permissions.
Permission Mapping
Although NT and UNIX file permissions are relatively simple, the process by
which NFS software maps file and directory access permissions between NTFS and
NFS can be more complex than choreographing a Broadway musical. Fortunately,
this process is transparent to users. The three NT NFS products I've
used--Hummingbird Communications's NFS Maestro, NetManage's ChameleonNFS/X, and
XLink Technologies's Omni-NFS For Windows NT--handle permission mapping the same
way.
An NT system can play one of two roles in an NFS environment. The NT system can act as an NFS client, accessing remote NFSs (UNIX) as if they were local NTFSs. Or, an NT system can act as an NFS server, letting UNIX systems access NTFSs. Usually, the permission mappings are the same regardless of the access direction, especially if you use one vendor's product to perform both client and server functions (which is how NFS products are generally sold).
When you access a file, either from a UNIX machine to an NFS server running on NT or from an NT NFS client to a UNIX machine, the NFS software must perform the permission-mapping process. In the first part of this process, authentication, the NFS software attempts to determine the user's identity. When a user accesses a remote UNIX file system from NT, the NFS subsystem determines the UID and GID on the UNIX system with the user's NT username and primary group identifier. When a user accesses an NTFS from a UNIX system (through an NFS server on an NT system), the NFS server maps the user's UNIX UID and GID to an NT logon name and group name.
When an NT user accesses a UNIX file system via NFS, the authentication process may use a special daemon (PCNFSD) on the UNIX host that attempts to translate the NT logon ID to a UNIX counterpart. If the daemon can't translate the logon ID, the NFS product uses a UID/GID translation table instead to automatically perform the translation (most NT NFS products maintain such a table; you usually have to set it up before using the NFS product). When a UNIX user accesses a file on an NT system, the NFS server product uses the UID/GID table, if the server product has one, to handle the translation. In either case, if no translation is available, the NFS software either assigns an ID or ends the connection attempt. Screen 2 shows how permissions are mapped to a UNIX system via NFS.
Determining the proper UID and GID or NT username and group combination is an important part of file permission mapping. Because UNIX does not maintain extensive ACLs for each file, proper mapping of the UID and GID to their NT counterparts is critical to ensure that users can access the files they need. For example, if your GID is not set correctly, NFS might assign you different access permissions from the group access permissions you require.
When a UNIX user creates a file on an NTFS via an NFS server, the NFS product often uses NTFS's Special Access permission flags rather than the standard NTFS file permissions to determine individual access levels. These flags more readily map to their UNIX counterparts because they include read, write, and execute flags (and some others), thus allowing a one-to-one translation. For example, if the read flag is set for a file on the UNIX system, the NT NFS software usually sets the NTFS Special Access read flag. When a new file is created on the NT system, the NFS software usually creates an ACL for the file that uses Special Access flags to set the file's permission for the owner, group, or other (world). NFS can affect two other Special Access flags, depending on the NFS product you use. Because UNIX's write permission implies that you have delete permission, the presence of this flag in a UNIX file can set the Delete Special Access flag. Also, because a file's owner can change access permissions, some NFS products set the Change Permissions Special Access flag for the owner.
User and Group Mapping
The three types of UNIX access permissions (user, group, and other) directly
map to three ACL entries for the file on the NTFS. An ACL entry for the owner
contains the user permissions, an entry for the group NFS determines the file
belongs to contains the group permissions, and finally the group Everyone
receives other permissions. The read, write, and execute special file permission
flags are set appropriately for each ACL.
Mapping users and groups is especially tricky when you access files in an NTFS from a UNIX system via an NFS server. The complexity arises from NTFS's ability to maintain many ACL entries for individual users and groups. In some cases, there may be several individual user ACL entries and no group ACL entries. In other cases, a file owner may not have an individual ACL entry. Or, there may be several group entries but no individual or owner entry. Generally, in such cases the NFS server product relies heavily on the UID/GID translation table to properly determine the correct access permissions for a file.
How these access permissions take effect for UNIX users depends on the NFS server product. For example, take a situation often found in a user's home directory on an NTFS. The user creates a new directory for FrontPage 97. The user, who is the file's owner, may use File Manager to modify NTFS security permissions for the directory and the files in it. As part of the ACLs the user specifies, the user may grant high access to several other users or to several groups.
Mapping these permissions for a UNIX user who wants to access the directory requires the NT server to perform a large amount of logic. The server attempts to translate the UNIX user's UID/GID combination into an NT counterpart and then determines the individual's access by examining the ACL entries for the files and directories the user is trying to access. Once the NFS software finds the correct ACL entry to use, the NFS server grants the appropriate access. If no match is found, the user cannot access the directory and files.
Establishing file permissions between NTFS and UNIX over NFS is hardly an exact science. Various vendors implement their client and server translation schemes differently. When choosing an NT NFS product, you need to understand how the product performs permission mapping. Two important issues are the product's use of special file and directory permissions in place of NTFS's default permissions and the methods the NFS product uses to perform UID and GID mapping between NT users and groups and their UNIX counterparts. When you fully understand these issues, sharing files with NFS becomes second nature.
| Contact Info |
|
ChameleonNFS/X NetManage * 408-973-7171 Web: http://www.netmanage.com NFS Maestro
Omni-NFS For Windows NT
|
- In Michael P. Deignan's article "Sharing Files Between NT and UNIX Systems," we inadvertently omitted the following products and vendors from the Contact Info box: Disk Access and DiskShare by Intergraph (http://www.intergraph.com) Reflection NFS Connection by WRQ (http://www.wrq.com)
