Chris,
 
well - I had to think a bit about your problem, thought about a variety
of solutions and, well, let me tell you what I think:
 
/*
 * All comments are entirely personal and do not reflect in any way
 * opinions/statements of my employer
 */
 
- There is no BSD equivalent to IPCGIVE/IPCGET
- FDs and SDs are still somewhat different and I wouldn't even try
  to implement that on MPE
- Spawning su does not like like a viable solution on MPE to me, to
  my knowledge su is not part of the POSIX command suite.
 
But:
 
- If your main process (in absence of inetd) forks the server process
- You then AIFChangeLogon
- Check .profile in $HOME for $PSV
- fork/exec the actual server (from $PSV)
 
you should still have the SDs from the original connection.
 
Let me know what you think,
 
kindest regards:
 
Christian Frank,
Hewlett-Packad GmbH,
RCO Ratingen, Network Operating Systems
 
<[log in to unmask]>
 
----------
From: Non-HP-Breemer.chris
To: Christian-Frank-at-om
Subject: Re: Socket passing
Date: Tuesday, January 17, 1995 11:25AM
 
Christian,
 
Thanks for your reply. I hope you have the time to take this a bit further.
 
> the 'inetd' passing mechanism is to fork() the child process and pass
> the socket descriptors as stdin/stdout - this makes it very easy to
> write network servers, since the server does not need to know anything
> about sockets and networks, it just needs to read()/write().
>
Yes, I realize that. This is how you invoke an arbitrary program via inetd.
But the design of the Uniface polyserver is different, in that sense that
we first change the logon environment, which then determines which server
is started.
The program that is activated by inetd is a login verification program. This
gets the socket as stdin, reads a user/password combination from the
socket and verifies this, using getpasswd() etc. If this is found ok, it
determines the value of the environment variable $PSV for that user (using su
and env commands). It then spawns an su command for the program it
finds in $PSV.
su does not preserve the socket, that is why we use the dup trick.
 
I suppose all this should be possible on MPE/iX 5.0, but I am worried
about the dup
from a fd to a socket. Does 5.0 handle bsd sockets and fd differently ?
 
On MPE, we issue AIFCHANGELOGON, then run a CI to get the
user environment, and then do a CREATEPROCESS for whatever is found in !PSV.
CREATEPROCESS does not ( I think) preserve the socket, but luckily we have
IPCGIVE and IPCGET. I don't suppose BSD sockets on MPE/iX will have a bsd
alternative to these calls ?
 
> If you fork() your child process, all fd's are availiable to the child
> (and should be fclosed by the father), why would you want to fdup'e it?
>
I hope that is clear by now.
 
Come MPE 5.0, I would like to use the same code as we use on UNIX, including
the dirty trick, for want of a better solution. Do you think this will work ?
 
Thanks very much for your help.
--
 
:)
Chris Breemer
[log in to unmask]