Put the address of the new ACEE in ASCBSENV and/or TCBSENV as appropriate?

Sent from my iPhone

On Oct 12, 2016, at 21:36, Janet Graff 
<0000004dc9e91b6d-dmarc-requ...@listserv.ua.edu> wrote:

>> Thanks for the info. It helps a bit, but not enough. 
> 
>> First, just to make sure you know, you can't do a RACROUTE REQUEST=VERIFY 
>> while running in cross-memory mode. You would need to create a >request for 
>> another task running in your server primary, queue the request to the task, 
>> and suspend the cross-memory task until you have an >answer.
> 
>> Next, doing a VERIFY for a user ID is not  really sufficient in the general 
>> case, as there are many other aspects of the user's security environment 
>> >that could affect the answer to an authorization check (group name, 
>> terminal name or other port of entry, SECLABEL etc.). At a minimum you 
>> should >use the UTOKEN as input to the VERIFY (if you have to create a new 
>> ACEE) but even that is not sufficient in some cases. So, if you're doing 
>> this for a >product (as opposed to a bit of home-grown code just for your 
>> own company's use) then you need to rethink how much data you capture. For 
>> >example, it may be much better to use a RACROUTE REQUEST=EXTRACT 
>> TYPE=ENVRXTR to get a copy of the user's ACEE, and then recreate it in >your 
>> address space using RACROUTE REQUEST=VERIFY that specifies ENVIRIN.
> 
>> But even before that, what kind of checks do you plan to make using the ACEE 
>> once you have it? (What resource class, for example?) If you're lucky >they 
>> will be checks that you could perform using the existing user's ACEE rather 
>> than rebuilding one. That would be both more efficient, and give you >a much 
>> simpler overall design.
> 
> -- 
>> Walt
> 
> Walt,
> 
> Thanks for the reply!
> 
> The cross memory mode for the system level task code is all written and has 
> been in the field for many years.  (chances are I'm going to bolix up this 
> explanation but I'll give it a go) The system level code uses an RACROUTE 
> FASTAUTH or AUTH to verify General Resource Profiles with a pointer to the 
> callers ACEE for it's own use.  It doesn't EXTRACT anything from the ACEE but 
> uses it for authorization checks. In any case my little test program doesn't 
> get involved in all that.  
> 
> What I'm trying to write is a stand alone assembler test program, that runs 
> in Batch under a userid.  The test program creates a secondary ACEE using a 
> hard coded userid and password that is just used for testing purposes.  Then 
> using this secondary ACEE it invokes the cross memory services support to the 
> system level task that will eventually use either the primary or the 
> secondary ACEE to validate access to resources.
> 
> So I've got the return zero creating the secondary ACEE, but it appears that 
> after that, when I invoke the cross memory services it's done using the ACEE 
> from the primary id.  What do I have to do to switch to using the secondary 
> ACEE?
> 
> Janet
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to