Using VEOPEN with PowerHouse on the HP-3000

[Johnson, Tracy]

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.
>