HP3000-L Archives

September 1997, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Wed, 10 Sep 1997 18:51:33 CDT
Content-Type:
text/plain
Parts/Attachments:
text/plain (50 lines)
Hi, Jeff.

Way back on Wed, 3 Sep 1997 11:41:21 -0700, Jeff Vance wrote:
|way back on Aug. 19 Jon Backus wrote:
|>      In the past I was able to copy databases through a DS line by
|> specifying the FCODE (-400 and -401).  Now I would like to do the same basic
|> function through an FTP connection.  Does anybody know how to do this or if
|> it can even be done?  I am currently at MPE/iX 5.0 on both ends of the
|> connection.
|
|        With the FTP-I patch (FTPEDR3 in 5.5)
|        you can transfer PRIV files through get and put.
|        With DSCOPY you need to specify the file code, but with FTP
|        it is not necessary.  If you need more info please contact
|        Arun G. at: [log in to unmask]


Don't both of these mechanisms open potential security holes?  I know it's
been a few years since I did much Image development, but I thought I knew
it pretty well when I did.  As I recall, Image provides additional security
layers on top of that found in the MPE file system allowing the database
creator to specify that certain sets and even specific fields within those
sets are Read-Write, Read-only or neither based on the password specified
by the user.  By virtue of having a negative filecode, the database becomes
a "priviliged file" which requires non-PM users to access it via PM-enabled
interfaces, primarily the Image intrinsics and utilities, essentially all of
which enforce Image's internal security as defined by the DB creator.  So
even if a (non-PM) user has both read and write access to the DB files, that
user cannot normally bypass the security of the database.  But if the user
can copy the database, then the user is the creator of the copy and
therefore is granted complete access to the data in the copy, including the
ability to read data he was not allowed to see before (even the list of
passwords for the original database).  And if the user modifies the copy
then copies it back over the original database, then the data inside the
original has been modified, all of which totally bypassed the internal
security of the Image database.

Or am I completely in left field about this?

BTW, the ability to STORE and RESTORE the database provides the same holes.
--
Jeff Woods
[log in to unmask] at Unison Software
[log in to unmask]   at home  [PGP key available here via finger]

"Sometimes one pays most for the things one gets for nothing."
      --  Albert Einstein (1879-1955)
TANSTAAFL: "There ain't no such thing as a free lunch."
      --  Robert Anson Heinlein (1907-1988)

ATOM RSS1 RSS2