Problem:
USER01 is running in IMPLEMENT mode and has an explicit permit to link any of USER02’s minidisks in the form:
TSS PER(USER01) VMMD(USER02) ACC(READ)
However, when a link to USER02’s 191 disk is issued, the attempt is failed by CA Top Secret. The following trace records are produced:
TSS-R U/USER01 A/USER01 T/GRAF0081 M/I RC/086640
VF/00000000 SF/00000000
TSS-1 RT/7 RD/8100 AC/400000000 AT/0000 AL/090C4002040000
RN/USER02.0191
From the trace, it can be seen that the user is being failed by CA Top Secret: Return code=8, DRC=66 (insufficient access).
Solution:
An examination of the access flags (AC/) shows that USER01 is requesting read access (byte 1=40); however, the allowed access has been found to be none (byte 2=00). This occurs in spite of the permit that was done with an ACC(READ).
An examination of the algorithm flags (AL/) indicates that the permit which was used in determining access was not the one in the ACID record, but the fourth permit (byte 5=4) in the second profile (byte 4=02) attached to this user. A TSS LIST of this profile shows that there is indeed an explicit permit to USER02.0191 with ACC(NONE).
This still leaves the problem as to why the permit in the ACID record was ignored. Under normal AUTH(OVERRIDE) processing, CA Top Secret would have matched on the permit in the user ACID and stopped. The answer lies in the RDT (RD/) flags. The first byte of the RDT flags indicates the following:
x'80' shows that the resource supports access levels
x'01' indicates that the resource has the MERGE attribute associated with it.
With the MERGE attribute, CA Top Secret takes the best fit (longest prefix) from the combination of the user ACID record and all attached profiles.
|
Copyright © 2009 CA.
All rights reserved.
|
|