Topic
  • 2 replies
  • Latest Post - ‏2013-08-29T15:27:01Z by BoeBrian
BoeBrian
BoeBrian
25 Posts

Pinned topic VOB fix_prot and everybody permission

‏2013-08-27T17:59:47Z |

Environment: Windows 7 64-bit and ClearCase 7.1.1.3.

 Why does mkvob and fix_prot apply the Active Directory group EVERYBODY? How do I control access permissions better than I am doing?

 We have lots of Windows VOBs which use Active Directory groups to control access to the root of each VOB. All these groups are rolled up to one master group. User use this master group in their CLEARCASE_PRIMARY_GROUP. It works like this.

 We have the groups:

   NW\CASCADE_BOE_BOE containing users working on Project A and giving access to VOB-A

   NW\CC_Sup1 containing users working on Project B and giving access to VOB-B

   NW\CC_Sup2 containing users working on Project C and giving access to VOB-C

 And the master group: NW\cascade which contains NW\CASCADE_BOE, NW\CC_Sup1 and NW\CC_Sup2.

 All the users belonging to the company belong to NW\CASCADE_BOE. Subcontractors belong to either NW\CC_Sup1 or NW\CC_Sup2. Company users are allowed to see and work in all VOBs. Subcontractors are only allowed to see the subset of the VOBs controlled by their associated group.

 All users do their work using NW\cascade as their CLEARCASE_PRIMARY_GROUP so they do not have to change its value as they jump back and forth between their different projects and so the working group is the same for both company users and for subcontractors.

 When I create a VOB it is created with the AD groups:

  • Group: EVERYBODY with Read & execute, List folder contents and Read permissions
  • Group: NW\NW\cascade with the same permissions as EVERYBODY
  • User: NW\vobadm with Modify, Read & execute, List folder contents and Read permissions
  • Group: NW\CCADM (Company ClearCase admins) with Full control permissions
  • Groups: SERVER\Administrators with Full control permissions

 These permissions give the world access to the VOB storage folder and the ability to mount and use the VOB, which is not what we want. We want just the company users (NW\CASCADE_BOE) to have access to the VOB and none of the subcontractors to have access.

 The ClearCase properties are in the attached file: New_VOB_Properties.txt.

 To repair this, I use Windows to edit the Properties (Security) of the VOB storage folder (fil-nw\vob07\cascade\boeing\vobs\bbjunk.vbs) to remove EVERYBODY and NW\NW\cascade, and to add NW\CASCADE_BOE with Modify permission.

 So far so good. Company people can access the VOB and perform checkout and in. Subcontractors cannot access the VOB (access denied).

 But if I try removing the VOB using rmvob, I get the errors:

M:\>ct rmvob \\fil-nw\vob07\cascade\boeing\vobs\bbjunk.vbs
Remove versioned object base "\\fil-nw\vob07\cascade\boeing\vobs\bbjunk.vbs"?  [no] y
cleartool: Error: unknown style protections on \\fil-nw\vob07\cascade\boeing\vobs\bbjunk.vbs: The data is invalid.
If the object is in the VOB's source or derived object pool, please fix it
with "cleartool checkvob -protections -pool".
For other VOB objects, please fix it with "cleartool protectvob".
Otherwise, please fix the storage directory with
  "%CLEARCASEHOME%\etc\utils\fix_prot".

cleartool: Error: Unable to rename versioned object base storage directory "\\fil-nw\vob07\cascade\boeing\vobs\bbjunk.vbs" prior to deleting it. Possible causes:
- The VOB may still be in use by users or ClearCase server processes. (Try removing the VOB later.)
- The protection of the VOB storage directory or its parent directory may prohibit renaming. (You must have "write" permission to the parent directory and full permission to the VOB storage directory).

cleartool: Error: Versioned object base "\\fil-nw\vob07\cascade\boeing\vobs\bbjunk.vbs" not deleted.
cleartool: Error: Trouble removing versioned object base "\\fil-nw\vob07\cascade\boeing\vobs\bbjunk.vbs".

Following the suggestions, I ran checkvob. I may be missing something, but nothing jumps out at me being wrong. The checkvob output is attached.

Unfortunately I cannot include the "-fix" keyword, not can I run protectvob. I am not allowed to log directly onto the server console.

So I run fix_prot as follows:

C:\Program Files (x86)\IBM\RationalSDLC\ClearCase\etc\utils>fix_prot -root -r -chown nw\cvobadm -chgrp nw\cascade \\fil-nw\vob07\cascade\boeing\vobs\bbjunk.vbs
CAUTION! This program reprotects every file and directory in a storage directory tree and should be used only when the protection has been damaged (e.g., through the process of copying the tree or by direct manipulation through a tool like the File Manager/Explorer).
Re-protect "\\fil-nw\cascade\boeing\vobs\bbjunk.vbs"?  [no] y
Protecting "\\fil-nw\cascade\boeing\vobs\bbjunk.vbs\s\sdft"...
Protecting "\\fil-nw\cascade\boeing\vobs\bbjunk.vbs\s"...
Protecting "\\fil-nw\cascade\boeing\vobs\bbjunk.vbs\d\ddft"...
Protecting "\\fil-nw\cascade\boeing\vobs\bbjunk.vbs\d"...
Protecting "\\fil-nw\cascade\boeing\vobs\bbjunk.vbs\c\cdft"...
Protecting "\\fil-nw\cascade\boeing\vobs\bbjunk.vbs\c"...
Protecting "\\fil-nw\cascade\boeing\vobs\bbjunk.vbs\admin"...
Protecting "\\fil-nw\cascade\boeing\vobs\bbjunk.vbs\db\logs"...
Protecting "\\fil-nw\cascade\boeing\vobs\bbjunk.vbs\db"...
Protecting "\\fil-nw\cascade\boeing\vobs\bbjunk.vbs"...
Reprotection complete.

 Now the permissions are back where I started, with EVERYBODY and NW\CASCADE being back on the folder and NW\CASCADE_BOE missing. But I can delete the VOB.

 What am I doing wrong?

Why is EVERYBODY given access?

Is there a better way that I can do this?

 

Thank you.

 Don't Panic! Brian Bygland
The Boeing Company - CATIA ClearCase Support

  • GKellner
    GKellner
    259 Posts
    ACCEPTED ANSWER

    Re: VOB fix_prot and everybody permission

    ‏2013-08-29T11:17:29Z  

    If it is better I don't know, but we do the following:

    Every VOB is stored in an extra directory.

    We don't change the permissions of the .vbs directory, but we can control the access rights via the parent directory.

    It lloks like:
    \\server\vobs\vob_a\vob_a.vbs
    \\server\vobs\vob_b\vob_b.vbs ...

     

    greetings georg, who never tried to manipulate the access rights on *.vbs.

  • GKellner
    GKellner
    259 Posts

    Re: VOB fix_prot and everybody permission

    ‏2013-08-29T11:17:29Z  

    If it is better I don't know, but we do the following:

    Every VOB is stored in an extra directory.

    We don't change the permissions of the .vbs directory, but we can control the access rights via the parent directory.

    It lloks like:
    \\server\vobs\vob_a\vob_a.vbs
    \\server\vobs\vob_b\vob_b.vbs ...

     

    greetings georg, who never tried to manipulate the access rights on *.vbs.

  • BoeBrian
    BoeBrian
    25 Posts

    Re: VOB fix_prot and everybody permission

    ‏2013-08-29T15:27:01Z  
    • GKellner
    • ‏2013-08-29T11:17:29Z

    If it is better I don't know, but we do the following:

    Every VOB is stored in an extra directory.

    We don't change the permissions of the .vbs directory, but we can control the access rights via the parent directory.

    It lloks like:
    \\server\vobs\vob_a\vob_a.vbs
    \\server\vobs\vob_b\vob_b.vbs ...

     

    greetings georg, who never tried to manipulate the access rights on *.vbs.

    I like it. That would solve a number of issues. Great suggestion.

    I have been stongly told by IBM that touching the ACLs of the .vbs folder is a bad no-no. I'll be working on implementing something like you suggest.

    Thank you

    Brian