Conference orarep::nomahs::repository

    
    If the user has SYSPRV they're okay. I've asked the customer
    to set audit alarms for file and acl failure.
    
    Steve

    Hi Steve,
    
    What is the result and the difference between VAX and Alpha of a 
    CDO SHOW PROTECTION FOR REPOSITORY ?
    
    Patrick

    
    Hi Patrick,
    
    Thanks. Unfortunately the vax system has cdd 4.3 compared to the axp
    which has 6.1. So now dictionary/repository protection comparison.
    
    They switched on audit/alarms for file-access and acl failure and
    nothing showed up. Yet it definitely is a security problem.
    
    I've decided to send them 6.1 eco 3 for the hell of it. Clutching
    at straws I guess.
    
    Could the cobol interface into cdd be at fault?
    
    regards,
    Steve

    I had the exact same problem. We tried everything, opened everything
    up, set every flag, did a set watch/files ect. w/ bypass on there was
    no problem but with it off and everything opened up, no luck.
    
    In the end, the customer decided to rmu/backup cdd$database.rdb,
    delete everthing in the direcotry, then restore the cdd$database.rdb
    and do a VERIFY/REBUILD...and the problem went away. ?????
    Maybe an ACL definition got hosed and in bypass there was no check
    for it? 

    Along these same lines, during the compile we noticed that an attach
    was done on the compatibility dictionary before it attached to the 
    dictionary where the dbms schema was. There were no links. Anyone know
    why this is?

    Hi Jay,
    
    does it happen only on programs having DBMS database ? I suspect an
    access can be done in this case for compatibility reason to access
    metadata in DMU format. Otherwise , maybe DBMS need to attach first to
    a repository to map its protocols and it uses to do it on
    CDD$COMPATIBILITY.  
    
    Hope this helps.
    
    Patrick   
    
    PS: What has changed in protection after the VERIFY/REBUILD inside CDO
    ( especially for the repository ) and outside ( VMS ACLs )?
                                                               

    Hi,
    
    /   does it happen only on programs having DBMS database 
    
    Not sure, but i will test it. i'm just curious, but i think your
    explanation pretty much answers the question. Something we are going
    to have the customer try is to turn on file auditing and give the
    compile a shot. Gary here thinks the problem is something about cdd.dic
    or the dir that it is in.

This entry is referenced in bug # 473799

  Note:  this might be related to bug 469152 and discussed in note 1072.


Versions:  CDD 6.1-03 and 7.0


SYMPTOM:

A nonprivileged user tries to compile a Cobol program that references a
DBMS subschema.  The compile fails with this error:

   %COBOL-F-CDDACCERR, *Error in accessing subschema - DB statement ignored
   -CDD-W-NODNOTFND, directory or object not found

The user can successfully excute these DBO commands:

   $ dbo/report cdd$default
   $ dbo/extract/subschema=...

If the process is given BYPASS privilege, then the compile works.


WORKAROUND:

Instead of giving the user account BYPASS privilege, you can change the
CDD protection for the repository to give the user control access.  Then
the nonprivileged user can successfully compile with the subschema.


ANALYSIS:

Here is an example that demonstrates this problem.

The user accounts, user1 and user2 only have TMPMBX and NETMBX privileges

Log in to the user1 account and create the CDD repository and define
the schemas.

  $ define cdd$default sys$sysdevice:[user1.cdd]
  $ mcr cdo
  define dictionary cdd$default.
  exit
  $ dbo/create/import=SYS$COMMON:[SYSTEST.DBM]dbmparts.dbm/alloc=1/block=1 -
    /nospace parts/log
  $ dbo/intergrate parts.roo/path=cdd$default
  $ cobol sys$common:[systest.dbm]dbm$sampcob.cob
  $! give world read access the the user1 directory
  $ set security/prot=(w:r) [-]user1.dir

Now log in to the user2 account and try compiling the cobol program

  $ define cdd$default sys$sysdevice:[user1.cdd]
  $! The following dbo commands work
  $ dbo/report cdd$default
  $ dbo/extract/subschema=partss5 parts
  $! The following compile fails
  $ cobol sys$common:[systest.dbm]dbm$sampcob.cob

          DB PARTSS5 WITHIN PARTS.
  ...........^
  %COBOL-F-CDDACCERR, *Error in accessing subschema - DB statement ignored
  -CDD-W-NODNOTFND, directory or object not found
  at line number 151 in file SYS$COMMON:[SYSTEST.DBM]DBM$SAMPCOB.COB;2

Now log in to user1 and change the protection for the repository, adding
control privilege for the identifier [*,*].

  $ mcr cdo
  ! first find the position for the identifier [*,*]
  show protection for repository cdd$default
  change protection for repository cdd$default 
  position 2 access control.    ! use the correct position number
  exit

Now user2 can successfully compile the cobol program.

    Thanks but CONTROL access didn't help me customer. 
    
    cheers,
    
    Steve

    
    I really believe if you don't have the vms prvilege no matter what
    cdd protection you set isn't going to help.
    
    The only workaround I have so far is to install cobol with
    /priv=sysprv.
    
    So is this a cdd bug or a cobol(+cdd interface) bug?
    
    cheers,
    
    Steve