Clearcase: How do I change the ownership of a view on UNIX and Linux

Answer 1

The following scenario illustrates the steps required to re-protect a view on UNIX and Linux.
Changing ownership of a view requires modification of both the view file system objects and the view database entries to reflect desired ownership.

File System Objects:
The file system objects include the view storage directory files and all view private files stored in the source (.s) directory.

Example: The following scenario uses the view test to illustrate the affects of the changes made.

%cleartool mkview -tag test /home/jdoe/test.vws
Created view.
Host-local path: host1:/home/jdoe/test.vws
Global path: /net/host1/home/jdoe/test.vws
It has the following rights:
User : jdoe : rwx
Group: ccusers : r-x
Other: : r-x

1. Before changing the view permissions, be sure to uncheckout any elements and backup the view to maintain a history of the view-private files to avoid any problems that may occur if a restore is required.

2. End the view_server process for the view you wish to change ownership on using the command:

   cleartool endview -server test

Note: When you list the view again, you should no longer see an asterisk on the far left of the line entry:

~$ cleartool lsview test
 test                /net/host1/home/jdoe/test.vws

1. If you do not have /opt/rational/clearcase/etc/utils in your path, cd to that directory.

2. SU to root and run the fix_prot command as follows:

   fix_prot -r -chown

Note: This utility will change the file system objects within the view storage. It will not change the view database permissions. The fix_prot utility is designed to correct inconsistencies within the VOB/View storage directories (.identity and files) in the event that they become misprotected. Review the related information below for more details about fix_prot.

You will be prompted to confirm; type yes.

~# fix_prot -r -chown user2 /net/host1/home/jdoe/test.vws

1. Check the .identity directory of the view storage to ensure the setuid/setgid bit (sticky bit) is applied:

INCORRECT PERMISSIONS:

~# cd /home/jdoe/test.vws/.identity
~# ls -al
total 8
drwxrwxr-x  2 user2 ccusers 4096 Sep 25 05:02 .
drwxrwxr-x  6 user2 ccusers 4096 Sep 25 10:08 ..
-r----x---  1 user2 ccusers    0 Sep 14 17:24 gid
-r--------  1 user2 ccusers    0 Sep 14 17:24 uid

Modify the permissions on the gid and uid files if needed:

chmod 2410 gid
chmod 4400 uid

CORRECT PERMISSIONS

~# cd /home/jdoe/test.vws/.identity
~# ls -al
total 8
drwxrwxr-x  2 user2 ccusers 4096 Sep 25 05:02 .
drwxrwxr-x  6 user2 ccusers 4096 Sep 25 10:08 ..
-r----s---  1 user2 ccusers    0 Sep 14 17:24 gid
-r-S------  1 user2 ccusers    0 Sep 14 17:24 uid

At this point all the view file system objects have been reprotected and will reflect the ACL of the new owner.

Note: The ownership of the view file system objects is now complete. If there are also view private files, continue with the instructions on changing the view database ACLs for these files.

View Database Objects
If you need to change the permissions of a view private file, it must be done using the UNIX/Linux chown, chgrp or chmod command while set in a view/VOB context.

%cleartool setview test
test(view)%cd /vobs/VOB1
test(view)%ls -l test.txt
-rw-rw-r-- 1 jdoe ccusers 5 Nov 1 10:48 test.txt
test(view)%su
Password:
# chown user2 test.txt

test(view)%ls -l test.txt
-rw-rw-r-- 1 user2 ccusers 15 Nov 1 11:20 test.txt