T.R | Title | User | Personal Name | Date | Lines |
---|
180.1 | Not a simple request | IOSG::TALLETT | Mit Schuh bish hi | Thu Mar 05 1992 19:21 | 26 |
| ================================================================================
Note 33.32 Actual delivery of pending MAIL?? 32 of 40
SHALOT::NICODEM "Who told you I'm paranoid???" 20 lines 4-MAR-1992 18:32
-< Not a simple request >-
--------------------------------------------------------------------------------
� PROFIL is a dataset that you can change, as long as it is your own record,
� (oa$user, oa$profil_vmsusr = key), but all other users' data is protected.
� How do I create a data set that behaves the same way? So that only
� the owner of a record is allowed to change it, (unless the changer
� has all priviledges required).
First of all, this should probably be in a separate note, not a reply
to note 33. However, if this simple answer suffices, then I suppose we can
leave it here.
The answer is that PROFIL is a *very* special dataset -- in more ways
than one. In the first place, it has special parameters associated with it,
which are defined in the BLISS code (including such things as privileges and so
forth). But it's even more than that, since "special" code has been written
throughout the system to put all sorts of other restrictions on the PROFIL
dataset. So if you truly want a PROFIL-like dataset, you've got quite a bit of
work ahead of you.
F
|
180.2 | About the register protection: sufficient with..? | IOSG::TALLETT | Mit Schuh bish hi | Thu Mar 05 1992 19:21 | 30 |
| ================================================================================
Note 33.35 Actual delivery of pending MAIL?? 35 of 40
STKHLM::GYULAI "Simplicity is the first virtue" 24 lines 5-MAR-1992 08:07
-< About the register protection: sufficient with..? >-
--------------------------------------------------------------------------------
About this ENTRY-form specified register and protection:
-----
;;.TYPE;;
ENTRY/MODE=UPDATE/KEY=USER
;;.FILE;;
filespec.dat, USER
;;USER;;
/VALID=<.IF OA$USER = USER THEN OA$VAL_SET_VALID ELSE DISPLAY Not allowed...
.
:
-----
Is this enough?
PROFIL seems to pull a nice trick; by specifying /VALID=<data set-spec>
where that file is protected, you can't really call FORM PROFIL and get
away with modifying other users' profiles.
Would that be both necessary and sufficient, to ensure that no one user
modifies other users' record?
(paranoid, me?) /n
|
180.3 | More... | IOSG::TALLETT | Mit Schuh bish hi | Thu Mar 05 1992 19:22 | 33 |
| ================================================================================
Note 33.36 Actual delivery of pending MAIL?? 36 of 40
SCOTTC::MARSHALL "Pearl-white, but slightly shop-so" 27 lines 5-MAR-1992 11:55
-< More... >-
--------------------------------------------------------------------------------
Hi,
First a correction to your named data:
>> /VALID=<.IF OA$USER = USER THEN OA$VAL_SET_VALID ELSE DISPLAY Not allowed...
Should be:
/VALID=<.IF OA$USER == USER THEN OA$VAL_SET_VALID ELSE DISPLAY Not allowed...
^
^
Second, this protection works if the user accesses the data set using the form,
but not if they do WRITE CHANGE type operations, which bypass the form named
data. You'd need to make sure that no users have CMDPRV (or whatever it's
called), so that they can't execute the commands directly.
To add to the earlier explanation of PROFIL. This is an ordinary entry form,
mapping an ordinary RMS data file, using the ordinary RMS action routines
in ALL-IN-1. HOWEVER, there is a "jacket" routine that is called prior to the
RMS routines, which performs the necessary privilege checks. This works for
both form-access and script-access to the file, and is a small, simple routine.
So if you have access to the Bliss source, it's fairly easy to make your own
protection routine, using this as a template.
Scott
|
180.4 | NOCMD ok, but UDP .FUNC WRITE is hard to stop! | IOSG::TALLETT | Mit Schuh bish hi | Thu Mar 05 1992 19:22 | 6 |
| ================================================================================
Note 33.37 Actual delivery of pending MAIL?? 37 of 40
STKHLM::GYULAI "Simplicity is the first virtue" 0 lines 5-MAR-1992 12:08
-< NOCMD ok, but UDP .FUNC WRITE is hard to stop?! >-
--------------------------------------------------------------------------------
|
180.5 | UDP's in V3.0 can prevent .FU | IOSG::TALLETT | Mit Schuh bish hi | Thu Mar 05 1992 19:23 | 7 |
| ================================================================================
Note 33.38 Actual delivery of pending MAIL?? 38 of 40
LARVAE::JORDAN "Chris Jordan, Digital Services - Offi" 1 line 5-MAR-1992 13:28
-< UDP's in V3.0 can prevent .FU >-
--------------------------------------------------------------------------------
|
180.6 | Moved from 33.* by moderator | IOSG::TALLETT | Mit Schuh bish hi | Thu Mar 05 1992 19:24 | 6 |
|
After fighting for half an hour with PAN, I decided to move
the previous notes the old way, so the authors are wrong. Sorry!
Regards,
Paul
|
180.7 | Rdb/VMS can do this... | SHALOT::DUNCAN | Joe - CIS/EIC Doc. Mgmt. Solution Set Consultant | Thu Mar 05 1992 21:01 | 6 |
| Of course, you could put the data in Rdb, and only give users access to
views that limit access to USER (an SQL keyword that equates to the VMS
user name of the current process). VAX SQL/Relational Access for
ALL-IN-1 would help with getting to the data using entry forms.
Joe Duncan @ OPA
|