| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 423.1 | Lexicals in ARCHIVE_USER_DOCUMENT | 51384::BOSMAN | We're just sugar mice in the rain | Wed Apr 08 1992 14:27 | 17 |
| Ok, I will answer my own question.
In the ALL-IN-1 V2.4 script ARCHIVE_USER_DOCUMENT the device for
archiving and the size of the document(s) are retrieved with lexical
functions (F$PARSE and F$FILE). If the user has no privilege to access
one of these an OPCOM message will be generated.
Because the document-size is necessary to check diskquota we have a
potential problem here. Just archive a document (without any privs on)
and GET #FTOTAL to see the document-size (it is 0!).
In ALL-IN-1 V3.0 the new data-set FILE$ is used to get these values.
This works fine for the BLOCK_SIZE, but DEVICE still will generate an
OPCOM message. Can someone explain the difference between these two
behaviours (just to keep our customer happy)?
Thanks in advance, Sjaak.
|
| 423.2 | Parse checks for file existance | IOSG::BENOY | In a state of flux | Fri Apr 10 1992 14:32 | 27 |
|
RE .1
> In ALL-IN-1 V3.0 the new data-set FILE$ is used to get these values.
> This works fine for the BLOCK_SIZE, but DEVICE still will generate an
> OPCOM message. Can someone explain the difference between these two
> behaviours (just to keep our customer happy)?
The reason why file$ gives an opcom message for the device field and
not for block_size is as follows. When file$ is looking for the block
size for the document to archive it will usually have no problems if
the extended attributes of a file are readable by the user calling
file$. That is if the document is accessable by the user, ie is local
or in a shared area, since file$ follows the same rules as other
functions do to access things in the shared area, ie turn on privs.
The device field is returned as a result of an RMS $parse operation,
which by default always does an implicit search to establish whether
the device/directory/file in the file spec string exists. Since file$
always uses the default behaviour for $parse in this case it will
always do an implicit search to verify that the device and directory
exists. Since there is no world access to the archive area directories
the $parse operation will always generate an alarm for this directory.
Does this answer your question ?
-Paul
|
| 423.3 | Partially | UTRTSC::BOSMAN | We're just sugar mice in the rain | Mon Apr 13 1992 08:14 | 6 |
| Paul,
Thanks for the explanation. But, why not turning privs on before the
$parse?
Sjaak.
|
| 423.4 | Security | IOSG::BENOY | In a state of flux | Tue Apr 14 1992 11:52 | 11 |
|
RE .3
> Thanks for the explanation. But, why not turning privs on before the
> $parse?
Because it would give access to extended file attributes that would not
normally be accessable to the user at VMS level. The exception to this
being if a file is in a shared area, then privs are turned on.
-Paul
|