| You can make the user a read-only user in terms of the operations
available to him through the "Operations" menu and the FCL, SHOW and
DIRECTORY only, for example. It does take some work, however.
The MM Programming Guide describes in detail how to create a "developer's
dictionary". Read Chapters 3(VMS) and 4(ULTRIX). You would use the
same mechanism to make a special "read-only" copy of the dictionary for
a restricted user. A quick description of what must be done is set out
below.
You must make a copy of the dictionary in some temporary work area. Use
DAP ($ manage/tool/dict or csh> mcc_dap) to remove all non-read
directives from EACH class in the dictionary. You want to make sure you
do not remove important directives like NOTIFY, GETEVENT, DIRECTORY,
SHOW, etc.. I would suggest that you carefully remove only directives
like SET, DEREGISTER, DISABLE, ENABLE, CREATE, DELETE, etc.
When you exit from DAP, new parse tables that go with the new dictionary
will be built. Move the dictionary and parse tables to a public place.
As defined in MM Programming Guide - Chapters 3 and 4, in whatever file
runs when the user logs in, you define
. on VMS a logical, MCC_SYSTEM, that is a search list that looks in
the directory where the new dictionary is first and then
MCC_SPECIFIC and then MCC_COMMON.
$ DEFINE MCC_SYSTEM dua0:[mcc], mcc_sprcific, mcc_common
. on ULTRIX an environmental variable, MCC_SYS_LOCATION, that
points to the directory where the new dictionary is
csh> setenv MCC_SYS_LOCATION /usr/new_mcc
This points the DECmcc user at the new dictionary and, since the action
directives are not in the dictionary/parse table, they should not be
able to take any destructive action.
Good Luck,
...kjn
|
| .1 has the hard way of doing it. The direct approach seems much more
reasonable.
1. Use DNS.
2. Configure DNS protections to limit the users access
Not only can you make some parts of the tree read-only for
specific users, , but you could set up
other parts of the tree as read/write and yet others as no access at all.
Dont muck with the dictionary. All you would be doing is asking for problems.
|
| >
> -< Use simple, direct approach >-
>
Har har har! You crack me up, Dave!
DNS? Simple? Direct? Stop it! You're killing me! Oooh!
;^)
Seriously, KJ is right: DNS has no effect on the dictionary portion of the
MIR, only the instance repository.
/doug ;^)
|