Understanding the NetWare UNIX Client (NUC) NLM 2.0

Articles and Tips: article

BRETT G. PALMER
Software Test Engineer
NetWare Products Division

01 Jul 1995

This AppNote explains many of the features of NUC.NLM, the NetWare UNIX Client support module that comes with UnixWare 2. The AppNote begins with a brief overview of what NUC.NLM does. It then focuses on ownership and rights mappings between UnixWare and NetWare, giving several examples of how file and directory ownership is assigned and how UNIX permissions map to NetWare trustee rights (and vice versa). It details how to configure a NetWare server with NUC.NLM and set up a volume on the server for sharing UNIX files and running UNIX applications. The AppNote concludes with a list of answers to commonly asked questions and problems relating to NUC.NLM.

Related AppNotes Feb 93 "Mapping Between UNIX Permissions and NetWare Rights in NetWare NFS"

Introduction
Overview of NUC.NLM
Ownership Mapping During File/Directory Creation
Ownership Mapping During Lookup
Rights and Permissions Mapping
Setting Up a System with NUC.NLM
Common Problems
Conclusion

Introduction

UnixWare 2 comes with an improved version of the NetWare UNIX Client support module, called NUC.NLM. The NetWare UNIX Client software makes it possible for UnixWare users to directly access a NetWare volume as if it were a remote UNIX file system. NUC.NLM provides better access control integration between the NetWare and NUC file systems.

This AppNote explains many of the features of NUC.NLM. After a brief overview of what NUC.NLM does, the AppNote focuses on ownership and rights mappings between UnixWare and NetWare. It gives several examples of how file and directory ownership is assigned and how UNIX permissions map to NetWare trustee rights (and vice versa).

It details how to configure a NetWare server with NUC.NLM and set up a volume on the server for sharing UNIX files and running UNIX applications. The AppNote concludes with a list of answers to commonly asked questions and problems relating to NUC.NLM.

This AppNote is intended as a supplement to the current UnixWare documentation, not as a replacement for it. The discussion assumes that you have a basic understanding of NetWare rights and UNIX permissions. If you need more information on these topics, consult your NetWare and UnixWare documentation. The February 1993 AppNote entitled "Mapping Between UNIX Permissions and NetWare Rights in NetWare NFS" also contains useful information on this topic.

Overview of NUC.NLM

Traditionally, NetWare's support for UNIX clients involved the use of the TCP/IP protocol suite and typically included packages such as NetWare NFS and NetWare/IP. With TCPIP.NLM and NFS.NAM (the NFS name space module) loaded on the NetWare server, UNIX clients accessed directories and files on the server by using their native NFS and the UDP/IP network protocol.

With UnixWare, Novell introduced a more integrated approach to supporting UNIX clients in the form of the NetWare UNIX Client (NUC) software. This software allows clients running UnixWare to access applications, directories, and files on a NetWare server by using NetWare Core Protocols (NCPs) and the IPX network protocol (see Figure 1).

Figure 1: NetWare's traditional UNIX client support compared with UnixWare's integrated client support as provided by NUC software.

NUC.NLM is a NetWare Loadable Module that is included with UnixWare 2. Along with the NFS.NAM module, NUC.NLM allows the NetWare UNIX Client software to directly access a NetWare volume as if it were a remote UNIX file system.

This access is accomplished through the NUC File System (NUCFS), a UnixWare network file system that provides NetWare file services to a UnixWare platform. NUCFS is an NCP engine for UnixWare that uses IPX/SPX as its underlying protocol. NUCFS access is possible with NetWare 3.11 or later versions.

By using NUC on the client and NUC.NLM (and the NFS name space) on the NetWare server, a UnixWare client is able to map NetWare services into the UnixWare environment. UnixWare users can then work with directories and files on the NetWare server just as they would in a native UNIX environment, making full use of long filenames, user and group ids, and UNIX-style permissions.

They can also share files with NetWare users. NUC.NLM includes new NCPs to better accommodate UNIX operations (create, open, link, delete, rename, and so on). It also handles the translation between NetWare and UnixWare security and ownership information.

Files Used by NUC.NLM

To map between NetWare users/groups and UNIX user ids/group ids, NUC.NLM uses the following files (located in the SYS:\ETC directory on the NetWare server):

File	Use
NFSUSERS	To determine which UNIX user id (uid) maps to which NetWare user
NFSGROUP	To determine which UNIX group id (gid) mapsto which NetWare group
PASSWD	To determine which UNIX uid belongs to whichUNIX gid

The PASSWD file is the link between the uids and the gids. Without a proper entry in this file, NUC.NLM will not know which NetWare group is mapped to which NetWare user.

Terminology

To better understand how NUC.NLM operates, let's define some terminology that describes the module's behavior.

Note: Here and throughout this AppNote, uppercase names refer to objects that reside on the NetWare server. Lowercase names refer to objects that reside on the UnixWare client.

Native id: This term refers to the uid and/or gid on the UnixWare machine. It is the id you would see displayed on a UnixWare terminal if you used the "id" command at the terminal prompt. For example, if you typed "id" you might see something like this:

uid=101(user1) gid=2(group1)

In this example, your native uid is 101 and your native gid is 2.

Mapped id: This term refers to the UNIX ids (uids/gids) and NetWare users/groups that are found in the NFSUSERS, NFSGROUP, and PASSWD files in the SYS:\ETC directory. "Mapped id" also refers to the UNIX ids (user and group ids) that are stored in the NFS name space by the NUC.NLM during file and directory creation.

Unmapped id: This term refers to those UNIX ids and NetWare users/groups that are not found in the NFSUSERS, NFSGROUP, or PASSWD files.

Ownership: This term refers to identifying which NetWare user NUC.NLM determines has ownership on the file. Note that ownership in the UNIX mode is determined differently than it is in the NetWare mode (see the "NetWare Mode vs. UNIX Mode" section for details).

Effective rights: This is a term used in NetWare to describe the rights that a particular user or group can actually exercise on a file or in a directory. Effective rights are determined by taking a combination of all rights that a user or group has due to security equivalence to other users and groups, inheritance from higher-level directories, explicit trustee assignments, and so on. It is the NetWare effective rights that NUC.NLM uses to determine which UNIX permissions should be mapped to a file or directory.

Mappings Performed by the NUC.NLM

During file and directory creation, NUC.NLM performs two types of mappings. The first type of mapping is between UNIX uids/gids and NetWare users/groups ("ownership" mapping). The second type of mapping is between UNIX permissions and NetWare rights ("rights and permissions" mapping). The procedures that NUC.NLM uses to determine these mappings are explained in detail later in this AppNote.

Note: NUC.NLM depends on the NFS name space to perform these mappings. NUC.NLM will not perform any mappings unless NFS.NAM is loaded for the volume.

NetWare Mode vs. UNIX Mode

NUC.NLM can be configured to run in either of two modes: the NetWare mode and the UNIX mode and the UNIX mode. The mode is set on a per-volume basis.

The NetWare mode was created to allow file sharing between UnixWare and NetWare and to allow all administration to be performed from the NetWare side. The access control methods used are the traditional NetWare access control methods: trustee assignments, inherited rights masks, attributes, and so on. In this mode, no trustee assignments are automatically generated for UnixWare clients.

In this mode the NUCFS does not enforce any UNIX access control methods. If the NetWare server allows the authenticated user to perform an operation, that operation will succeed regardless of the permissions or ownership of the UnixWare user. You do lose some UNIX integration; for example, chmod, chown, and chgrp commands are ineffective in the NetWare mode. However, this mode is easier to administer from a NetWare point of view.

The UNIX mode was created to provide better UNIX integration with NetWare. UNIX applications should be able to run on a NetWare volume that is in the UNIX mode. In the UNIX mode, NetWare trustee assignments are used to emulate UNIX permissions for files and directories. For every file and directory created by a UnixWare client, three trustee assignments are automatically made:

One for the mapped NetWare user
One for the mapped NetWare group
One for the group EVERYONE (or for the bindery container on NetWare 4 servers; see "Differences between the NetWare 3 and 4 Versions" for more information)

In the UNIX mode, NUC.NLM allows some NetWare administration to be performed from the UnixWare client. For example, when a user changes the UNIX permissions on a file/directory, the trustee assignments for the file/directory on the NetWare side are also changed and vice versa. Another example would be when a user does a chown command from a UnixWare client, the ownership on the NetWare side (in the DOS name space) is also changed.

The following are factors to consider when choosing which mode to use:

What types of activities will be done on the NetWare volume? For example, if you want to run UNIX applications on the NetWare volume, you should probably use the UNIX mode. But if you only want to share files between NetWare and UnixWare users, you might want to use the NetWare mode.
Do you want UnixWare users to be able to modify rights on the NetWare server? If so, you should use the UNIX mode.
Is NetWare server performance a high priority in your environment? The UNIX mode can cause excessive amounts of trustee assignments, which can affect a NetWare server's performance.
Which do you prefer: NetWare administration or UnixWare administration? In the NetWare mode, all administration is done from the NetWare server. In the UNIX mode, administration is done on the NetWare server and on the UnixWare client.

Ownership Mapping During File/Directory Creation

When a file or directory is created in a volume with NFS.NAM and NUC.NLM loaded, NUC.NLM tries to create the best possible mapping between UnixWare and NetWare users and groups. The ownership mapping occurs regardless of what client software is being used (UNIX, DOS, OS/2, and so on). It is the NetWare user who is creating the file/directory that determines how ownership is mapped.

When a file or directory is created, NUC.NLM performs several operations to determine the appropriate entries (mappings) to place into the NFS name space. These operations are explained as follows:

At creation time NUC.NLM checks to see if the NetWare user who is performing the creation has an entry in the NFSUSERS file.
- If an entry is not found for that NetWare user, NUC.NLM places the id of "root" into the uid and gid entries in the NFS name space.(In the NFSUSERS file, the default uid for "root" has the value of 0). The process stops at this point.
- If an entry is found for that NetWare user, the uid that is paired with the NetWare user's name is placed in the NFS name space uid entry for that particular file/directory. The process then continues with Step 2.
After a user entry has been found in the NFSUSERS file, NUC.NLM checks the PASSWD file to find the matching UNIX group id that is paired with the UNIX user id found in the NFSUSERS file.
- If an entry is not found, the id of "root" is placed in the NFS name space gid entry. The process stops at this point.
- If a matching uid is found in the PASSWD file, the process continues with Step 3.
Once a mapped uid has been found, the corresponding group id is compared with the entries in the NFS GROUP file to find the matching NetWare group.
- If a group is found, the mapped gid is placed in the NFS name space entry for that particular file/directory.
- If a group is not found, NUC.NLM places the name of "root" into the gid entry in the NFS name space.

This process is illustrated in Figure 2.

Figure 2: The procedure NUC.NLM uses to map ownership during file/directory creation.

Example Configuration Files

All of the examples in this AppNoteuse the same configuration files (NFSUSERS, NFSGROUP, and PASSWD).Although the sample configuration is simple, the principles illustratedcan be applied to configurations with many more users and groups.

The configuration files contain the following entries:

SYS:\ETC\PASSWD File

root:x:0:3:0000- Admin(0000):/:/sbin/sh
user1:x:113:604::/home/user1:/usr/bin/ksh
user2:x:114:604::/home/user2:/usr/bin/ksh
nomapu:x:115:605::/home/nomapu:/usr/bin/ksh

Note: The PASSWD file is simply a copy of my UnixWare /etc/passwd file(to simplify this example, I chose to erase all the other UnixWareusers in this file). The key elements of this file are the uidand gid entries. For example, NUC.NLM will parse the line "user1:x:113:604/home/user1:/usr/bin/ksh" to find the uid entry (113) and the gid entry (604). The restof the information is ignored.

SYS:\ETC\NFSUSERS File

#  "NFS uid", "NetWare Username"
0       ADMIN
113     USER1
114     USER2

SYS:\ETC\NFSGROUP File

#  "NFS gid", "NetWare Group Name"
3       SYS
1       OTHER
604     NUCUSERS

The user and group configurations are as follows:

UnixWare User and Group Configuration

UnixWare User Names	UID	UnixWare Group Names	GID
user1	113	nucusers	604
user2	114	nucusers	604
nomapu	115	nomapg	605

NetWare User and Group Configuration

NetWare Users	NetWare Groups
USER1	NUCUSERS
USER2	NUCUSERS
NOMAPU	NOMAPG

For simplicity's sake, I have conveniently mapped UnixWare user1 (113) to NetWare USER1, and UnixWare user2 (114) to NetWare USER2. The names do not have to be the same between UnixWare and NetWare, although this may help eliminate errors while setting up the mappings. Also note that the UnixWare user "nomapu" (not mapped user) and its group "nomapg" (not mapped group) do not have entries in the NFSUSERS and NFSGROUP files. This was deliberate to show the effects of users that are not mapped.

Examples

The following table contains three examples of ownership mapping during file creation. The examples refer specifically to file creation, but the same results apply to directories as well.

ExampleName for File Creation	UnixWareUser/Group	Login As NetWare User:	NFSEntries at File Creation	NetWareOwner at File Creation
1. Mapped User	user1(113)/ nucusers (604)	USER1	uid: 113 gid: 604	USER1
2. Non-mapped User	nomapu (115)/nomapg (605)	NOMAPU	uid: 0gid: 0	NOMAPU
3. Different User	user1 (113) /nucusers (604)	USER2	uid: 114gid: 604	USER2

Example 1: Mapped User From a UnixWare client, user1 (uid=113) creates a file on a NetWare volume via the NUCFS. The user is authenticated as the NetWare user USER1. At creation time NUC.NLM places the numbers 113 and 604 into their respective uid and gid positions in the NFS name space. These IDs were found in the NFSUSERS, NFSGROUP, and PASSWD configuration files (see the sidebar "Example Configuration Files").

Example 2: Non-mapped User In this example a non-mapped UnixWare user, nomapu (uid=115), creates a file on a NetWare volume. This user is authenticated as the non-mapped NetWare user NOMAPU. Since there aren't any mapping entries for this user in the configuration files (NFSUSERS, NFSGROUP, and PASSWD), NUC.NLM places the root ID (0) into the uid and gid positions in the NFS name space.

Example 3: Different User This third example highlights how the IDs placed in the NFS name space depend on the authenticated NetWare user. In this case the UnixWare user user1 logs into the NetWare server as USER2. Since USER2 is the authenticated user, NUC.NLM searches the configuration files for entries that are relevant to USER2. The result is that NUC.NLM places the IDs of 114 and 604 into the uid and gid positions, respectively.

Ownership Mapping During Lookup

It is important to remember that NUC.NLM is trying to emulate the effective rights of the NetWare user. This means that the ownership displayed for a particular file/directory on your UnixWare client may change when you use a different NetWare user account. The way that NUC.NLM determines what uid or gid should be displayed on the UnixWare client depends on who it thinks has ownership on the file or directory.

Ownership, as determined by NUC.NLM, behaves differently for the UNIX mode than for the NetWare mode. The difference is as follows:

In the NetWare mode, ownership occurs when a NetWare user has either the Access Control (or Supervisor) right OR the user is the 'NetWare owner' of the file/directory. (The NetWare owner of the file/directory is usually the original NetWare creator of the object. NetWare ownership can be seen by using the NetWare NDIR or FILER utilities.)
In the UNIX mode, ownership occurs when a user has both the Access Control (or Supervisor) right AND the user is the NetWare owner of the file/directory.

It is important to remember that in the NetWare mode ownership is determined by an OR operation of the Access Control right and NetWare ownership, whereas in the UNIX mode it is an AND operation.

There are three possible ownership values that can be displayed for the uid and the gid of a particular file/directory on the UnixWare client:

The native id
The mapped id
The id of "nobody"

The id of "nobody" is displayed on the client when NUC.NLM discovers an id conflict. An id conflict occurs when a user's native id is the same as the NFS mapped id, but the authenticated NetWare user does not have ownership on the file. Rather than give the user on the UnixWare client the impression that he/she has ownership on the file, the id of "nobody" is displayed.

Note: The id of "nobody" could also be displayed if there was an actual user or group named "nobody." For this reason it is recommended that you avoid creating usersor groups with the name of "nobody."

When a directory listing is performed in the NUCFS from a UnixWare client (for example, with the ls -l command) NUC.NLM has to check each entry in the directory to determine what it should display for the UnixWare client. The process it uses to determine what is displayed on the UnixWare client is explained in the following steps:

If the NetWare user is the owner of the file/directory (as determined by NUC.NLM), the native uid and the mapped gid is displayed on the client. The process is complete for thatparticular file/directory.
If the NetWare user is not the owner and there is not a user id conflict, the mapped uid is displayed on the UnixWare client and the process continues to Step 3.

If a user id conflict occurs, the uid of "nobody" is displayed on the client and the process continues to Step 3.
After the uid has been discovered, NUC.NLM must determine which gid should be displayed on the client. NUC.NLM checks to see if the authenticated NetWare user belongs to the mapped NetWare group of the file/directory.

If the NetWare user does belong to the NetWare group assigned to file/directory at hand, the native gid is displayed on the client.

If the NetWare user does not belong to the mapped group and there is not a group id conflict, the mapped gid is displayed.

If a group id conflict occurs, the gid of "nobody" is displayed on the client and the process is complete for that particular file/directory.

Steps 1 through 3 are repeated for each entry found in the directory. The entire process is illustrated in Figure 3.

Figure 3: The procedure NUC.NLM uses to determine what ownership to display on the UnixWare client.

Examples

The following tables contain several examples of what you can expect from NUC.NLM during a directory listing (ls -l) from your UnixWare client. The first table shows examples of what a mapped UnixWare user might see on his/her terminal when authenticated as various NetWare users (mapped and unmapped). The second table shows examples of what an unmapped UnixWare user might see on his/her terminal when authenticated as various NetWare users (mapped and unmapped).

In each table, the first column numbers the example; the second column shows the UnixWare user and group ids of the user performing the listing; the third column is the authenticated NetWare user; the fourth column shows what NetWare user was used by a UnixWare client to create the file; the fifth column shows the uid and gid entries in the NFS name space; and the sixth column shows what uid and gid values are displayed on the UnixWare client after the directory listing has occurred. Although the examples shown are for files, the same results apply to directories as well.

Mapped User Examples. In the examples below, the native ids of user1 (113) and nucusers (604) are the same for each example. What changes are the NetWare users.

Note: In these examples we assume that none of the NetWare rights havechanged on the file since creation time. An alteration of NetWarerights could change the ownership on the file (see "Rightsand Permissions Mapping" later in this AppNote).

Mapped User
#	UnixWareUser/Group (native ids)	AuthenticatedNetWare User	OriginalNetWare Creator	NFSEntries at File Creation (mapped ID)	idsDisplayed on UnixWare Client
1	user1(113) / nucusers (604)	USER1	USER1	uid: 113 gid: 604	uid: 113 (user1 - native ID)gid: 604 (nucusers - mapped ID)
2	user1(113) / nucusers (604)	USER1	USER2	uid: 114 gid: 604	uid: 114 (user2 - mapped uid)gid: 604 (nucusers - native gid)
3	user1(113) / nucusers (604)	USER2	USER2	uid: 114 gid: 604	uid: 113 (user1 - native uid)gid: 604 (nucusers - mapped gid)
4	user1(113) / nucusers (604)	USER2	USER1	uid: 113 gid: 604	uid: "nobody" (due to uid conflict)gid: 604 (nucusers - native gid)
5	user1(113) / nucusers (604)	USER1	NOMAPU	uid: 0gid: 0	uid: 0 (root - mapped uid)gid: 0 (root - mapped gid)

Example 1 In this example the UnixWare user, user1, is authenticated as the NetWare user USER1. The user does a directory lookup on a file. The file was originally created by USER1. Because the NetWare user has ownership on the file, NUC.NLM sends the native uid (113) and the mapped gid (604) to the UnixWare client.

Example 2 This example is similar to Example 1 above, except in this case the file was created by USER2. NUC.NLM realizes that USER1 does not have ownership on this file, so it checks to see if USER1 is a member of the mapped NetWare group, NUCUSERS. USER1 is a member of this group, so NUC.NLM sends to the UnixWare client the mapped uid (114) and the native gid (604, which coincidently matches the mapped gid found in the NFS name space).

Example 3 In this example user1 is authenticated as USER2. The user does a directory lookup on a file that was created by USER2. Because the file is owned by USER2, NUC.NLM sends to the UnixWare client the native uid (113) and the mapped gid (604).

Example 4 Here we have an example of an id conflict. The UnixWare user user1 is authenticated as the NetWare user USER2. The directory lookup is on a file that is owned by USER1. NUC.NLM determines that USER2 is not the owner of the file, so it checks the mapped uid against the native uid. Since the uids match, NUC.NLM sends back the id of "nobody." After determining the proper uid, NUC.NLM checks to see if USER2 is a member of the mapped NetWare group, NUCUSERS. Because USER2 is a member of this NetWare group, the native gid (604) is also sent to the UnixWare client.

Example 5 In this example user1 is authenticated as USER1. A directory lookup is performed on a file that was created by a non-mapped NetWare user, NOMAPU. Because the NetWare user was not mapped, NUC.NLM places the id of root (0) into the NFS name space entries. Since USER1 does not have ownership on the file, the mapped uid (0) and gid (0) found in the NFS name space are sent to the UnixWare client.

Non-mapped User Examples. In the examples below, the native ids nomapu (115) and nomapg (605) are the same for each example. What changes are the NetWare users.

Non-mapped User
#	UnixWareUser/Group (native ids)	AuthenticatedNetWare User	OriginalNetWare Creator	NFSEntries at File Creation (mapped ID)	idsDisplayed on UnixWare Client
1	nomapu (115) / nomapg (605)	NOMAPU	NOMAPU	uid: 0gid: 0	uid: 115 (nomapu - native uid)gid: 0 (root - mapped gid)
2	nomapu (115) / nomapg (605)	NOMAPU	USER1	uid: 114 gid: 604	uid: 114 (user1 - mapped uid)gid: 604 (nucusers - mapped gid)
3	nomapu (115) / nomapg (605)	USER1	NOMAPU	uid: 0gid: 0	uid: 0 (root - mapped uid)gid: 0 (root - mapped gid)

Example 1 In this example a directory lookup is being done on a file that was created by the unmapped NetWare user NOMAPU. NUC.NLM determines that NOMAPU has ownership of the file, so it sends the native uid (115) and the mapped gid (0) to the client.

Example 2 Here an unmapped user is looking up a file that was created by a mapped user, USER1. Since the unmapped user does not have ownership on the file, NUC.NLM sends the mapped ids (114, 604) to the client.

Example 3 In this example the unmapped user authenticates as a mapped NetWare user, USER1. A directory lookup is performed on a file that was created by the unmapped NetWare user NOMAPU. Since USER1 does not have ownership on the file, the mapped ids (0, 0) are displayed on the UnixWare client.

Rights and Permissions Mapping

When a file or directory is created from the UnixWare client on a NetWare volume that is in the UNIX mode, NUC.NLM creates three trustee assignments. These trustee assignments map into the UNIX permissions for user, group, and world (other). The permission values are stored in the NFS name space for each file/directory that is created.

Likewise, when the attributes of a file/directory are changed by any NetWare client, NUC.NLM changes the UNIX permissions in the NFS name space to map accordingly.

UNIX Permissions to NetWare Rights

The following table illustrates the mapping between UNIX permissions and NetWare rights. This table pertains only to volumes that are in the UNIX mode. (In the NetWare mode, no trustee assignments are automatically generated for files/ directories created by UnixWare clients. As a result, there are no rights mappings from UnixWare to NetWare in the NetWare mode.)

FileType	UnixWarePermissions	NetWareRights	Notes
File	r (read)	R (Read)
w (write)	W (Write)
x (execute)	No direct mapping	The executepermission does not have an equivalent mapping in NetWare. The execute permission is stored in the NFS name space to ensure adherenceto UNIX semantics.
Directory	r (read)	F (File Scan)right if directory also has the x (search) permission	The NetWareFile Scan right is granted to the mapped NetWare user if the UnixWare user has read(r) and search (x) permissions on the directory.
w (write)	C (Create) and E (Erase) rights; E (Erase) rights on all children objects	Write (w) permissionon a directory gives the NetWare user Createand Erase rights in the directory. The NetWareuser is also granted the Erase right to allfiles and directories directly beneath theparent directory.
x (search)	F (File Scan)right if directory also has the x (search) permission	The NetWareFile Scan right is granted to the mappedNetWare user if the UnixWare user has read(r) and search (x) permissions on the directory

At creation time, a trustee assignment is always created for the NetWare user and for the group EVERYONE (or the bindery container for NetWare 4.x servers), regardless of the mapping configurations. This is done to ensure that the NetWare user has ownership on the file/directory that was created.

A trustee assignment is also created for the mapped NetWare group if there is an appropriate entry in the PASSWD and NFSGROUP files. At creation time, the specific NetWare trustee assignments are determined by the umask setting on the UnixWare client and by the parent directory permissions.

Note: When a directory is created, NUC.NLM also affects the InheritedRights Mask (IRM) of the directory. If the creator of the newdirectory is not the owner of the parent directory, the IRM ischanged to EMF (Erase, Modify, and File Scan rights). If the creatorof the new directory is the owner of the parent directory, theIRM remains at its default value of SRWCEMFA (Supervisor, Read,Write, Create, Erase, Modify, File Scan, and Access Control) forthe new directory.

The process for determining these mappings is illustrated in Figure 4.

Figure 4: The procedure NUC.NLM uses to determine rights mappings.

NetWare Rights to UNIX Permissions

When a UnixWare client performs a directory lookup (as with the ls-l command), NUC.NLM displays two pieces of information on the client:

The ownership mappings (as determined according to the procedure described in the "Ownership Mapping During Lookup" section)
The permission mappings for each object (file or directory) in the directory

Once ownership has been determined, NUC.NLM calculates the correct permissions to display on the client. If the rights on a file/directory have not been modified since the last listing, NUC.NLM sends the permissions found in the NFS name space to the UnixWare client. If the rights have been modified since the last listing, NUC.NLM recalculates the UNIX permissions.

The recalculated permissions are then stored in the NFS name space and sent to the UnixWare client. The permissions are calculated by finding the NetWare effective rights of the NetWare user, group, and EVERYONE (or the bindery container for NetWare 4 servers).

The following table shows how NetWare rights map to UNIX permissions. This table pertains to both NetWare mode volumes and UNIX mode volumes.

FileType	NetWareRights	UnixWarePermissions	Notes
File	R (Read)	r (read)
W (Write)	w (write)
C (Create)	Not applicable to files
E (Erase)	Parent's w (write) permission	The write (w)permission is displayed on the parent directory if the NetWare user has the Erase right for all child files and directories.
F (File Scan)	Not applicable to files
A (Access Control)	No direct mapping	No direct mapping,but it is used to determine ownership (see "Ownership Mapping DuringLookup").
M (Modify)	No direct mapping	The Modifyright does not have a direct mapping, but it is necessary to perform chmod commandson a file/directory from a UnixWare client.
S (Supervisor)	No direct mapping	No direct mapping,but it is used to determine ownership (see "Ownership Mapping DuringLookup").
Directory	R (Read)	No direct mapping
W (Write)	No direct mapping
C (Create)	w (write) permissiongranted if directory also has the E Right	Write (w) permissionsare displayed on the UnixWare client if the NetWare user has Create and Erase rightsin the directory as well as the Erase right for all child files and directories.
E (Erase)	w (write) permissiongranted if directory also has the C Right	Write (w) permissionsare displayed on the UnixWare client if the NetWare user has Create and Erase rightsin the directory as well as the Erase right for all child objects below the directory.
F (File Scan)	r (read) and x (search) permissions	This occurs only if the NetWare user has File Scan rights in all child files and directories.
A (Access Control)	No direct mapping	No direct mapping,but it is used to determine ownership (see "Ownership Mapping DuringLookup").
M (Modify)	No direct mapping	The Modifyright does not have a direct mapping, but it is necessary to perform chmod commandson a file/directory from a UnixWare client.
S (Supervisor)	No direct mapping	No direct mapping,but it is used to determine ownership (see "Ownership Mapping DuringLookup").

The process NUC.NLM uses to map between NetWare rights and UNIX permissions is illustrated in Figure 5.

Figure 5: The process NUC.NLM uses to map between NetWare rights and UnixWare permissions.

Setting Up a System with NUC.NLM

There are several ways to set up a NetWare server with NUC.NLM. The following paragraphs describe some of the key points to consider for an effective setup.

Differences Between the 3.x and the 4.x NUC.NLM

There are three fundamental differences between the NUC.NLM for NetWare 3.x servers and the NUC.NLM for NetWare 4.x servers.

INETDB.NLM. The first difference is in the setup process. For NetWare 4 servers, you must run INETDB.NLM on the server console prior to loading NUC.NLM. This step needs to be done only once.

Failure to run INETDB.NLM on a NetWare 4.x server will resultin unexpected behavior with NUC.NLM in regards to file/directoryownership and permission mappings.

SUPERVISOR vs. ADMIN. The second difference is that the NetWare 4.x server installation process does not create the user SUPERVISOR. Instead it creates the user ADMIN. If a user named SUPERVISOR is desired, the system administrator must create it.

The absence of a SUPERVISOR user can pose a problem with mappings for NUC.NLM. If in the NFSUSERS file you try to map the uid of 0 (root) to the NetWare user SUPERVISOR and there isn't a user SUPERVISOR, NUC.NLM performs the ownership and rights mappings as if no mapping existed.

The Group EVERYONE. The third difference between the NetWare 3.x and 4.x NUC.NLM is the group EVERYONE. For a NetWare 3.x server, NUC.NLM maps the NetWare group EVERYONE to the group "world" on Unix. This is a good mapping since by default all NetWare users belong to the group EVERYONE on a NetWare 3.x server.

On a NetWare 4.x server, the group EVERYONE does not exist unless it is created by the system administrator. There is no default group that all users belong either. To overcome this problem, NUC.NLM maps the Unix group "world" to the NetWare bindery context container.

UNISTART and UNISTOP Files

The UNISTART.NCF and UNISTOP.NCF files allow a system administrator to load and unload all the NUC/NFS files with one command at the server console. This is much easier than typing in all of the necessary commands separately.

These files are created when NUC.NLM is first installed on the server. You can edit the UNISTART.NCF file from the server console by typing

load edit sys:\system\unistart.ncf

A similar command can be used to edit the UNISTOP.NCF file.

Example: Setting Up a Volume in the UNIX Mode

This section gives an example of how to set up a NetWare server in the UNIX mode.

Step 1: Set up the NetWare server.

Follow the instructions in your UnixWare System Administration handbook to successfully load NUC.NLM on your NetWare server. (If you are running NUC.NLM on a NetWare 4.x server, remember to load INETDB.NLM. You will get unexpected behavior if you forget this step.)

Be sure to make the appropriate entries in your mapping files (NFSUSERS, NFSGROUP, and PASSWD) for all users that will be accessing the NetWare server from a UnixWare machine.

Step 2: Set up the UnixWare client.

The easiest way to set up a directory structure for UnixWare users to access the NUCFS (in the UNIX mode) is from a UnixWare client. By using the UnixWare client to create your directory structure, you allow NUC.NLM to perform all the necessary mappings.

Note: You could configure your directory structure from a DOS client,but it would require many more steps and would also be prone toerror. You would have to manually perform all of the trustee assignmentsand ownership settings.

Suppose you want to create three home directories for three UnixWare users who will be accessing a NetWare volume in the UNIX mode. Home directories give each user a personal area on the volume in which to create and delete files/directories without granting the users access to the entire volume.

Here is the NetWare configuration:

Server Name: NOVELL (NetWare 4.1 server)Volumes:SYS, APPS, UNIXUsers: USER1, USER2, USER3Groups:NUCUSERS

Here is a list of UnixWare users and groups, with their corresponding uids and gids:

UnixWare Machine: unixware (UnixWare2 Application Server)Users: user1(113),user2(114), root (0)Groups: sys(1),nucusers(604)

Users 1, 2, and 3 belong to the NUCUSERS group. The NetWare users are mapped to their respective UnixWare users 1, 2, and 3. All of the UnixWare users use the UnixWare 2 Application Server, named unixware, to run their UNIX applications. The users would like to be able to run their UNIX applications and store their files on a NetWare volume.

First, log in to the NetWare server and verify UNIX permissions at the root of the volume.

As root from unixware, log in to the NetWare server NOVELL.
Use the cd command to change to the directory /.NetWare/NOVELL.
Do an ls -lin the directory. You see the following:
```
rwxr-xr-x     root     sys     unix
rwx------     root     root    sys
rwx------     root     root    apps
```
These are the correct permissions we want for our users. We don't want them to have write permissions at the root of the volume.

To create the home directories for the UnixWare users, perform the following operations from the UnixWare client:

Change to the UNIX volume by typing

cd unix
Create a home directory for user1 by typing

mkdir user1
Change the ownership on the directory from "root"to "user1" by typing

chown user1 user1
Change the group ownership on the directory from "sys" to "nucusers" by typing

chgrp user1 nucusers

After creating the home directory user1, we used the chownand chgrp utilities to change the ownership and group values to the respective UnixWare user (user1). Otherwise the new home directory would be owned by root and the gid would be sys. When you use chownand chgrp,NUC.NLM changes all the necessary trustee assignments and NetWare ownership values automatically.
Repeat Steps 1 through 4 for user2, substituting "user2" for "user1" where appropriate.
Do a listing on the directories (ls-l command) to verify the new home directories. You see the following:
```
rwxr-xr-x    user1     nucusers user1    
rwxr-xr-x    user2     nucusers user2
```
You now have two home directories in which the UnixWare users can share files with their respective NetWare users. The UnixWare users can also add or revoke permissions to their home directories by using the chmod utility.

Recommendations

Here are two recommendations for setting up and working with NUC.NLM.

Create mapping assignments for all UnixWare users who will be accessing the NetWare volume.
Those UnixWare users who will be accessing the NetWare volume should authenticate as their mapped NetWare users. For example, if a system administrator wants to perform "root"-type activities in the NUCFS, the system administrator should log in as SUPERVISOR (or Admin) on the NetWare server.

Common Problems

This section presents answers to common questions and problems users might experience when working with NUC.NLM, NetWare, and UnixWare.

Why do I see the uid of "nobody"?

The id of "nobody" is displayed only when there is a user conflict (unless you created a user named "nobody, "which is not recommended). This occurs when the ids stored inthe NFS name space match the ids of your client, but you are notlogged in as the NetWare owner of the file. NUC.NLM knows what your uid and gid are on the UnixWare client, and it does not want you to think you have rights to that file/directory. Therefore it displays the uid and gid of "nobody."
How do I know what mode a volume is in?

The best way to tell if a volume is in the UNIX mode is to create a file from a UnixWare client and check if explicit trustee assignments were granted for the file. If trustee assignments were granted at file creation, the volume is in the UNIX mode. If no trustee assignments were granted, the volume is in the NetWare mode.

Another way to check the mode is to look at the STARTUP.NCF file and/or the UNISTART.NCF file. These files should tell you what mode the volumes were loaded in. Consult your system administration handbook for more details.
Why are volumes always listed as root or nobody?

When a volume is first created, no trustee assignments exist because the NFS name space does not have any entries for the volume. To get the proper entries on your volumes, you need to use chown and chgrpto enter the values into the NFS name space.
Entries appear to be mapped but we don't see any trustee assignments created for the mapped NetWare group. Why?

This is usually caused by not having proper entries in the PASSWD and NFSGROUP files. Check to make sure that an entry is found in both of these files for the user and group in question.
Why doesn't chmod 077 revoke read and write permissions from the owner?

The way NUC.NLM performs the rights mappings is by determining the effective rights of the user/group. In this case the UnixWare client is trying to revoke all rights from the owner and grant all rights to the group and world. From the NetWare side the owner will still have the same effective rights, because of the rights inherited from NetWare groups (see "Rights and Permissions Mapping").
When I chmod a file to 111, why can't I execute the file?

In NetWare there is no equivalent rights mapping to the execute permission (see "Rights and Permissions Mapping"). From NetWare you need the Read right to execute a file, but when you chmod a file to 111 you are revoking the read privileges. To overcome this limitation, you should grant read (r) permission to the file.
I thought I set everything up correctly on my NetWare 4.x server for the NUC.NLM, but I get failures when I try to chmod or chowna file. Why?

This is usually caused by not loading INETDB.NLM on your server. Type load inetdbat the server console. This should correct the problem.
Why can't I access a file from my UnixWare client when I know that I can access it from my DOS client?

The NetWare file system supports reverse inheritance. This means that if a file exists deep within a directory structure and your NetWare user is granted explicit rights to that file,your NetWare user can CD down the directory structure to the file regardless of what rights the user may have in the intervening directories.

Reverse inheritance does not exist in UNIX. A user can only cd into a directory if that user has read and execute permissions in that directory. In the UNIX mode, the NUCFS enforces UNIX access control methods. If you cannot access a file from your UnixWare client, you probably do not have the correct UNIX permissions. Ask your system administrator to grant you the necessary permissions to accomplish this task from UNIX.
Why can't I prevent a UnixWare user from creating trustee assignments on my NetWare machine?

If you have configured a volume to run in the UNIX mode, trustee assignments will be created for the mapped user,the mapped group, and the group EVERYONE (or the bindery context container for NetWare 4.x servers) every time a file/directory is created.

This is to ensure the best integration between UNIX and NetWare. You can prevent new trustee assignments from being changed on a file/directory by revoking the NetWare Modify right on that particular file/directory (see "NetWareRights to UNIX Permission Mappings"). However, trustee assignments at creation time cannot be revoked if a user has the Create right in the directory.
When I chown a file/directory to a particular user, the operation appears to be successful. But when the new owner tries to access the file/directory, she sees the file/directory being owned by "nobody." Why?

This is usually due to changing the owner of a file/directory (via the chown command) to a UnixWare user that is not mapped. Because the user is not mapped, no trustee assignments are created for the file. If a user does not have the Access Control right, NUC.NLM thinks the user is not the owner of the file (see "Ownership Mapping During Lookup").
Can I have two UnixWare clients with the same uid and accessing the same NetWare volume, but being used by two different NetWare users? In other words, can the same uid be mapped to two NetWare users?

With NUC.NLM, there can be only a one-to-one mapping between uids and NetWare users (and also between gids and groups). To avoid problems, enforce unique uids for all UnixWare clientson your network.

Conclusion

By using NUC.NLM, you can provide your UnixWare clients with better UNIX and NetWare integration. NUC.NLM allows you to emulate your NetWare effective rights onto a UnixWare client, with proper UNIX semantics. NUC.NLM makes it possible to run UNIX applications and store UNIX files on a NetWare volume.

This AppNote has shown how NUC.NLM maps ownership and access controls between the NetWare and UnixWare environments. It has also given some configuration examples and recommendations to help network administrators set up a system with NUC.NLM.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.