Repairing Storage Directory ACLS on NTFS

We recommend that you use NTFS-formatted disks for holding VOB and view storage directories on Windows computers. NTFS file system objects are protected by security descriptors, which contain ownership information and access control lists (ACLs). FAT file systems do not support ACLs, so objects in FAT file systems can only be protected by the readonly attribute. This attribute is available in both NTFS and FAT, but it is not enforced and can be removed easily.

On NTFS, a VOB or view storage directory’s ownership (its owner and primary group ID) is determined from the security descriptor on the directory root. On FAT file systems, this information is stored in the file identity.sd in the storage directory root. (For compatibility, the identity.sd file is also created on NTFS file systems). On both FAT and NTFS, the file groups.sd holds the supplementary VOB group list.

VOB and View Storage Directory ACLs

Rational ClearCase establishes ACLs for VOB and view storage directories when VOBs and views are created. These ACLs have a particular form that ClearCase relies on. The following example shows the correct ACL for a VOB storage directory, sources.vbs, created by user NT_WEST\ccase_adm, whose primary group is user. The ClearCase administrators group is named clearcase.

Note: As annotated in the example, ClearCase LT uses the built-in LocalSystem identity (NT_AUTHORITY\SYSTEM) wherever ClearCase uses the ClearCase administrators group. On a ClearCase LT server, the name NT_AUTHORITY\SYSTEM would appear where the name clearcase appears in this example. In both ClearCase and ClearCase LT, the first ACL entry (NT_AUTHORITY\NETWORK) is present only on VOB storage directories, not on view storage directories, and is never present when the VOB storage directory is on a NAS device.

cacls c:\vobstore\sources.vbs 
NT AUTHORITY\NETWORK:(OI)(CI)(DENY)(special access:)																		(on VOB storage only)
						DELETE
						FILE_WRITE_DATA
						FILE_APPEND_DATA
						FILE_WRITE_EA
						FILE_WRITE_ATTRIBUTES

NT_WEST\user:(CI)R				 														(VOB’s principal group)
Everyone:(CI)R 
NT_WEST\ccase_adm:(CI)(special access:) 																		(VOB owner) 
						STANDARD_RIGHTS_ALL 
						DELETE
						READ_CONTROL
						WRITE_DAC
						WRITE_OWNER
						SYNCHRONIZE
						STANDARD_RIGHTS_REQUIRED
						FILE_GENERIC_READ
						FILE_GENERIC_WRITE
						FILE_GENERIC_EXECUTE
						FILE_READ_DATA
						FILE_WRITE_DATA
						FILE_APPEND_DATA
						FILE_READ_EA
						FILE_WRITE_EA
						FILE_EXECUTE
						FILE_READ_ATTRIBUTES
						FILE_WRITE_ATTRIBUTES

NT_WEST\clearcase:(CI)F 										(ClearCase LT uses the built-in identity NT AUTHORITY\SYSTEM)
NT_WEST\user:(OI)(IO)(special access:)																		(VOB’s principal group) 
						GENERIC_READ
						GENERIC_EXECUTE

Everyone:(OI)(IO)(special access:)
						GENERIC_READ
						GENERIC_EXECUTE

NT_WEST\ccase_adm:(OI)(IO)(special access:)																			(VOB owner) 
						DELETE
						WRITE_DAC
						WRITE_OWNER
						GENERIC_READ
						GENERIC_WRITE
						GENERIC_EXECUTE

NT_WEST\clearcase:(OI)(IO)F										 (ClearCase LT uses the built-in identity NT AUTHORITY\SYSTEM)
BUILTIN\Administrators:(OI)(CI)F

Preserving NTFS ACLs When Copying a VOB or View Storage Directory

Whenever you copy a VOB or view storage directory to another location in an NTFS volume, or to another NTFS volume, you must use a copy program that preserves the storage directory ACLs.

In most cases, we recommend using the ccopy utility (ccase-home-dir\etc\utils\ccopy) when copying a VOB or view storage directory. Although ccopy copies all of the necessary ACL information, it does not copy the full security descriptor of an object, and therefore effectively grants the user who runs it full access to the copied directory. If someone other than the VOB or view owner is copying a VOB or view storage directory, it may be more appropriate to use xcopy /o or, on Windows NT, scopy instead.

On Windows 2000 or Windows XP, you can use xcopy with the /o option.

Because Windows 2000 and Windows XP allow a directory to inherit ACLs from its parent directory, the copied directory may inherit some entries from the ACL of its parent directory, which can cause problems with VOB and view access.

On Windows NT, you can use the scopy command, from the Windows NT Resource Kit, with the /o option.

Note: When using xcopy or scopy, you must supply any additional options required to copy subdirectories, and you must be logged on as a user with rights to create the directory and set the ACLs on the target host. The Administrators and Backup Operators groups typically have these rights.

After you copy the VOB or view storage directory, run fix_prot –l, as described in Utilities for Fixing Protection Problems, to check the ACLs on the target directory. If fix_prot –l shows any errors, follow the procedures in Fixing Protection Problems to correct them.

Causes of Protection Problems

This section describes typical scenarios that can lead to incorrect storage protections and suggests how to avoid these situations.

Copying the Storage Directory Incorrectly

Converting the File System to NTFS

If you create the storage directory on a disk partition formatted as FAT or FAT32 and later convert that partition to NTFS, the storage directory protection will become incorrect. ClearCase reports a different VOB owner after the conversion. VOB and view servers do not start because the identity.sd file does not agree with the storage directory root’s security descriptor. There is no way to avoid this behavior. For information about correcting storage directory protection, see Fixing Protection Problems.

Editing Permissions

If you edit a file permission, for example, by using Windows Explorer or cacls, ClearCase users will begin having access and protection problems.

Caution: Never click OK in the Windows Explorer File Permissions dialog box if the changes will affect VOB or view storage. Doing so changes the order of access control entries even if you have not changed and file permissions.

where vob-stg-pname is pathname of the VOB storage directory. For information about fixing protection problems caused by editing file permissions, see Fixing Protection Problems. For more information, see the checkvob reference page.

Utilities for Fixing Protection Problems

ClearCase includes three utility programs for finding and fixing VOB and view storage directory protection problems:

vob_sidwalk fixes storage directory protections for schema version 54 VOBs. It can also be used to change ownership on VOB objects. For more information, see the vob_sidwalk reference page.

fix_prot fixes storage directory protections for views and also for schema version 53 VOBs.

lsacl (Windows only) displays NTFS ACLs for file system objects

All of these utilities are installed in the ccase-home-dir/etc/utils directory.

fix_prot

fix_prot [–f·orce] { –root [–r·ecurse] [–recover {–chown user | –chgrp group } | –replace·_server_process_group| [–r·ecurse] [–type { d | f }]
[–chown user] [–chgrp group] [–chmod permissions] } pname …

Options

–type
Specifies the type of file system objects to fix. Use d for directories and f for files. If –type is not specified, fix_prot operates on both directories and files.

–chmod
Specifies the new access rights: owner, group, other (world). Both symbolic and numeric codes are valid, such as go-x (symbolic) or 0644 (absolute).

–recover
(Windows only) Restores correct file system ACLs in a VOB or view storage directory based on the information in the identity.sd and groups.sd files. Not applicable to schema version 54 VOBs, for which vob_sidwalk –recover_filesystem performs this function.

–replace·_server_process_group
(Windows only) Replaces ACL entries for the ClearCase administrators group. Use this option if you have changed the ClearCase administrators group name or have moved a view to a new domain that has a different SID for this group.

Examples

To create a UNIX .identity directory after moving a VOB from Windows to UNIX. The VOB has been moved to the storage directory /vobstg/winvob.vbs. The new owner is vobadm and the new group is ccusers. You must run this command as root.

ccase-home-dir/etc/utils/fix_prot –root –recurse –chown vobadm –chgrp ccusers \
/vobstg/winvob.vbs

To repair ACLs damaged when a view storage directory was copied to NTFS directory C:\ClearCaseStorage\int.vws using a copy utility that did not preserve ACLs:

ccase-home-dir\etc\utils\fix_prot –root –recover C:\ClearCaseStorage\int.vws

To display the protection modes ClearCase associates with the directory E:\vobstg\sources.vbs:

ccase-home-dir\etc\utils\fix_prot E:\vobstg\sources.vbs
drwxr-xr-x MYDOMAIN\me MYDOMAIN\mygroup E:\vobstg\sources.vbs

Note: fix_prot may return an error message that begins with the following text:

fix_prot: Error: unknown style protections on directory: The data is invalid.

If it does, you must rerun fix_prot and specify all of the –chown, –chgrp, and –chmod options and also supply an absolute permissions value, either in numeric or ID=rights (o=rwx) form to –chmod. For example:

ccase-home-dir\etc\utils\fix_prot –chown owner –chgrp group –chmod 0666 pname

lsacl

lsacl [ –s | –l ] [ –n ] { [ –f path-name ] | [ –r registry-value-name ] }

Options:

–s | –l
Specifies short or long format; displays generic rights, by default.

–n
Specifies that the numeric security ID (SID) is not to be translated into the user’s name. Use this option if the domain controller is down or if the user’s account has been removed.

–f
Reads a security descriptor from a file; allows you to display the contents of the identity.sd and groups.sd files.

–r
(Windows only) Reads a security descriptor from a Windows registry value. Specify registry-value-name in the form RootKey\ValueName where:

RootKey is one of HKLM, HKCU, HKCR, HKU, HKCC. HKLM is assumed if RootKey is omitted.

Note: You can also use the Windows cacls utility to display an NTFS ACL, but cacls cannot read a security descriptor from a *.sd file.

Fixing Protection Problems

Log on as a member of the Administrators or Backup Operators group.

If the groups.sd file exists in the storage directory root stg-pname, run this command:

ccase-home-dir\etc\utils\lsacl –f stg-pname\groups.sd

Note the supplementary group list. The following is sample output:

===== stg-pname\groups.sd Owner: NT_WEST\bob (User) (non-defaulted) Group: NT_WEST\usersnt (Group) (non-defaulted) ACL (revision 2): 0: allowed SID: NT_WEST\user (Group) rights (00000000) 1: allowed SID: NT_WEST\tester (Group) rights (00000000) ===== stg-pname\groups.sd Owner: NT_WEST\bob (User) (non-defaulted) Group: NT_WEST\usersnt (Group) (non-defaulted) ACL (revision 2): Empty ACL: all access denied	(Owner) (Primary group) (Supplementary group) (Supplementary group) (Owner) (Primary group) (No supplementary group)

===== stg-pname\groups.sd 
Owner: NT_WEST\bob (User) (non-defaulted)
Group: NT_WEST\usersnt (Group) (non-defaulted)
ACL (revision 2): 
0: allowed 
SID: NT_WEST\user (Group)
rights (00000000)

1: allowed 	
SID: NT_WEST\tester (Group)
rights (00000000) 

===== stg-pname\groups.sd
Owner: NT_WEST\bob (User) (non-defaulted)
Group: NT_WEST\usersnt (Group) (non-defaulted)	
ACL (revision 2):
Empty ACL: all access denied

(Owner)
(Primary group)


(Supplementary group)



(Supplementary group)



(Owner)
(Primary group)

(No supplementary 
group)

Run fix_prot –root to remove the supplementary group list.

ccase-home-dir\etc\utils\fix_prot –r –root –chown owner –chgrp group ^
stg-pname

If you are fixing view storage, you are finished.

If you are fixing VOB storage, log on as the VOB owner and continue.

If the VOB has a supplementary group list, run this command:

cleartool protectvob –add_group group-name[,...] vob-stg-pname

To remove the cleartext containers, run this command:

scrubber –e –k cltxt vob-stg-pname

This step must precede Step 7 because checkvob cannot fix cleartext containers.

To fix the storage pool’s protections, run this command:

cleartool checkvob –force –fix –protections –pool vob-stg-pname