Re: TESTAUTH from C/C++
inline bool isauth() {
int rc;
__asm (" TESTAUTH FCTN=1"
: "=NR:r15"(rc)
:
: "r1", "r14", "r15");
return rc == 0;
}
On 16/08/2022 2:17 am, Tony Harminc wrote:
Marginally related to my previous question - I'd like to do a TESTAUTH from
C/C++ code, and refuse to run if I'm not APF authorized. I'm not proposing
to actual use the result for any sort of my own security testing, but just
to know if calling a C/C++ library function that is documented to require
APF (or better) is likely to fail so I can tell the user early.
I don't see a C library function to do this. The TESTAUTH expansion is
tiny, and I could use __ASM(...), but it's perhaps neater to just test
JSCBAUTH directly in C code. Yes, I realize TESTAUTH is more than just
testing that one bit, but I think it's true that if that bit is off (and
I'm not in supervisor state or system key, which I won't be), then a
TESTAUTH would fail, and that's all I want to know.
Oddly enough, there *is* a library function that appears to test for the
Program Controlled state. Well, maybe not - it's __must_stay_clean() which
tests for the "must not lose Program Controlled" status, so not quite the
same.
What's the best approach?
Tony H.
--
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
Re: TESTAUTH from C/C++
ISAUTH EDCPRLG DSALEN=CDSALEN,BASEREG=NONE * TESTAUTH FCTN=1 * SRL R15,2 4 => 1 LCR R15,R15 1 => -1 AHI R15,1 1 => 0; 0 => 1 * EDCEPIL , -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TESTAUTH from C/C++
On Mon, 15 Aug 2022 at 15:26, Kirk Wolf wrote: > IMO, If you are going down the path of writing C/C++ for z/OS of much > significance, you will likely need to write some assembler routines that > you can call from C/C++.Just bite the bullet and figure out the calling > conventions (XPLINK?) and you will be glad in the long run. Yup - thanks. This is a 20+ year old code base that runs on z/OS and Windows with conditional compilation. It already uses a number of z/OS callable services, including RACF ones. I'm just trying to make it a bit more z/OS-friendly in the way it interacts with end-users and operations people. Part of this is issuing messages with the expected z/OS level of accuracy and particularity (don't laugh...), rather then the "Oops - something went wrong" that we see from Google and Microsoft et al. So it's not a matter of writing brand new C/C++ code for z/OS. If we *were* writing new z/OS code I'm pretty sure we'd be looking at the Open XL C/C++ compiler with its newfangled bells and whistles, 64-bit-only code, and so on. Our current code has run with LE and its baggage for a long time, and isn't likely to change. The compiler inlining support is another option that often good, but in > many cases it can be tricky because you have to carefully declare all of > the register clobbers, not to mention the crazy syntax and symantics of > __asm. > I've tried asking IBM over the years to provide something that's a lot more like the PL/X GENERATE statement for C, i.e. that doesn't try to cram assembler into C syntax. Of course that's for Metal C where the compiler is generating assembler statements anyway. I seem to be crying in the wilderness on this one. Tony H. On Mon, Aug 15, 2022, at 1:17 PM, Tony Harminc wrote: > > Marginally related to my previous question - I'd like to do a TESTAUTH > from > > C/C++ code, and refuse to run if I'm not APF authorized. I'm not > proposing > > to actual use the result for any sort of my own security testing, but > just > > to know if calling a C/C++ library function that is documented to require > > APF (or better) is likely to fail so I can tell the user early. > > > > I don't see a C library function to do this. The TESTAUTH expansion is > > tiny, and I could use __ASM(...), but it's perhaps neater to just test > > JSCBAUTH directly in C code. Yes, I realize TESTAUTH is more than just > > testing that one bit, but I think it's true that if that bit is off (and > > I'm not in supervisor state or system key, which I won't be), then a > > TESTAUTH would fail, and that's all I want to know. > > > > Oddly enough, there *is* a library function that appears to test for the > > Program Controlled state. Well, maybe not - it's __must_stay_clean() > which > > tests for the "must not lose Program Controlled" status, so not quite the > > same. > > > > What's the best approach? > > > > Tony H. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TESTAUTH from C/C++
That's what I did, for example to be able to call SWAREQ etc. from C or certain machine instructions which cannot be reached from C otherwise. Very small ASSEMBLER routines with clean C interfaces. Because we are only using 31-bit C with standard linkage conventions and NORENT, the linkage to the ASM routines is a no-brainer. No XPLINK. Even no LE dependencies or considerations. LE doesn't even notice that there are some small ASM routines doing some system-related work. Kind regards Bernd Am 15.08.2022 um 21:23 schrieb Kirk Wolf: IMO, If you are going down the path of writing C/C++ for z/OS of much significance, you will likely need to write some assembler routines that you can call from C/C++.Just bite the bullet and figure out the calling conventions (XPLINK?) and you will be glad in the long run. The compiler inlining support is another option that often good, but in many cases it can be tricky because you have to carefully declare all of the register clobbers, not to mention the crazy syntax and symantics of __asm. Kirk Wolf Dovetailed Technologies, LLC http://coztoolkit.com Dovetailed Technologies: +1 636.300.0901 Note: Our website and domain name have changed from dovetail.com to coztoolkit.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TESTAUTH from C/C++
IMO, If you are going down the path of writing C/C++ for z/OS of much significance, you will likely need to write some assembler routines that you can call from C/C++.Just bite the bullet and figure out the calling conventions (XPLINK?) and you will be glad in the long run. The compiler inlining support is another option that often good, but in many cases it can be tricky because you have to carefully declare all of the register clobbers, not to mention the crazy syntax and symantics of __asm. Kirk Wolf Dovetailed Technologies, LLC http://coztoolkit.com Dovetailed Technologies: +1 636.300.0901 Note: Our website and domain name have changed from dovetail.com to coztoolkit.com On Mon, Aug 15, 2022, at 1:17 PM, Tony Harminc wrote: > Marginally related to my previous question - I'd like to do a TESTAUTH from > C/C++ code, and refuse to run if I'm not APF authorized. I'm not proposing > to actual use the result for any sort of my own security testing, but just > to know if calling a C/C++ library function that is documented to require > APF (or better) is likely to fail so I can tell the user early. > > I don't see a C library function to do this. The TESTAUTH expansion is > tiny, and I could use __ASM(...), but it's perhaps neater to just test > JSCBAUTH directly in C code. Yes, I realize TESTAUTH is more than just > testing that one bit, but I think it's true that if that bit is off (and > I'm not in supervisor state or system key, which I won't be), then a > TESTAUTH would fail, and that's all I want to know. > > Oddly enough, there *is* a library function that appears to test for the > Program Controlled state. Well, maybe not - it's __must_stay_clean() which > tests for the "must not lose Program Controlled" status, so not quite the > same. > > What's the best approach? > > Tony H. > > -- > 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
