A Windows NT Fileserver with UNIX Clients

Al Koscielny

The UNIX operating system is known for its robustness as a database server and typically serves UNIX or Windows clients. Windows NT is designed for client/server and is very compatible with Windows clients. This article focuses on another permutation, using a Windows NT server as a file server for UNIX clients.

Our current software development project is a cross-platform application that runs both on Windows and X Window. The development environment has a local area network with Pentiums running Windows NT or Windows 95 and Sun workstations with Solaris 2.4. The cost of PCs with Windows-based software is significantly lower than for workstations running UNIX, so the Windows platforms predominate. Windows NT Server 3.51 running on a Pentium 90 is set up as the primary domain controller and is a fileserver for some large test datasets. The fileserver has the SourceSafe revision control product on a shared directory. For convenience during coding and testing, these shared directories are remotely mounted on the Sun workstations. Although the test dataset could be recreated fairly easily, the source code files under revision control must be protected from inadvertent modification or deletion.

Windows NT departed radically from the primitive file protection mechanisms in DOS and Windows for Workgoups. It supports varying permissions for user accounts and user groups along with a variety of shared directory permissions. Although NetBIOS and the NetBUI protocol have been the basis of Microsoft's networking, Windows NT and 95 offer much more support for TCP/IP. However, Windows NT does not share filesystems using NFS as do the UNIX platforms. We installed an NFS server for Windows NT (Beame and Whiteside's BW Connect) on the fileserver to export (or share in Windows terminology) filesystems. Solaris clients can mount these filesystems at boot time using an entry in the /etc/vfstab file. Or, the clients can mount them at a later time using mount -t nfs server:/filesystem /mount-point. Restrictions to a filesystem's access, such as read only, can be added when it is mounted. However, for software revision control, we need full read-write-delete access. See Networking Personal Computers with TCP/IP by Hunt for detailed information on networking with Windows 95 and NT.

File Security

File access under the UNIX operating system depends on the user and group concepts. A user has a unique login name and a user ID number (UID). A user can be a member of one or more groups defined using a group ID number (GID) in the /etc/group file, and the primary group is set in /etc/passwd. When a file is created, its group is the owner's current group, which could be different from the primary group, depending on the flavor of UNIX. User and group ownership can be changed after file creation with the chown and chgrp commands. Access to a file is determined by user and group ownership and a set of nine file permissions bits, which are shown by using an ls -l command. The basic group of three bits, denoted rwx (read, write, execute) is repeated for the user, group, and other. Directories use the same permission bits, but since a directory is a list of files, the interpretation is different. Read permission allows the listing of file names, and write permission allows creation and deletion of files. Execute permission specifies search permission on the directory and its subdirectories. (Chapter 23 of UNIX Power Tools has an excellent description of UNIX file permissions.)

File access control under Windows NT varies with the type of filesystem. The File Allocation Table (FAT) filesystem is compatible with DOS filesystems, offers very minimal access control, and is not adequate for our application. The Windows NT File System (NTFS) offers much more detailed control over file access. The five predefined file access permissions are No Access, Read, Change, Full Control, and Special Access. Each permission specifies the operations that the user can perform on the file, as shown in Table 1. For example, Read permission permits both reading and executing; Full Control permits reading, writing, executing, changing the file permissions, and taking ownership.

Under Windows NT, a security descriptor (SD) structure contains the security information for a file. The SD contains an owner, a group, a discretionary access control list (ACL), and a system ACL. An ACL is a list of users and groups along with their access permissions. The owner for a file can be a user or an NT group. Windows NT Server has three types of groups for managing users, local, global, and special. A local group includes only users on the local computer; whereas, a global group is used across an entire domain (including trusted domains). A Windows NT domain is a collection of computers with a common domain database and security policy, conceptually similar to a Network Information Service (NIS) domain. The special group is used internally for system access to permissions. Special groups are built-in and the administrator (the Windows NT counterpart of UNIX root) cannot add users to special groups. The group entry in the SD is different from the NT group and is included for POSIX support. Matching groups across Windows NT and UNIX must be given special attention. The discretionary ACL can be controlled by the owner of the file; so for example, the owner of a file can give full control to other users. The system ACL is under the control of the administrator and is used for audit messages. Additional information on Windows NT security structures can be found in Supporting Microsoft Windows NT Server and Support Fundamentals for Microsoft Windows NT Server.

The Windows NT File Manager can be used to view and change file permissions and ownership. From the File Manager, highlight a file or directory and then select Security on the File Manager menubar. This will bring up a menu with the items Permissions, Auditing, and Owner. (These are grayed out for FAT filesystems that don't support security.) One shortcut is to use the security icon (a door key) from the File Manager toolbar. Selecting Permissions will bring up a dialog box that shows the permissions for the current file or directory selection. Default file permissions for Windows NT are very generous, because of the DOS heritage of Windows. The user and Everyone (an NT built-in group that is the counterpart of world or other) have full control over the file. Typically, UNIX directory permissions are drwxr-xr-x, which gives only the owner full control, while group and other have read and search access. File permissions are inherited by subdirectories, so this can be changed easily. Under version 4.0 of Windows NT, which has the new Windows 95 type of window manager interface, click the right mouse button on the filename in Explorer and select properties. From a DOS prompt (the Windows counterpart of an xterm), the command CACLS can be used to view permissions and ownership. CACLS with no arguments will provide a list of arguments for the command.

Case Sensitivity and Name Mangling

With NTFS, a filename can be up to 255 characters long and include spaces and periods. The case of a filename is preserved, but the filename is not case sensitive (Minsai et al., 1996, p. 224). So, for example, the filenames TheVeryLongFileName and Theverylongfilename collide under NTFS. On a UNIX filesystem, filenames can be up to 255 characters and are truly case sensitive. Filenames that differ only by case are sometimes used under UNIX, so some caution is needed when using an exported NTFS. During earlier phases of this project, files transferred using ftp from Windows for Workgroups had uppercase filenames and were often converted to lower case using mv. On NTFS, such filenames collide. For example, mv KMAPSUB.CXX kmapsub.cxx will collide. BW Connect handles the collision by creating a mangled filename and adds an index file to the subdirectory. The files are safe, but figuring out which is which can be difficult, because applying the above mv to an entire subdirectory will give lowercase names on UNIX and only mangled names on NT. The name collision problem can be avoided by using a temporary filename when changing case (i.e., mv the file to a temporary name and then mv temporary name to the target name). On the client side, BW Connect offers some user preference options to deal with the lack of true case sensitivity under NTFS, which can be accessed from Main/Control Panel/Networks/BW Client/Configure.

Changing Permissions and Ownership

Under UNIX, chmod is used to change file permissions, and only the file's owner or root is allowed to change permissions. With NTFS, the ability to change permissions on a file can be given to other users. With NT, either the File Manager or CACLS is used to change permissions. Using File Manager, the menu sequence Security/Permissions is used to view the permissions in a dialog window. The dialog can be used to add or remove permissions for users or groups. This is a two-step process of selecting the user or group, pressing the Add button, which adds the name to a box at the bottom of the dialog, and then selecting the permissions to be given. The permissions are changed when the dialog box is dismissed (an Apply button would be handy). This can be confusing when the permissions are changed in the dialog and an ls is done on the file on the UNIX client before dismissing the dialog.

The file's owner can change the file's group and, under some UNIX systems without accounting, the owner can change the file's owner. Root can always change anything on local filesystems. Under NTFS, the owner can only permit someone else to take ownership of a file, so taking ownership will be an unfamiliar concept for UNIX users. To change file ownership under NTFS, use the Add button from the File Manager/Security/Permissions menu sequence to add the new owner, give either Full Control or Special Access/Change Ownership. This can also be done from a command line with a CACLS filename /G new_owner:F. The new owner must then log in and take ownership of the file from the File Manager/Security/Owner/Take Ownership menu item sequence. The administrator can always take ownership of any file or directory. There does not appear to be a way to transfer ownership without logging in, and the login/logout/login as another user operation can be quite slow.

The notion of group under Windows NT is different from UNIX. There is no visibility into a GID from File Manager, so files created from NT should have the group changed on the UNIX client with chgrp.

Frequently, errors that occur when using chmod, chown, and chgrp from the UNIX client do not generate any messages, and the command is simply ignored. Use an ls -l to determine whether the command was ignored. If so, check the file permissions on the NT side and verify that the owner has the appropriate permissions. Usually, the owner should be given full control, but if the file was created on the UNIX side, the owner will have only RWXDP. Problems in deleting files and directories from File Manager can often be remedied by giving the owner Full Control. chown is always ignored because changing ownership under NT must be done by the new owner.

Installation Checklist

I found the following checklist useful for setting up the shared filesystems.

As the Windows NT administrator:

1. Install NFS server under Windows NT

2. Export file systems from NT [probably under Main/Control Panel/(your particular NFS server)]

3. Set up the mapping from UID to user name, GID to local group

As a user under Windows NT:

1. Create a subdirectory

2. Restrict permissions, if the defaults are not acceptable

As UNIX root:

1. Modify /etc/fstab or /etc/vfstab for boot time mounting

2. Mount filesystems on the UNIX client

As a UNIX user:

1. Change the group for the subdirectory

You should test file access control before turning it over to the developers. For example, use touch to create a file in the subdirectory from the UNIX client, then check that the permissions are set correctly and that group permissions are as expected. For example, with the directory permissions of drwxr-xr-x, other members of a group should not be able to delete files in the user's subdirectory. The current NFS software for Windows does not appear mature enough to take this on faith.

Permissions Mapping

Creating a file file1 on the NT Server gives the file owner and everyone Full Control but file1 doesn't belong to a group. So, on the UNIX side, an ls -l gives -rwx---rwx, with an unknown GID. First, change the GID, which can be done with chgrp on the UNIX client. Next, to illustrate changing permissions, consider a chmod 000 file1. This will set all the UNIX permission bits to 0. NT's File Manager will then show the following permissions:

Administrators      Full Control
Domain Admins       Full Control
NETWORK             Full Control
Server Operators    Change (RWXD)
"owner"             Special Access (P)
SYSTEM              Special Access(RWXDPO)

Adding permissions on the UNIX side is reflected in a straightforward way on the NT side, as shown in Table 2. For example, chmod 400 file1 adds read permission for the owner. A chmod 644 file1 adds RWD for the user, R for the group, R for Everyone on the NT side, and produces -rw-r--r-- on a UNIX ls. Adding write permission on the UNIX side corresponds with adding both write and delete on the NT side. To give Full Control to the owner, telnet to the NT server and use the CACLS command. This can be handy when the NT server won't let the owner remove a directory. P (change permissions) is inferred from UNIX file ownership by the NFS product, so the details will probably depend on the particular NFS product used. Root has no special powers over imported filesystems, and a naive but instinctive su followed by rm -rf subdirectory will only generate a Permission denied.

Summary

Table 3 summarizes how various filesystem operations are performed in UNIX and Windows NT. In using an NFS product to serve Windows NT filesystems to UNIX clients, two minor difficulties are case sensitivity and the lack of group ownership. File permissions are more extensive for NTFS than for UNIX filesystems, so normal use of UNIX file permissions (e.g., in a group software development environment) is easily accommodated. However, because there are more NT permissions than UNIX permission bits, the UNIX permission bits are not a reliable indicator of what can really happen. Sometimes the NTpermissions also must be checked to explain unexpected behavior.

Further Reading

Hunt, C. 1995. Networking personal computers with TCP/IP. Sebastopol, CA: O'Reilly & Associates, Inc. ISBN: 1-56592-123-2.

Microsoft Press. 1996. Support fundamentals for Microsoft Windows NT. Redmond, WA: Microsoft Press. Part Number 097-0001372.

Microsoft Press. 1996. Supporting Microsoft Windows NT Server. Redmond, WA: Microsoft Press. Part Number 097-0001373.

Minsai, M., C. Anderson, and E. Creegan. 1996. Mastering Windows NT Server 3.51. San Francisco, CA: Sybex. ISBN: 0-7821-1874-7.

Nemeth, E., G. Snyder, S. Seebass, and T. R. Hein. 1995. UNIX system administration handbook. Englewood Cliffs, NJ: Prentice Hall. ISBN 0-13-151051-7.

Peek, J., T. O'Reilly, and M. Loukides. 1993. UNIX power tools. Sebastopol, CA: O'Reilly & Associates, Inc. ISBN: 0-553-35402-7.

About the Author

Al Koscielny is a software engineer at Kaman Sciences Corporation; his educational background is in meteorology and software engineering. His interests include object-oriented design, C++ applications, UNIX system administration and Windows-UNIX networking. He can be reached at koscieln@csn.org.