|
|
Views mediate user access to ClearCase elements and versions. Like VOBs and objects within VOBs, views participate in access control. In a dynamic view, permissions on elements and versions interact with permissions on views and view-private files or directories to control access to both VOB and view data.
For example, you must check out a version of an element to modify the element. The element must grant permission to check out a version. In a dynamic view, checking out a version creates a view-private file. You must have permission to create the view-private file in both the view and the directory that contains the file. The containing directory, in turn, can be either an element version or a view-private directory.
In general, access to ClearCase data in a dynamic view requires a process to pass a series of tests:
It must have access to the view.
It must have access to the containing directory.
It must have access to the element.
In a snapshot view, native file-system permissions on the snapshot view directory tree determine access to files and directories in the snapshot view, including copies of element versions. Creating, deleting, and modifying elements in a snapshot view require the process to have the appropriate permissions for those elements.
NOTE: On UNIX hosts, ClearCase treats view access requests from a remote root user as requests from the user nobody.nobody. See Restricted Privileges for Remote root for details.
A dynamic view has these properties that are important for access control:
Owner. The initial owner is the user of the process that creates the view.
Group. The initial group is the primary group of the process that creates the view.
Protection mode. The initial protection mode for a view is determined one way on UNIX hosts and another way on Windows hosts.
On Windows, a view initially has read, write, and execute permission for the owner and group, and it has read and execute permission for others. You can use the Properties of View dialog box to display the owner, group, and protection mode for a view. You cannot change the owner and group after the view is created. You can use the chview command to change the protection mode to read/write or read-only.
On UNIX, the initial protection mode depends on the umask of the user who creates the view. A umask is a UNIX setting that specifies that some permissions are not granted when the user creates a file. (For details, see the umask(1) reference page.) When a user creates a view, ClearCase begins with read, write, and execute permissions for all users and then removes the permissions specified by the user's umask. For example, if the user's umask is 002, ClearCase removes write permission for others.
To locate the view storage directory and display the owner, group, and protection mode for a view, use the cleartool lsview command with the -properties and -full options:
cleartool lsview -properties -full my_view * my_view /net/myhost/views/myview.vws
.
.
.
Owner: sue : rwx (all)
Group: clearusers : rwx (all)
Other: : r-x (read)
Use the UNIX ls command to list the view storage directory:
cd /net/myhost/views
ls -ld myview.vws
drwxrwxr-x 6 sue clearusers 512 Nov 10 11:29 myview.vws
The output of this command shows the view's owner (sue), group (clearusers), and protection mode (drwxrwxr-x). Depending on your UNIX system, you may need to use ls -g to view the group.
Only the view owner or the privileged user can delete a view.
A process must have read permission for both a dynamic view and a file or directory in the view to read the file or directory. To read a version of a file or directory element, the process must have read permission for the element. See Permission to Read Elements. To read a view-private file or directory, the process must have read permission for the view-private file or directory. See Permission to Read View-Private Files.
ClearCase uses an algorithm that considers the process's user and group and the view's owner, group, and protection mode to determine whether to grant read permission for a view. See Access to ClearCase Data.
A process must have write permission for a view to perform some operations that change the view itself, such as setting its config spec.
A process must have write permission for both a dynamic view and a containing directory in the view to create or delete a file or directory in the containing directory. If the containing directory is an element version, the process must have write permission for the element. See Permission to Write Elements. If the containing directory is a view-private directory, the process must have write permission for the view-private directory. See Permission to Write View-Private Files.
ClearCase uses an algorithm that considers the process's user and group and the view's owner, group, and protection mode to determine whether to grant read permission for a view. See Access to ClearCase Data.
A process must have execute permission for both a dynamic view and a file or directory in the view to execute the file or directory. To execute a version of a file or directory element, the process must have execute permission for the element. See Permission to Execute Elements. To execute a view-private file or directory, the process must have execute permission for the view-private file or directory. See Permission to Execute View-Private Files.
ClearCase uses an algorithm that considers the process's user and group and the view's owner, group, and protection mode to determine whether to grant execute permission for a view. See Access to ClearCase Data.
This section discusses access control for view-private files in dynamic views. In a snapshot view, native file-system permissions on directories and files in the snapshot view directory tree determine access to those directories and files.
In a dynamic view, the initial owner, group, and protection mode for a view-private file are determined differently on UNIX and Windows.
On UNIX, the initial owner, group, and protection mode for a view-private file are determined using the following rules:
Owner. The initial owner is the user of the process that creates the file or directory.
Group. The initial group is the primary group of the process that creates the file or directory.
Protection mode. The initial protection mode for a view-private file depends on the umask of the user who creates the file or directory. A umask is a UNIX setting that specifies that some permissions are not granted when the user creates a file. (For details, see the umask(1) reference page.) When a user creates a view-private file or directory, ClearCase begins with a set of permissions that depend on how the file or directory is created. ClearCase then removes the permissions specified by the user's umask. For example, if the user's umask is 002, ClearCase removes write permission for others.
You can use the cleartool describe command or the UNIX ls command to display the owner, group, and protection mode for a view-private file or directory. You can use the UNIX chown command to change the owner, the chgrp command to change the group, and the chmod command to change the protection mode.
On Windows, the initial owner, group, and protection mode for a view-private file are determined using the following rules:
Owner. The initial owner is the user of the process that creates the file or directory.
Group. The initial group is assigned in one of two ways based on the group of the process that creates the file or directory:
If the process's primary group is the same as the VOB's group, that group is assigned.
Otherwise, the process's group list is compared with the VOB's supplementary group list and the first group that appears on both lists is assigned.
Protection mode. A view-private file or directory initially has read, write, and execute permission for all users.
You can use the cleartool describe command to display the owner, group, and protection mode for a view-private file or directory. The ClearCase > Properties of File or ClearCase > Properties of Directory dialog box displays the owner and group. The Read-only check box in either dialog box indicates whether all users have write permission.
You cannot change the owner or group of a view-private file or directory. You can use the Read-only check box in the ClearCase > Properties of File or ClearCase > Properties of Directory dialog boxes or the attrib +R and attrib -R commands to specify whether all users have write permission. You cannot change any other permissions.
A process must have write permission for both the view and a containing directory in the view to create a file or directory in the containing directory. For view permissions, see Permission to Write Views.
If the containing directory is an element version, the process must have write permission for the element. See Permission to Write Elements. If the containing directory is a view-private directory, the process must have write permission for the view-private directory. See Permission to Write View-Private Files.
A process must have write permission for both the view and a containing directory in the view to delete a file or directory in the containing directory. For view permissions, see Permission to Write Views.
If the containing directory is an element version, the process must have write permission for the element. See Permission to Write Elements. If the containing directory is a view-private directory, the process must have write permission for the view-private directory. See Permission to Write View-Private Files.
A process must have read permission for both the view and a view-private file or directory in the view to read the file or directory. For view permissions, see Permission to Write Views.
ClearCase uses an algorithm that considers the process's user and group and the view-private file or directory's owner, group, and protection mode to determine whether to grant read permission for the file or directory. See Access to ClearCase Data.
A process must have write permission for both the view and a view-private file or directory in the view to write the file or directory. For view permissions, see Permission to Write Views.
ClearCase uses an algorithm that considers the process's user and group and the view-private file or directory's owner, group, and protection mode to determine whether to grant write permission for the file or directory. See Access to ClearCase Data.
A process must have execute permission for both the view and a view-private file or directory in the view to execute the file or directory. For view permissions, see Permission to Write Views.
ClearCase uses an algorithm that considers the process's user and group and the view-private file or directory's owner, group, and protection mode to determine whether to grant execute permission for the file or directory. See Access to ClearCase Data.
A derived object (DO) is a file created in a dynamic view by clearmake or during a clearaudit session. These commands do not create derived objects in snapshot views.
A derived object is at first like a view-private file. You must have the same permissions to create a DO as to create a view-private file. A DO has an owner, group, and protection mode, determined initially in the same way as those of a view-private file. See Access Control for View-Private Files.
A shareable derived object is one that other dynamic views can use by winking in the DO. When a shareable DO is winked in for the first time, it is promoted from the view in which it was created to become an object in the containing VOB. This VOB object is a shared DO.
A shared DO has an owner, group, and protection mode. The owner and group are initially those of the shareable DO at the time it is promoted to the VOB. The group of a shareable DO must be one of the VOB's groups for the DO to be promoted to the VOB.
A shared DO's owner, the VOB owner, or the privileged user can use the cleartool protect command to change the DO's owner, group, or protection mode.
A process that winks in a shared DO to a dynamic view must have read permission for the DO. ClearCase uses an algorithm that considers the process's user and group and the DO's owner, group, and protection mode to determine whether to grant read permission for the DO. See Access to ClearCase Data.
A winked-in DO is like a copy-on-write view-private file in the dynamic view that winks it in. It has the owner, group, and protection mode of the shared DO. If you change a winked-in DO in the view, such as changing its permissions or writing it, ClearCase converts the DO to a view-private copy.
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
