On Thu, 26 Jun 2014 08:53:35 -0700 Phil Smith <[email protected]> wrote:
:>Barbara Nitz wrote:
:>>>So my current fundamental question is: what identifies an address space
besides the ASID?
:>>The STOKEN is the only thing that uniquely identifies an address space for
the life of the IPL.
:>>>That is, I would have thought that ASID X'1234' meant the same address
space, whoever referred to it. An address space might be refused access to it,
but would always mean the same one no matter who referred to it. Is this
incorrect?
:>>I recently encountered a situation where one tcb in a server had started an
address space with asid 1234, which immediately terminated with a JCL error.
Another tcb in the same server had also started an address space in the correct
timeframe to *also* get asid 1234. This STC actually started up and stayed up.
Both TCBs later believed to be talking each to its own address space, when in
essence both TCBs were talking to the same one that had the asid sequentially
after the first terminated.
:>>So asid is not a unique criterium to identify an address space, but STOKEN
is. You get the STOKEN either from the ASCRE invocation or by using LOCASCB to
translate asid into STOKEN. In the latter case, beware that until LOCASCB
returns, the asid may already be the wrong one due to the slot in the ASVT
getting reused by the next request.
:>I was aware of ASID reuse, but while ASID may not be a unique criterion over
time, for the duration of this exercise, it is. If the client manages to go
away during the operation and the ASID gets reused, we'll detect that when we
go to return the results. In any case, in my testing environment, the client
definitely isn't going away during the operation.
:>So my supposition/belief is that ESAR followed by using that ASID should get
me "back" to the correct address space.
:>* In the first module, soon after the PC:
:> ESAR R1 Get secondary ASID
:> STH R1,SRQESASN And remember that
:> MVI SRQERSVA+8,X'37' Set a magic value
:> STH R1,SRQERSVA+9 Remember the SASN
:> MVI SRQERSVA+11,X'73' And another magic value
:> SAC 512 Begin AR-mode execution
:> LAM R2,R2,=F'2' Home space
:> USING ACEE,R2
:> CLC ACEEACEE(4),=CL4'ACEE' Does it look like an ACEE??
:> BE *+8 Yes, great, continue
:> EX *-*,* Ouch, ABEND time
:> ST R2,SRQERSVA+0 Remember the ACEE address
:> MVC SRQERSVA+4(4),SRQEACEE Remember saved ACEE address
:>* So:
:>* 1) We know that the ACEE in R2 looks like an ACEE
:>* 2) We have saved both it and SRQEACEE in SRQERSVA
:>---------
:>* Later on, in the other module:
:> SAC 512 Begin AR-mode execution
:> L R4,SRQEACEE Get ACEE address in caller's home space
:> LH R1,SRQESASN Get caller's SASN
:> SAR R4,R1 Set that in AR4
R1 has an ASN, not an ALET.
You can try
SSAR R1
LAM AR4,AR4,=F'1'
:> LA R3,SRQERSVA Point to our saved stuff
:> DC X'00'
:>* In the dump, at 0(R3):
:>* 007FC6F0 007FC6F0 37004573 (and R1 = 0045 as expected)
:>* So SRQEACEE is still what we expect (and I've done various checks
:>* to be sure something ELSE isn't stepping on that storage), and
:>* SRQESASN is correct (that is, matches what we got from the ESAR
:>* back in the first module)
:>* BUT R4 is pointing to all zeroes!
:>* Shouldn't the SAC/SAR mean that R4 is now pointing to the ACEE?
:>Binyamin Dissen wrote:
:>>Sounds like you are trying to access the storage when you no longer have a
:>>bind to the client address space. While you "could" ALESERV every single
:>>client address space, you cannot guarantee safe access from the server side
:>>(without a lot of work).
:>How do we "lose" the bind to the client address space? Note that we're only
referencing the ACEE here, not doing anything (in this part of the exercise)
with anything else in the client address space, so I don't think "safe access"
is an issue. Is it?
As long as you are in the DU doing PC-SS, you have the bind. But your server
tasks will have different DU's.
:>>You have to explain why you feel the need to cache the security information
in
:>>your server.
:>Cache? Not sure what you mean. We're asking SAF whether the requestor has
access to a resource. I'm not aware that I'm caching anything, but surely I'm
just not understanding what you mean.
So why a need to save it?
--
Binyamin Dissen <[email protected]>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
