MATCTX (was Detecting changing objects...)

Leif,

I am unable to recreate this exposure (on V4R4 at 50 anyway), and am not
sure I understand your exact environment.  The two builtins I looked
at (_MATCTX1 and _MATCTX2) are system builtins that map directly to
the MI instruction so I'm not clear on what system state program you
are seeing on the stack.

I can also think of scenarios where C runtime is simply doing the same
checking (if not actually using) as the QusMaterializeContext API and
so no breach necessarily exists (though in my test environment I got
MCH6801 with the C builtin _MATCTX2 which suggests the runtime isn't
using the API so one scenario may be scratched...).

Could you send me a quick test case and what release/security level you
are seeing the successful run on?

Thanks,
Bruce

>
>The V4R2 functional reference manual does not mention any
>restrictions. Anyway, I still don't have a *rationale* for why
>an obvious security breach is allowed in C and not in MI.
>
>As I mentioned in my post it is*obvious* that it would work
>with the C-program because at the bottom of the API it
>is a system state program that executes the MATCTX.
>What is not obvious is why *this* breach is allowed.
>So my question still stands. It is not about "how",
>but about "why"?
>
>> -----Original Message-----
>> From: bvining@VNET.IBM.COM [SMTP:bvining@VNET.IBM.COM]
>> Sent: Friday, November 19, 1999 10:21 AM
>> To:   MI400@midrange.com
>> Subject:        MATCTX (was Detecting changing objects...)
>>
>> If MATCTX was working prior to V4R3 for explicit libraries then the
>> bug is in the previous releases and not V4R3.  For many releases
>> there has been a restriction concerning passing system pointers to
>> system domain objects from user state programs (at higher security
>> levels); I suspect it is this restriction (the explict system pointer
>> to the context/library) that is causing the failure.
>>
>> Because of this IBM provided the API QusMaterializeContext (you can
>> probably guess what it does based on the name) back in one of the V3
>> releases (it's in the V3R7 manual anyway).  This API is documented in
>> the Object APIs chapter of the System API Reference (though it basically
>> points you to the MI Functional Reference as the API is just a front end
>> to MATCTX that puts you into the proper state).  Other front ends of
>> this type exist, such as QusMaterializeJournalPortAttr in the Journal
>> and Commit APIs chapter).
>>
>> Bruce
>>
>> >
>> >A problem with MATCTX is that from V4R3M0 it seems to be
>> >a restricted operation (except when materializing the machine
>> >context - * ) and gives you a protection violation at security
>> >level 40 and above if your program is a user state program.
>> >Interestingly enough, the C function matctx does not have
>> >that problem. (I can hear the C-bigots snicker already).
>> >This is because the C interface goes through a service
>> >program that is not a user state program. As far as I am
>> >concerned thus is a bug. It does not make sense to
>> >have a restriction that is that easily circumvented. Maybe
>> >the bug has already been fixed in V4R4M0. If not, it
>> >either should be fixed or it should not be a restricted
>> >operation.
>> >
>>
>


+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---