SSL equivalent of givedescriptor() and takedescriptor()

Question

I am converting an old tcp only server to use SSL (via IBM's GSkit), and one of the problems is getting the SSL handle into the spawned program. The original code passes the raw socket in via calls to the givedescriptor() and then uses takedescriptor() to get and then use the passed in socket.

Is there a GSKit/SSL equivalent of the give/take descripter methods?

givedescriptor() API documentation

UPDATE:

The issue is that the socket and the SSLHandle are created in one process, which initialized the SSL environment, and then need to be passed on to another process entirely - hence the need to give/take descriptor, as the socket / SSLHandle need to 'given' to the new process (it is actually an RPG program that is submitted and runs independently from the original program).

UPDATE 2:

Looks similar to this question, so I'll have a read of that as well.

From the other article (which doesn't have a code based answer, but a written solution)

"It looks like the session handles are just pointers to some storage in heap. Due to the design of Single Level Store, you could copy them via shared memory (memmap, shmget/shmat, ...). You just have to ensure that the process that opened the GSK environment doesn't die or the activation group will get cleaned up and those pointers will become invalid. You also will probably need to put a mutex or some other locking primitive around them if you're going to have multiple threads accessing the shared data structure."

UPDATE 3:

This is the example I am using to share the memory between processes - Example: Using semaphore set and shared memory functions, still not exactly solved the issue yet though.

UPDATE 4:

I thought I'd add more details of why I need to ask the question. I am changing a non-blocking TCP server that is used as a connection point to an IBM i. It has the 'standard' mechanism for handling connections as they come it, creating threads and negotiating the connections in these threads. The threads then create independent process (via sbmjob). In the vanilla TCP version we can then give the running job the handle of the socket via the give/takedescriptor function, and will merrily write to and from the socket.

So I need an equivalent way of getting the independently running program to be able to write to SSL.

It maybe that this is not possible with the current mechanism.

Answer 1

There is no such thing as an 'SSL handle' known to the operating system and inheritable by child processes or transferable to other processes. The 'SSL handle' will inevitably be a pointer into some opaque data structure in the originating process, as SSL is an application layer protocol, and therefore implemented in the process, not in the kernel. So you can't 'give' an 'SSL handle' to another process and expect it to work.

EDIT

The answers here don't really answer the underlying question, which how I should do this, so although the bounty has been awarded, I can't accept the only answer.

The answer is that you can't do it.

It maybe that this is not possible with the current mechanism.

Correct. As you've foreseen this possiblity in your question, it is difficult to understand why you can't accept it in an answer.