Article View: bit.listserv.asm370
Article #320Re: Authorizing Address Space
From: Bill Fairchild
Date: Mon, 05 Sep 2005 17:58
Date: Mon, 05 Sep 2005 17:58
44 lines
3389 bytes
3389 bytes
In a message dated 9/5/2005 9:49:46 A.M. Central Daylight Time, essteam@juno.com writes: >I have a client who would like me to develop a presentation on an Authorizing Address Space. >I suggested simply writting an SVC that switches Authorizations instead of and address space. >That Suggestion was fround upon. They are building this facility to alow Vendor Products and As well As >IBM products to issues Authorized Services where I the Vendor does not usually/easily permit it. >The customer would like to develop a cross memory environment; issue a Program Call Instruction form a vendor product address space to >thecustomers Authorizing Server Address Space and allow the caller to be in Supervisor State key xx or APF Authorized. >I believe an SVC could be developed to accomplished this, but I suspect theres more to this that what they are telling me. >My first question is when the Cross Memory Program is executed, it would Sets the APF Authorization bit >and return. WHo IS in the APF state, The entire Calling Address Space or only the invoking TCB? >Can anyone on the list speak to the pros vs cons of developing an Authorizing SVC against an Authorizing Address Space. >I also suspect that Some Security Checking would be done in this Address Space, since that was the first concept they had me explore. >paul d'angelo Judging from your questions, the background of the situation, and some of the replies, I believe you are in way over your head on this project. You need to subcontract this work, or at least the design phase, to an MVS-z/OS security expert who knows all about SVCs, PCs, APF, etc. or else tell your client that you respectfully decline to work any more on this project. I also believe your client is in way over their head. If you continue on this project, you should purchase a large amount of product liability insurance for yourself. At the very least, much more research is needed before you begin creating your presentation. Bill Fairchild
Technical Details
Message-ID:
<20d.88877bd.304de143@aol.com>Path:
arc1-ca.pugleaf.net!g2news1.google.com!news3.google.com!news.glorb.com!usenet.INS.cwru.edu!newsfeed.berkeley.edu!ucberkeley!sn-xit-03!sn-xit-08!sn-xit-14!supernews.com!149.173.6.116.MISMATCH!foggy!vm.sas.com!aol.com!DASDBill2Show Full Headers
Complete Article Headers
X-Google-Thread: fcdcb,605a50893b34558 X-Google-Attributes: gidfcdcb,public X-Google-Language: ENGLISH,ASCII-7-bit Path: arc1-ca.pugleaf.net!g2news1.google.com!news3.google.com!news.glorb.com!usenet.INS.cwru.edu!newsfeed.berkeley.edu!ucberkeley!sn-xit-03!sn-xit-08!sn-xit-14!supernews.com!149.173.6.116.MISMATCH!foggy!vm.sas.com!aol.com!DASDBill2 From: Bill Fairchild <DASDBill2@aol.com> Newsgroups: bit.listserv.asm370 Subject: Re: Authorizing Address Space Date: Mon, 5 Sep 2005 13:58:27 EDT Organization: SAS Inc. Lines: 44 Sender: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> Message-ID: <20d.88877bd.304de143@aol.com> NNTP-Posting-Host: mozart.unx.sas.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: foggy.unx.sas.com 1125943364 30655 10.19.150.41 (5 Sep 2005 18:02:44 GMT) X-Complaints-To: usenet@unx.sas.com NNTP-Posting-Date: Mon, 5 Sep 2005 18:02:44 +0000 (UTC) Comments: Gated by NETNEWS@VM.SAS.COM Return-Path: <owner-assembler-list@LISTSERV.UGA.EDU> X-Mailer: 9.0 Security Edition for Windows sub 5200 X-Spam-Flag: NO Approved-By: DASDBill2@AOL.COM Return-Path: owner-assembler-list@LISTSERV.UGA.EDU X-OriginalArrivalTime: 05 Sep 2005 18:02:42.0160 (UTC) FILETIME=[02A1B700:01C5B244] Originator: daemon@mozart.unx.sas.com