Conference azur::mcc

Until someone who knows better comes along, my guess is it 
has to do with targetting notification.

    assign and deassign target should be the only ones requiring write
    access to the instance database.  The only thing I am unsure of
    is when you do a read using the mcc_mir routines does it automatically
    open it for write regardless of the fact that it is a read request?
    
    But notification services are the only one who access that database.
    

    The mcc_mir_ routines do open repositories as Read/Write.  The
    DNS Local MIR routines use private routines to specify read-only
    and read-write repositories, so they do not have this problem.
    If targetting is a security issue, then we need to investigate
    the use of the targetting database, and whether it should also
    use read-only repositories.
    
    -Matt.

    In the real world, I suspect that this would not be much of an issue...
    
    It's really not a big issue for us either,....only a curiosity.  We
    have created an on-line DECmcc demo capability and want to allow wide
    access, however, we don't want users to be able to modify databases.
    
    To much effort is involved in creating maps and setting up the
    environment.  
    
    In the real world, it might become an issue if either multiple users
    have full access or many users have limited access.  If the later, it
    would then become, or should become no more than an annoiance.  
    
    Perhaps someone else would have another opinion....
    
    IN either case, thanks very much for the additional information.
    
    Al
    

If what you want is a DEMO system, then do what the DECmcc demo kit does
and clone the MIR's and MAP files, and define some logicals so everything
works right. and who cares if if the files get changed.  Then, when you have
a new MIR/Map that you want available to the demo, just trash the old
demo files and replace them with the new ones.  You can play with alarms,
add entities to the map, play lots of games, and it does not disrupt
your production environment at all.

RE.: .3 
/ The mcc_mir_ routines do open repositories as Read/Write

I experienced the following on this subject (BMS V1.2.3) as a "Read only user":


FCL> DIR TARGET DOMAIN * or as well the equivalent IMPM command 
--> Read/Write access violation on MCC_TARGET_*_MIR.DAT files

FCL> SHOW DOMAIN domainname RULE * ALL CHAR or as well the equivalent IMPM 
command 
--> Read/Write access violation on MCC_ALARM_*_MIR.DAT files

IMPM command GRAPH STATISTICS 
--> Read/Write access violation on MCC_PA_*_MIR.DAT files

FCL> SHOW RECORDING class * PARTITION=*,IN DOMAIN=domainname 
--> Read/Write access violation on history files

TSAM GETCHAR utility
--> Read/Write access violation on MCC_TS_AM_*_MIR.DAT files



Beside the above mentioned examples there are a lot of unseen Read/Write
accesses which keeps the audit process busy!! 

here is just an example:

DCL>MANAGE/ENTERPRISE/INERFACE=DECWINDOWS  
--> Read/Write access on MCC_DNS_*.DAT files

Summary: creating a DECmcc "Read only account" using the local MIR is almost 
not possible.

I would like to see a remark in the release notes regarding nonprivileged user
accounts and Local MIR/DECdns disadvantage/advantage.


				Roland


				 

    The MIR code I just looked at attempts to open repository files
    read/write, and then if that fails do to a privilege problem, tries
    again read-only.
    
    This was Ultrix MIR code.  Is this only a VMS MIR problem?
    

    Jim,
    
    Since the original note was for VMS, I assumed that we were discussing
    the VMS MIR.  Failing over to Read-only access on the file open sounds
    reasonable for the VMS implementation.  I'll QAR it.
    
    -Matt.