8 — DCE Distributed File Service

[Previous] [Next] [Contents] [Index]

8.1 Variation from OSF DFS

Gradient DCE for Tru64 UNIX includes DCE DFS from OSF DCE Release 1.2.2. This release does not contain any enhancements for DFS beyond those that are part of OSF DFS. However, there are the following areas of difference:

• The Episode file system is not supported.

• DFS in Gradient DCE for Tru64 UNIX does not include enhanced DFS features such as fileset cloning.

• DFS in Gradient DCE for Tru64 UNIX allows the use of Tru64 UNIX ACLs for authorization purposes.

• DFS in Gradient DCE for Tru64 UNIX relies on Tru64 UNIX built-in file system backup rather than using the backup facility provided with OSF DFS.

For information on how to configure DFS, see the Gradient DFS for Tru64 UNIX Configuration Guide.

The last section in this chapter identifies solutions to some common problems you might encounter using DFS.

8.2 Using Tru64 UNIX ACLs

Tru64 UNIX supports the use of generic ACLs on its two supported filesystems (UFS and AdvFs). The ACLs follow the POSIX model, providing a sequence of ACL entries, each consisting of a tag (type), an identifier for entries whose type requires it, and a set of permission bits.

Table 8-1: Tru64 UNIX ACLs

Tag	Identifier	Permission Bits
user	uid	rxw
group	gid	rxw
user_obj		rxw
group_obj		rxw
other_obj		rxw

ACL entries tagged as user or group identify persons or groups that might attempt to perform some action on the directory or file. The Identifier is a user id (uid) for user tags or a group identifier (gid) for group tags. ACL entries tagged as user_obj, group_obj, and other_obj do not use identifiers because these are implicit in the metadata of the directory or file. (See Note below.) The permissions are the standard UNIX read (r), write (w), and execute (x) permissions.

NOTE: Because DFS in Gradient DCE for Tru64 UNIX maps uids and gids to specific users and groups, password files must be synchronized with the DCE Security registry. Enabling Security Integration Architecture (SIA) offers one way to synchronize uid and gid information with the DCE cell registry.

Default ACLs for containers and objects are created following the same method as in the standard DCE DFS implementation.

8.2.1 Tru64 UNIX ACL Limitations

Tru64 UNIX ACLs lack the following functionality that is available with generic DCE ACLs:

• A set of "foreign" tags supporting users, groups, and objects from foreign cells.

• A set of "delegation" tags supporting delegation from users, groups, and objects in the local cell and in foreign cells.

• An unauthenticated mask controlling access for unauthenticated users.

• A cell name included in ACL identifiers which is used for foreign cell user authentication.

• A wider set of permission bits:
  • (c) control
    
  • (i) insert
    
  • (d) delete
    

An additional limitation of Tru64 UNIX ACLs is that the ACL identifiers are uids or gids instead of full DCE UUIDs.

Gradient DCE for Tru64 UNIX handles these ACL limitations by providing appropriate responses to administrative or user actions that involve Tru64 UNIX ACLs. People or programs that use or administer DFS proceed as normal DCE clients. A transparent translation layer in DCE DFS intercepts and deals with ACL operations.

8.2.2 DCE Responses to Tru64 UNIX ACL Operations

Due to the limitations of Tru64 UNIX ACLs, some operations involving ACLs behave differently or return an error. Specific responses to Tru64 UNIX ACL operations depend on whether the operation is unsupported, totally supported, or partially supported.

Unsupported operations such as adding an entry for foreign_user, or group_delegate return an error.

Totally supported operations such as a user in the local cell requesting write access to a file behave in the standard manner.

Some operations are partially supported. Tru64 UNIX provides appropriate responses to certain operations even though the features for their support is lacking from the Tru64 UNIX ACLs. For example, a user attempts to delete a file from DFS. Normally, DFS requires the d (delete) permission but Tru64 UNIX performs the delete operation if the user has write permission on the file.

8.2.3 Mapping between DCE ACLs and Tru64 UNIX ACLs

The mapping is done by a translation layer between DFS and the underlying physical file system at the server. In other words, none of this work has any bearing on the client portion of DFS.

• There is no space for a home cell uuid, so the server assigns the UUID of the cell that it belongs to as the home cell UUID of any ACL that it deals with.

• No "foreign" ACL entries are possible. The client can submit them, but the cell UUID is dropped before the mapping to a uid or gid is done (the mapping will fail in this case, since the foreign user or group UUID will not be found in the registry of this cell).

• The mapping between principal or group UUIDs on one hand and uid/gids on the other is done by querying the registry of the cell to which the file server belongs. It is assumed that the password files are synchronized with the registry or a scheme like SIA is used.

• The permission bits need to be mapped according to Table 8-2.

  Table 8-2: Mapping Permission Bits

  Tru64 UNIX ACL Bits	DCE ACL Bits
  	file	directory
  r	r	r
  w	cw	cwid
  x	x	x

• DFS simulates a mask_obj tag to satisfy operations that require its presence. However, the simulated mask_obj does not mask any permissions (its permissions are rwxcid).

• The initial_container and initial_object ACLs behave normally.

You can disable the ACL support in the DFS server by setting a kernel global variable using the dbx debugger. After a new kernel that includes DFS support has been built, specify the following:

							cd /usr/sys/conf
			dbx -k vmunix
		patch dfs_acls_enabled = 0
		quit

where conf is the name of the configuration you chose when executing doconfig. After disabling ACL, any remote ACL operations on DFS files return ENOTTY errors.

8.3 NFS-DFS Secure Gateway Server Administration

The NFS-DFS Secure Gateway server does not support the dfs_login and dfs_logout programs. For authenticated access to DFS, users of DCE-unaware NFS clients must authenticate to DCE from the Gateway Server machine using a dfsgw add operation. Refer to the OSF DCE DFS Administration Guide and Reference for information about authenticating from a Gateway Server machine.

8.4 DFS Backup

DFS in Gradient DCE for Tru64 UNIX relies on Tru64 UNIX built-in file system backup rather than using the backup facility included with OSF DFS. Refer to your Tru64 UNIX documentation for instructions on using the Tru64 UNIX file system backup facility.

8.5 Solutions to Common Problems with DCE DFS

Here are solutions to a few common problems that you may encounter with DCE DFS.

8.5.1 Running Commands Requiring the setuid Feature

Commands that use the setuid feature (for example, the ps command) do not execute properly if used from the DFS namespace. Before running the commands, you must enable the setuid functionality on a per fileset basis by issuing the cm setsetuid command. Issue this command on each machine that needs to use these setuid commands after DFS has started, that is, after the system is in multiuser mode. See cm setsetuid(8dfs) in the OSF DCE DFS Administration Guide and Reference for more information.

8.5.2 Running cron Jobs with DCE Credentials

It is often necessary to run jobs asynchronously with DCE credentials. For example, you might run a job after hours that requires access to DFS. One way to have a job running under cron(1) or at(1) acquire DCE credentials is by using the -k option of the dce_login command. This option allows dce_login to acquire credentials by reading a key from a keytab file, rather than by getting a password interactively. Using the -k option along with the -e option, which allows an executable command to be specified on the command line, accomplishes the desired effect.

The solution consists of two parts:

• First, decide on a principal with whose credentials the cron job should run. (Create a DCE user for this, if one does not exist already.) In the following example, the principal is designated with the placeholder princ. Then, as cell_admin, create a keytab file with a command similar to the following:

  dcecp -c keytab create princ.keytab \
               -storage /path/name/of/keytab \
               -data {princ plain 1 password}
  

  Where the password is the same password that was specified when the princ account was created in DCE. You may need the -noprivacy option if you do not have the privacy kit installed on the machine. The keytab file is created with root as the owner and 600 permissions. The ownership of the file has to be changed to the UNIX identity of the executor of the cron job.

• Next, you can add a line similar to the following to a crontab file to have cron run a script with the credentials of principal princ:

  5 20 * * 1-5 dce_login princ -k /path/name/of/keytab \ -e /path/name/of/
  script
  

  to run the indicated script with the credentials of princ at 8:05 p.m., Monday through Friday.

You can verify that the first step above worked by issuing the following command:

dce_login princ -k /path/name/of/keytab -e klist

and making sure that the principal listed is indeed princ.

[Previous] [Next] [Contents] [Index]

To make comments or ask for help, contact support@entegrity.com.

Copyright © 2001 Entegrity Solutions Corporation & its subsidiaries.

Copyright © 1998-2001 Compaq Computer Corporation.

All rights reserved.