Setting correct permissions for derived objects

Learn how to set permission for derived objects.

If you and other members of your team want to share derived objects (DOs), make sure that your views are configured to create shareable DOs and that the DOs are created with a mode that grants both read and write access to team members. To accomplish this, use either of the following alternatives:

• Set your umask value to 2 in your shell startup file.
• Set the environment variable CCASE_BLD_UMASK to 2 and leave a more restrictive umask value in your .login file or its equivalent (the value 22 is commonly used, which denies write access to group members). When clearmake runs a build script, it performs the following steps:
  1. Saves the current umask value.
  2. Sets the umask value to the value of CCASE_BLD_UMASK.
  3. Creates a shell (if necessary) to run the build script.
  4. Restores the original umask value when the build script (or shell) completes.

  You can set CCASE_BLD_UMASK as a make macro, instead of as an environment variable.

  Note: If you want to use CCASE_BLD_UMASK, do not set your umask value in your shell startup file. If you set the umask value in your startup file, the umask value is reset to its original value in Step 3 when the startup file is read. Setting CCASE_BLD_UMASK in your startup file has no effect.

Other users cannot overwrite and destroy a DO that you are still using, even if you use a CCASE_BLD_UMASK value that grants write access to group members. If your DO has been winked in to another view, and the corresponding makefile target is rebuilt in that view, clearmake first breaks the link to your DO, and then creates a file in that view for the build script to overwrite.

Permissions on DOs affect the extent to which they are shareable:

• When you perform a build, the HCL VersionVault build tool winks in a derived object to your view only if you have read permission on the DO.
• The VersionVault build tool can wink in DOs for which you do not have write permission. But permission denied errors might occur during a subsequent build, when a compiler (or other build script command) attempts to overwrite such a DO. To work around this problem, you can rewrite your makefile to remove the target before rebuilding it. You can also set a policy for how users must set their permissions.

For information about fixing the permissions of DO versions, see the protect reference page.