Access control for derived objects

A derived object is at first similar to 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 in dynamic views. In addition, the following considerations apply:

• 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 and becomes 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 a 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. The algorithm used by DevOps Code ClearCase 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 algorithm for VOB and view data.
• A winked-in DO has the owner, group, and protection mode it had as a shared DO. If you change a winked-in DO in the view, such as changing its permissions or writing to it, the DO is converted to a view-private copy.