| I'm sure you know that emtying the wastebasket doesn't necessarily
delete the file, if it's in the mail shared areas, unless there are no
other people sharing it.
I've always understood that high water amrking is quite expensive in
performance terms, but I think this is less so in later versions of
VMS. However high water marking will not be the full story in your
case, since it will only prevent someone seeing a bit of an old
document on the end of a newly created RMS file. If you want the old
blocks on the disc to be totally overwritten, your only choice is to
turn on the erase on delete option that Terry mentioned.
If you could get to the delete command that actually deletes the
document when the wastebasket is emptied or the janitor runs, then you
could add the /ERASE (in DCL terms) qualifier to the delete, but since
the delete is in BLISS (I'm pretty sure!) you can't!
Perhaps we need a requirement to have a symbol somewhere that would
control whether we did this in the code?
Graham
|
| Both operations - high water marking & erase on delete - are very
expensive in terms of performance , without going into technical
details.
If a customer is satisfied (!?!) with the performance of his present
ALL-IN-1 system, implementing one of the two options will need setting
his expectations accordingly (question is never repeated once you tell
them it affects performance).
What does he want to protect his data from ?
In ALL-IN-1 environment most of the users are CAPTIVE. Assuming you get
to DCL, one needs fairly advanced knowledge of the file-system structures
to get to deleted documents in ALL-IN-1 terms & data-in-files on VMS level.
Ajay.
|
| > What do they want to protect?
Verrrrry interesting. This gets real confusing, but one of their
people said he was able to read messages sent to other users. When I
questioned him about this, he claimed he was given a regular,
non-privileged ALL-IN-1 account, on top of a non-privileged VMS
account.
A number of mail messages were sent to him by another user. Now these,
it seemed, came from SprintMail into ALL-IN-1, in batch mode.
He ran a program called "DOCDB", (yes!), and began looking at the
messages he received. He said the filenames were cryptic, but
sequential, as:
GZYYB1024
BLTTA1025
RDVXX1030
He couldn't remember just what the names were, only that they had
numbers on the end. Looking at that list, he knew that there were mail
messages between 1025 and 1030. Using the FORM that DOCDB provided
him, he changed the numbers in the filename, and was able to read
messages 1026-1029.
I said I'm familiar with DOCDB.DAT, a data file, but had never heard of
an executable called DOCDB.
Anyway, when we challenged him about this, (I wanted to SEE it!), he
said, oh all that stuff had been removed some time ago as a security
threat....
We're still investigating.
Very weird, yes?
Anyway, the perception was gained that ALL-IN-1 was not very secure.
Interestingly enough, when the issue of Encryption came up, the head of
security did balk somewhat, because of management and performance
issues.
We continue to try to get to the bottom of the DOCDB thing, and to
assure them of the innate security of ALL-IN-1 messages.
John
|
| There was (!!!) a package that did document encryption in the Office
ASSETS Library. It was retired last September. However, the sources
may still be available through an exception process from the Digital
Solutions Library. If not, the author may still have them.
Check topic 505 in the old Office ASSETS conference now residing at
HORUS::OASSETS.
Note: due to incorporating an encryption algorithm, this package was
export restricted. Don't mean you can't strip the existing algorithm
and supply your own tho.
Good luck,
David
|