• Subject: RE: Security Admin package for multi level security
  • From: John P Carr <jpcarr@xxxxxxxxxxxx>
  • Date: Sat, 6 Nov 1999 10:36:30 -0500

The authority is checked on the "Update" operation.   Not at open.  
If the program monitors for an error (specific CPF message) while doing the 
update,  No problem.   If the program does an update and doesn't monitor,
You will get an CPF (etc) error message.


A company had a program that read in a transaction file and then did some
calc's and wrote out another file (Straight Output in the Fspec).   When it 
did the Write,  It deleted the Input transaction Record.

Well one time a person ran it who didn't have authority to the Output File.
The program DIDN'T bomb on the Write statement  !,   It waited till it 
wrote a Block of records (remember Straight Output, so blocking occured).

Bottom line?  Nothing outputed to file,  HOWEVER the individual transaction
records WERE deleted and were GONE.    

Neat Huh?  (heard that at Sound-Off a few years ago). 
IBM said "Working as designed"

John Carr

Here's another shining chance to show off my ignorance.  I don't use AS/400
security much at my current job.  I don't understand how AS/400 security
alone can properly handle security without application programming.  

Let's say that I have an "update customer master" application that allows
access to name, address and telephone number.  If I want to give a trainee
Customer Service Rep "read-only" access to this application (look but don't
touch) I can't simply restrict his authority to "read-only", because the
program opens the file for update - with restricted authority, the open
fails.  Don't I really need to make the application "security aware" so that
if the user has "read-only" on the customer master file, the application
opens a read-only access path, protects the display fields from update, etc?

I always thought that OS security had to be built into (or recognised by)
the application.

Buck Calabro
Aptis; Albany, NY

| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].