Re: Performance Question - Authority check rate exceeded gui

Vern,

Close, but you closed the book too soon. IF there are no private authorities
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.
:-)

-Walden
-----Original Message-----
From: Vern Hamberg <hambergv@goldengate.net>
To: MIDRANGE-L@midrange.com <MIDRANGE-L@midrange.com>
Cc: John Cirocco <jcirocco@us.ibm.com>
Date: Monday, November 24, 1997 9:17 PM
Subject: Re: Performance Question - Authority check rate exceeded gui


>At 08:24 AM 11/21/97 -0500, you wrote:
>>Pete,
>>
>>>>Do you have users that have less than *PUBLIC access to objects? I'm
>>>>told that is a big cycle hog.
>>
>>Yep - Our problem is that the developers are part of a group (QPGMR) and
have
>>less than *PUBLIC. My suggestion to the is top add all production users to
a
>>seperate group and make that group the Primary Group for all the objects.
But
>>without the tool and/or knowledge to prove my theory, they are reluctant
to do
>>so.
>>
>>They also have other problems with performance but I want to only fix one
at a
>>time and re-review their performance data.
>
>Here's the skinny, straight from the Security-Reference v3r7 manual, on the
order in which authority checking is done:
>
>>>>>
>
>1. User’s *ALLOBJ special authority
>    2. User’s specific authority to the object
>    3. User’s authority on the authorization list securing the object
>    4. Groups’ *ALLOBJ special authority
>    5. Groups’ authority to the object
>    6. Groups’ authority on the authorization list securing the object
>    7. Public authority specified for the object or for the authorization
list securing the object
>    8. Program owner’s authority, if adopted authority is used
>
>    <<<<
>
>As you can see, public authority results in very inefficient processing, as
it is delayed until the end, almost. The only thing worse, it seems, is
adopted *OWNER. Ouch!!
>
>There's a lot more in the manual—flowcharts for all stages, and multiple
examples. Too much to put in a posting here. Get the PDF version or get it
off your Softcopy CD. The above was in chapter 5. Should be plenty to prove
your case.
>
>HTH
>
>
>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 +---
>

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