What trustee rights are & how they work

In NetWare, access to directories (folders) and files is controlled by trustee rights assignments. Trustees can be users or groups, the rights can be any combination of specific permissions in the table below, and rights can be set (assigned) to any folder or file on a NetWare server.

Inheritance of Rights
Rights are inherited.

Common Settings & Combinations of Rights
Read only - R F - trustees can read, but not edit, delete, or create files
Full Read/Write - R W C E M F - trustees can do anything (read, write, create, delete, change attributes) but cannot add or remove trustee rights.
Limited Read/Write - R W F - trustees can only read and edit existing files (cannont create or delete files)
Write only ("drop box") - W C - trustees can use Windows Explorer or MacOS Finder to copy files into the folder, but cannot open the folder, see or read files in it, or make any changes to existing files in the folder.

Checking & setting trustee rights

1. Using a Windows 95, 98, or NT computer running the Novell client (Client 32, NetWare Client, or IntraNetWare Client) right click on the directory and choose Properties.
2. Select the "NetWare Rights" (or "IntraNetWare Rights") tab. In a few moments you should see three boxes. The one at the top shows the users and groups who have specific rights to that directory (others may have inherited rights from a higher level in the directory structure and won't appear) and what rights they have. The box in the middle is an Explorer-style view of the NDS directory tree; the box at the bottom indicates your current rights ("effective rights") to the directory (note that you cannot assign rights that you do not have, and you can never assign the Supervisor right in this window (that can only be done with the NetWare Administrator program)).
3. Use the middle box to browse the NDS tree and locate the object (group, user, or NDS context) that you want to have rights to this directory.
   Generally, you will see the NDS context for your workgroup, with the user groups that have been created for your workgroup. If you need to assign rights to an individual user, click on the [-] icon to collapse it, scroll to the "IDs" context and hit [+] to expand it, then open the appropriate branch for the user you are looking for (remember, users are broken up into 9 contexts (ab, cd, ei, j, kl, m, nr, s, tz) based on the first letter of their user name). It may take several seconds to expand the user contexts (there are several hundred objects to read in each context). Shortcut: once the user context is expanded, click once on the first user object listed, then type the user ID you are looking for; as you type, the window will auto-scroll to the first matching entry.
   NOTE: When expanding objects make sure to click on the [+], plus, symbol. Double-clicking on the object itself will make the object a trustee--this has more than once caused an administrator to grant rights to all CWRU users!
4. After locating the specific object, click on it once and choose Add. The object will appear in the top box with a series of small boxes next to the object. By default, R and F will be checked.
5. In the top box, click on the appropriate rights boxes [R W C E M F A] for the object.
6. Click on Apply.
7. Click on OK.

General Considerations

NOTE: The terms folder and directory are synonymous and are used interchangably throught this document.

The first piece of the security pie is physical security. DMS keeps all production servers in climate controlled, card access rooms and with the assistance of Administrative Information Services backs up the servers on a nightly basis.

The second piece is object security. Objects are items stored in the NDS tree. They include things like user accounts, print queues, gourps, etc. The ability to alter NDS object rights and properties (information about an object) is object security. To a certain extent, how these object rights and properties are treated are in the control of the work group administrator. DMS will do its best to advise administrators who suggest changes that may sacrifice the security of your branch of the tree but, will not prevent "open" policies unless such policies. jeopardize the entire tree. In the future, certain object rights will be granted to the work group administrator. For the time being, all objects must be manipulated by DMS or CWRUnet Services (they control the "super user account" that can do all).

The third and often most important piece is rights to the file system, more commonly known as file and directory trustee rights/assignments. File system security to a particular work group lies solely with the department. DMS willensure that others outside of your department will not be able to see your data. After that, who a your department allows access to their data is your responsibility. DMS will not interfere unless it jeopardizes overall system security. As a result, it is your duty as a work group manager to know how to set file system rights and to understand the structure of file system secuirty.

In general, rights should only be granted to the extent that they are necessary to accomplish a required task while still maintaining overall system security.

The following headings cover areas that your need to know.

Directory Trustee Rights Explained

For example, I want the group MyDepartment_Staff.MyDepartment.CWRU needs to be able to be able to see files in folder A, read the files, alter the files and create new files but, not delete the files. I, as ork group manager would grant the group rwcef rights. If I wanted the group to only be able to read, see the file names and place new files in the dorectory without being able to alter existing files, I would grant rcf to the directory.

The most common file system security problem that is encountered is the result of a lack of understanding of inherited rights. Inhereted rights refer to those that your get because you have them somewhere else. The rights flow down the directory tree. As a result if I have rights at the root of a directory, i.e. f:\, I have the smae rights to all subdirectories, i.e. f:\apps and f:\home\xxx5. This is a very important and deceptively easy concept to understand. You can easily and inadvertently give a user or group of users the ability to see and alter sensitive data if you do not fully understand inherited rights.

Since rights flow down the directory structure or tree as it is known, you should grant rights begining a the lowest level in the tree as possible. For example, if group A needs full access to Homes\Memos folder, you should grant them rwecf to Share\Memos. If you were to grant them rwcef to \Homes then they would have those same rights to \Homes\Memos, \Homes\Requisitions, \Homes\Confidential\\Personell\Reviews. The most common mistake is that departments assume that everyone has a private directory that no one else can see but, the group Department_Users (which all departmental users are a member of) has read and file scan rights to the \Department folder. Private directories by default are created as a directory called \Department\Homes\Login_name. Since everyone in the department has read and file scan to \Department, they have the same rights to \Department\Home\User_A, \Department\Home\User_B, \Department\Home\User_C, etc. By default, each user is granted full access (including modify and access control) to his/her "home" or private directory. It is the user or work group administrator that can grant others access to a private or "home" directory.