NetWare 5.1 Administration

Chapter 5: Managing File System Security

 

Objectives:

This chapter takes us into the next layer of security, File System Security. The objectives important to this chapter are listed on page 5-1:

  1. Identify How File System Security Works
  2. Design File System Rights
  3. Design File and Directory Attribute Security
Key Concepts:
Identify How File System Security Works

A user may be assigned rights to files and/or directories. All rights discussed in this chapter are File System rights. DO NOT confuse these rights with NDS rights, which we will discuss later. The rights that may be assigned are described in the chart on page 5-3. Rights are applied to objects in the file system, which has hierarchical levels. Rights that apply at one level are usually passed on to lower levels, or inherited. Let's begin with a description of each:

Supervisor
This right includes all the other seven rights; it allows the user to grant rights to other users, and cannot be blocked by an Inherited Rights Filter (see below).
Read
the right to read the contents of files, and run programs
Write
the right to change or update a file
Create
the right to create new files or directories in a directory
Erase
the right to delete a file or directory
Modify
different from Write; this is the right to rename a file, or change its attributes
File Scan
the right to see files and directories
Access Control
the right to change trustee assignments and IRFs to limit access

We decided in a previous class that the rights could be remembered with the "acronym" WRMFACES (pronounce it "worm faces").

The default rights granted to certain users are described on page 5-4:

  1. A user is usually granted all rights to his/her home directory, except Supervisor. Because of this, the user cannot grant rights to that directory to anyone else.
  2. Some users are given Supervisor rights in the file system:
    • a user who creates a server object, usually an administrator
    • any user who has NDS Supervisor rights to the file server
  3. users in the same container as the SYS: volume get Read and File Scan rights to the SYS:PUBLIC directory

Page 5-5 does not belong in this chapter. It discusses NDS rights that are assigned when a server is created. We will not discuss this page at this time.

A chart of the rights needed by a user to perform certain tasks appears on page 5-6. An odd example is that a user may need W,C,E, and M rights just to edit an existing file. This is because some software products, when editing, actually Create a new temporary file, Write to that file, then Erase the old file, and Modify the new file to have the original filename.

Trustees are introduced on page 5-7. A trustee is any object listed on a directory or file's ACL. The ACL is the Access Control List, which specifies who may have what kind of rights to the directory or file. An ACL is a trustee list. This leads us to ask, how do you get to be a trustee? A User may be placed on an ACL directly, or may be made a trustee through the other objects listed on page 5-9.

  • A User may be on the trustee list.
  • A Group may be placed on the trustee list, and a User may be a member of that Group.
  • An Organizational Role may be placed on the trustee list, and a User is on the Organizational Role's list.
  • A Container may be place on the trustee list, and a User exists inside that Container.
  • The [Public] object may be placed on a trustee list. This grants rights to anything connected to the network, logged in or not.

Inheritance means passing rights from a higher level down to a lower level. See the diagram on page 5-13. The trustee in this diagram is given rights to a directory that has subdirectories. Her rights apply to all subdirectories and files contained by the original directory.

You may, however, block inherited rights. One way is to make a specific assignment of rights at a lower level. The assignment at any level will override most rights that would have been inherited from a level above. A limitation on this is that the Supervisor right may not be blocked by a new assignment at a lower level.

Another method of blocking rights is the use of the Inherited Rights Filter, which limits what rights may be inherited from above. Consider the example on page 5-16. A User is granted R, W, and F rights as a Trustee to the SHARED directory. The ACCTNG directory is a subdirectory of the SHARED directory. DB and REP are child directories of ACCTNG. An IRF placed on the REP directory blocks all inherited rights except S, R, and F.

The User will inherit the R, W, and F rights for the ACCTNG and dB directories. For the REP directory, the W right is blocked. The User inherits only those rights assigned above that are not blocked by the IRF.

The situation is more complex if the the user is a member of a group. In the example on page 5-18, a Group is assigned R, W, C, E, and F rights to the SHARED directory. An IRF is applied to the ACCTNG directory that blocks all but S, R, and F rights. (Note: an IRF can be set to block any combination of rights, except the S right.)

The Group will then have only R and F rights with respect to the ACCTNG directory. A User, EAlder, is a member of the Group. EAlder is made a Trustee of the ACCTNG directory, and granted W and M rights to it. (An IRF does not affect rights that are assigned below it.)

How many rights does EAlder have with respect to the ACCTNG directory? Four: W, M, R, and F. EAlder is personally granted two rights, and also inherits two more, as a member of the Group. This composite group of rights, gained through any and all means, is called the User's Effective Rights.

Design File System Rights

It is preferred to assign rights in a top-down order:

  1. rights needed by every object in a Container are assigned to that Container
  2. additional rights needed by objects in a Group are assigned to the Group
  3. additional rights needed by an individual are assigned to the User object

One person's rights may be set as equivalent to another user's rights. This is meant to be done as a temporary measure, for instance, when someone takes on the work duties of another during the other's short absence. It is dangerous to do this sort of assignment, since the rights no longer exist if the absent worker is deleted.

In general, remember that:

  1. Group rights are additive.
  2. Assigned rights are personal.
  3. Inherited rights pass down, and can be blocked by IRFs, except for the Supervisor right.

To plan the rights that should be given to users, consider the hierarchical diagram on page 5-27. Plan from the top down. We might summarize the rules on this page as:

  • Grant few rights at the top, more at the bottom.
  • Grant no more rights than are needed to a trustee.
  • Use IRFs as necessary to block inheritance.
  • Grant supervisor rights to few users.

The list of priorities on page 5-28 is good to know. Grant rights to users with the following order of methods:

  1. Grant rights to the [Public] object.
  2. Grant rights to containers, and hence, to users in them.
  3. Grant rights to Groups and Organizational Roles, for users in other containers.
  4. Grant additional necessary rights to Users.
  5. Grant Security Equivalence rights to Users who fill in for other Users.
Design File and Directory Attribute Security

The last concept in this chapter is Attribute Security. This is yet another level of security that can override the previous levels. Attributes are specific properties of files and directories. The chart on pages 5-32 and 5-33 lists possible Attributes for files, and the shorter chart on page 5-34 lists possible Attributes for directories. If these Attributes are applied, permissions at other levels are ignored if contradicted.