On 22/2/22 6:30 pm, Erik Janssen wrote:
Thanks for the pointers! Very interesting, I never realized that the ZSS part
was also open source and written in metal C. I've so far only seen very minimal
examples of using metal C, so I will look into the code!
ZSS is written in LE C. It is program controlled and executes
pthread_security_np() to run threads using the surrogate identify of the
user. Any authorized APIs are executed in ZIS (Metal/C).
The following snippet is part of a ZSS REST API that calls the ZIS
cross-memory server using a PC call to check authorization against a SAF
profile:
https://github.com/zowe/zss/blob/staging/c/zis/client.c#L205-L207
The PC call is executed here:
https://github.com/zowe/zowe-common-c/blob/d15566760a6a55c8452001087fb6ed2e31501e7a/c/crossmemory.c#L4776
It seems that ZOWE also has the approach to have a PC service that runs the
authorized code, so I guess my initial feeling was correct that this is the
correct 'pattern' to provide authorized services to an unauthorized (yet
perhaps 'program controlled') backend.
Absolutely! The design of the Zowe cross-memory server was based upon
the architecture of existing products. The Metal/C devs were mentored by
some of our best guys. ZIS was proprietary code that Rocket open sourced
as part of the Zowe project. Of course, most of the folks on here have
a obvious dislike of open source so probably aren't keen on Zowe. What I
can tell you is there is a lot of full time development going on in that
space.
The program control seems to be a specialization of that 'pattern', where you
might decide that the only 'clients' of your authorized PC service can be
programs that have been loaded from a 'controlled environment'. This mainly
seems to have been focused on services that allow the identify of the invoker
to change like the pthread_security_np() call, which seems to make sense that
you would only want to allow that to happen if you know where the module that
wants to do that was loaded from.
I will see if I can get slack up and running :-)
Kind Regards,
Erik.
On Tue, 22 Feb 2022 08:35:50 +0800, David Crayford <[email protected]> wrote:
On 22/2/22 4:59 am, Erik Janssen wrote:
Well, the routine I wrote can handle a user, password or passphrase and
optionally an APPL to verify against.
So, even though there are a lot of options to do it different, I was more
looking for ways how such a 'service routine' that needs apf authorization
could be used from a non-authorized caller.
The __passwd routine can do it, but it requires program controlled environment
and python doesn't seem to be defined as program controlled and I don't want to
'just' enable it.
Program Control can be a PITA, but APF authorizing a service is a bag of
worms.
Also, the relation between APF authorisation and program control (if any) still
eludes me, and if there is no relation then I don't understand how __passwd can
check a password if the environment is not apf authorized.
I hope that someone can explain how that works.
AFAIK, there is no relationship. I've very leery when I see a z/OS UNIX
program APF authorized.
Zowe has a couple of components you may be interested in. All APF
authorized services are processed in the ZIS server, otherwise nown as
the cross-memory server. It's a Metal/C application that is open source
an available to
Github. It provides services via PC calls which are exploited by the ZSS
server which is a lightweight HTTP server written in C. Both have tiny
footprints and you can write your own plugins. SAF
authentication/authorization are
already provided.
Disclaimer: I'm a Zowe commiter and I mainly work on these components.
Although only for code reviews, we have devs working full time on Zowe.
https://docs.zowe.org/stable/getting-started/zowe-architecture/
https://github.com/zowe/zss
BTW, building this stuff can be tricky. You can reach out on the
OpenMainframe slack channel and one of our helpful devs can assist you.
Or just ping me offline.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
