Using VEOPEN with PowerHouse on the HP-3000

Peter Bateman shediac92@hotmail.com
Thu, 18 Mar 2004 11:44:08 -0400


PowerHouse uses the IMAGE password that is specified on the
FILE statement for the IMAGE database.


The members of an APPLICATION SECURITY CLASS (ASC) are defined
by the client's user.account logon. Read and write privledges
can be assigned to an ASC. Although the ASCs can be same name
as other passwords in the IMAGE database, they are NOT used in the
calls to DBOPEN.

Therefore, when using PowerHouse it is important to have individual
user.account logons for each user of the application so that the signon user 
will be mapped to the appropiate ASC.



Regards,
Peter Bateman

>From: "Johnson, Tracy" <Tracy.Johnson@msiusa.com>
>To: "Walter Murray" <wmurray@midtown.net>, <powerh-l@lists.sowder.com>
>Subject: RE: Using VEOPEN with PowerHouse on the HP-3000
>Date: Thu, 18 Mar 2004 09:20:34 -0500
>
>The following are suggestions you can use without
>resorting to VEOpen (or VEDBopen.)
>
>Job Passwords:
>Security/3000 should handle it.  VEOpen is not the tool.
>
>Application Password hard-coded in Job Streams:
>This is a little different.  But you can prompt
>for these passwords at Run-Time using Security/3000
>"::" prompting, then plug them in with "{}" variables.
>(Self replicating jobs are more difficult, but
>see my Read group access comments further down.)
>
>Source Code:
>A tip from the days when disc was expensive:
>Store the Source Code to tape and purge it.
>Restore when before compiling, store to tape again
>after mods. Purge after storing.
>
>Schemas:
>Same tip from the days when disc was expensive:
>Store the schemas to tape and purge them.
>Restore when needed, purge after use.
>
>(Of course Image passwords will be harder to hide than
>you think.  Every user that configures his own ODBC
>connection will need to plug in the IMAGE password.
>We added a Read Only password to our Image databases
>and give only that one to users, we also turned
>Write Access to ODBC off.)
>
>Powerhouse:
>It uses the Passwords inherent to the database.  If
>you mod the database to have separate Read and Read/Write
>passwords, in order to use them you will also have to
>recompile the Powerhouse schema (a.k.a. PDL.)
>
>Since Powerhouse schemas (or PDLs) are compiled
>you can purge the source after compiling also.  Again,
>store them to tape first.)
>
>- - - - - - - - - - - - - - - - - - - - - -
>
>If the intent is to prevent casual reading, the
>above steps should work.  A more determined
>hacker would be able to reverse engineer passwords
>from compiled code anyway.  I assume here that
>only authorized users are in your system and your
>company doesn't hire hackers or authorize their
>access.
>
>- - - - - - - - - - - - - - - - - - - - - -
>
>Other measures are more organizational.  Why
>is source code and schemas put in MPE groups and
>accounts where non priviledged users have read
>access anyway?
>
>You can turn off Read Access to a group where
>job streams reside in.  It was a few years back
>where they change jobs so you don't need Read
>Access (R) of a group where a Job Stream resides
>to Stream it.  Only Execute (X) access is needed
>now.
>
>You can also turn off Read Access to groups where
>Executable code resides.  Then only the Group
>Users, (GU), Librarians (AL, GL) or the Managers
>(SM, AM) can read them.
>
>Add passwords to the executable groups so users
>can't change CHGROUP to the Group where the code
>resides also.  This presumes users aren't HOME'd
>to one of these groups.
>
>
>BT
>
>
>Tracy Johnson
>MSI Schaevitz Sensors
>
> > -----Original Message-----
> > From: powerh-l-admin@lists.sowder.com
> > [mailto:powerh-l-admin@lists.sowder.com]On Behalf Of Walter Murray
> > Sent: Wednesday, March 17, 2004 10:12 PM
> > To: powerh-l@lists.sowder.com
> > Subject: Using VEOPEN with PowerHouse on the HP-3000
> >
> >
> > 2004-03-17
> >
> > Greetings,
> >
> > I hope all you experts will be tolerant of this PowerHouse
> > novice.  I'm
> > an old hand at the HP-3000 and MPE, but new to the wonderful world of
> > Cognos software.
> >
> > Can anyone share any experiences, tips, or pitfalls with using the
> > VEOPEN procedure (part of SECURITY/3000 from VESOFT, Inc.), with
> > PowerHouse applications?
> >
> > I am in the midst of a project to eliminate IMAGE passwords
> > that appear
> > in plain text in places like source code, job streams, schemas, etc.
> > The goals are (1) to minimize the risk that someone looking through
> > files or listings will discover a password he shouldn't know;
> > and (2) to
> > make it easy to change a password without having to hunt down
> > and change
> > every file that might contain that password.
> >
> > I am using VEOPEN to accomplish this, and I have just about everything
> > worked out except what I need to do with PowerHouse.
> >
> > As I understand it (and please set me straight if I don't have this
> > right), PowerHouse needs to know only one password for each IMAGE
> > database, and that has to be a password that permits read and write
> > access to all data sets and items.  That password appears in
> > plain text
> > in the source schema, but apparently is encrypted in the compiled
> > schema.  (I deduce this because I dumped a small compiled schema and
> > didn't see any passwords.)
> >
> > My plan is to remove the passwords from the PowerHouse schemas and
> > recompile them.  According to the documentation, that will cause
> > PowerHouse to use a semicolon password when calling DBOPEN, which
> > normally wouldn't work, except for the creator of the database.
> >
> > The trick, then, is to make sure that calls to DBOPEN from PowerHouse
> > are intercepted by an XL that VESOFT provides, named
> > VEOPENNL.PUB.VESOFT.  The VESOFT version of DBOPEN calls VEOPEN, when
> > consults an Access Control File created by the Data Base
> > Administrator.
> > If the user is authenticated, VEOPEN then gets the database password
> > from the root file and passes it along in its call to the real version
> > of DBOPEN.
> >
> > What I need to do, then, is provide for PowerHouse programs
> > to be bound
> > to VEOPENNL.PUB.VESOFT when they are loaded.
> >
> > It looks as though all PowerHouse applications are invoked using a
> > variety of UDCs, all of which seem to funnel through a single
> > UDC, named
> > PHRUNPROG, which contains a single RUN command, which potentially
> > contains a number of libraries in its XL list.  I propose
> > simply to add
> > VEOPENNL.PUB.VESOFT to the end of that list.
> >
> > Is it that simple?  Will that work?  I spoke with support
> > folks at both
> > VESOFT and Cognos this morning, but neither really knew anything about
> > the other.  To his benefit, the Cognos support analyst invited me to
> > share what I found out, to be added to their knowledge base.
> >
> > Thanks for any help you can provide.  I apologize if this message is a
> > great deal longer than it needs to be.
> >
> > Walter, a stranger in PowerHouse paradise
> >
> > Walter J. Murray
> >
> >
> > = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> > Mailing list: powerh-l@lists.sowder.com
> > Subscribe: "subscribe" in message body to
> > powerh-l-request@lists.sowder.com
> > Unsubscribe: "unsubscribe <password>" in message body to
> > powerh-l-request@lists.sowder.com
> > http://lists.sowder.com/mailman/listinfo/powerh-l
> > This list is closed, thus to post to the list you must be a
> > subscriber.
> >
>
>= = = = = = = = = = = = = = = = = = = = = = = = = = = =
>Mailing list: powerh-l@lists.sowder.com
>Subscribe: "subscribe" in message body to powerh-l-request@lists.sowder.com
>Unsubscribe: "unsubscribe <password>" in message body to 
>powerh-l-request@lists.sowder.com
>http://lists.sowder.com/mailman/listinfo/powerh-l
>This list is closed, thus to post to the list you must be a subscriber.

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN Premium   
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines