Re: Authority Lookup Question...

> Ken Graap wrote:
>
> We have secured our production data using authority lists. For example
>
> Object . . . :   NARL    Owner  . . . . :   TURNOVER
> Library  . . :   P1FILES Primary group  :   *NONE
> Object type  :   *FILE   ASP device . . :   *SYSBAS
>
> Object secured by authorization list     CISPRDDTA
>
>
                          Object     -----Object------   ------Data-------
>
>  User         Group        Authority   O   M   E   A   R   R   A   U   D
E
>
>  TURNOVER                  *ALL        X   X   X   X   X   X   X   X   X
X
>
>  *PUBLIC                   *AUTL
>
> The authority list CISPRDDTA is defined with these entries:
>
>               Object
> User         Authority
> QSECOFR      *ALL
> XYZ          *CHANGE
> CISACCESS    *ALL
> *PUBLIC      *USE
>
> Lets say I'm user XYZ and I want to open this file for update. My
> understanding is that authority would be checked like this:
>
>
> 1. Object authority is checked (Primary group,
> *PUBLIC, ownership)
> 2. *ALLOBJ is checked
> 3. Private authority is checked
> 4. Authority list is checked ... Access granted
>
> My question is ... Since I have specified *PUBLIC authority as *AUTL I
> assume that in step #1 the authority for *PUBLIC specified in the
CISPRDDTA
> authority list will be checked... but will the system then return from the
> CISPRDDTA authority list, check for *ALLOBJ and private authority before
> going back to the list again in step #4 to check for XYZ's authority or
will
> it be smart enough to know user XYZ has *CHANGE authority and allow update
> access immediately in step #1?


Ken - Does this help?

For more information (and flowcharts), see chapter 5 in the
OS/400 Security Reference book, under the topic
"How the System Checks Authority", pp 148 - 173:
http://publib.boulder.ibm.com/iseries/v5r1/ic2924/books/c4153025.pdf

<Excerpt>
How the System Checks Authority

When a user attempts to perform an operation on an object, the system
verifies
that the user has adequate authority for the operation. The system first
checks
authority to the library or directory path that contains the object. If the
authority to
the library or directory path is adequate, the system checks authority to
the object
itself. In the case of database files, authority checking is done at the
time the file is
opened, not when each individual operation to the file is performed.

During the authority-checking process, when any authority is found (even if
it is
not adequate for the requested operation) authority checking stops and
access is
granted or denied. The adopted authority function is the exception to this
rule.
Adopted authority can override any specific (and inadequate) authority
found. See
the topic "Objects That Adopt the Owner's Authority" on page 128 for more
information about adopted authority.

The system verifies a user's authority to an object in the following order:
1. Object's authority - fast path
2. User's *ALLOBJ special authority
3. User's specific authority to the object
4. User's authority on the authorization list securing the object
5. Groups' *ALLOBJ special authority
6. Groups' authority to the object
7. Groups' authority on the authorization list securing the object
8. Public authority specified for the object or for the authorization list
securing the
object
9. Program owner's authority, if adopted authority is used

Note: Authority from one or more of the user's groups may be accumulated to
find sufficient authority for the object being accessed.
</Excerpt>

Steve Landess
Austin, Texas
(512) 423-0935