Re: Performance Question - Authority check rate exceeded gui

Walden

Thanks for clarifying further what I said.

At 10:03 PM 11/25/97 -0500, you wrote:
>Vern,
>
>Close, but you closed the book too soon. IF there are no private authorities

What, no cigar? And I don't even smoke cigars! <g>

>less  than public then the public search is the fastest. There can be users
>with more private authority, but not less. There is a flag in the object
>header that indicates if there are any users with less than private
>authority, so public can be quite fast.
>
>Consider the following:
>
>All my users are in two groups "users" and "programmers". Assume that I want
>to allow my end users to change my production data, but not my programmers.
>I could specify public(*change) and programmers(*use) and suffer great
>performance problems. Or I could specify public(*USE) and users(*change) and
>have no performance problems. Same net effect, but the second option results
>in no users having less than public authority.
>
>This whole conversation ignores the fact that "menu level" security is no
>longer a valid security model on the AS/400. There are too many other ways
>for users to get to data (Remote SQL, DDM, ODBC, FTP, File XFer, etc.) to
>rely on menu level security. My suggested security model for production
>files is public(*use), or public(*exclude), and all production programs
>adopt owners authority, and the owner has sufficient rights to update the
>files. This way I know my users aren't updating files thy shouldn't. I know
>adopted security is slow, but if you are trying to make your system run
>faster by tweaking security settings call me, I'll sell you a bigger 400.
>:-)

I'd be glad to buy one from you, but our IBM rep might not like it.  <g>

At present, we are basically using menulevel security, somewhat as does
MAPICS and as laid out in _Tips and Tools_. Admittedly, there are a number
of ways to get in, as you mentioned. I hope we will reexamine our situation
eventually (fat chance, eh, until someone breaks in?). Prior to
implementing this about a year ago, we'd been running with basically
*ALLOBJ for all users—no kidding! I can only say, I was not here then! Then
a security audit forced us to change things. You can imagine the painful
transition from NO security (beyond user/password) to ANY security.

Somehow we've got away with it for 12 years. As someone called it,
"Security by obscurity". And in our case, the data assets we have (title
information gathered from public documents, e.g.) is largely PD. Our own
title insurance policy information would be more proprietary.

In this case, I (and we) believe that our main concern is accidental data
corruption—less so than malicious activity. But this assessment
process—weighing the cost of securing assets vs. their value) has to be
ongoing. (Un)fortunately, the 400 can lull us to complacency, and it's hard
to say how much effort is needed to secure what we have.

Cheers

Vernon Hamberg
Systems Software Programmer
Old Republic National Title Insurance Company
400 Second Avenue South
Minneapolis, MN 55401
(612) 371-1111 x480


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@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
+---