[Info-vax] Sharing a BG device with another user process

[Stephen Hoffman]

On 2013-12-20 15:32:09 +0000, Jeffrey H. Coffield said:

> I am reviewing the code in our JDBC driver for RMS and feel that I am 
> missing something in the log in sequence. I have a listener process 
> that accepts a network connection, authenticates the username/password 
> and starts a detached network process under the users account. The 
> problem (I think) is that in order for the server process running under 
> the users account to assign a channel to SYS$NET, I have to install the 
> server image with SHARE privilege. Otherwise I get a SYSTEM-W-DEVALLOC 
> error on the assign.

FWIW, SHARE privilege has had a long history of leaving dangling I/O 
channels if the deassign requests happen in the "wrong" order.

> It is important that the server run in the context of the user as our 
> driver provides a method to read logicals and symbols set in the users 
> LOGIN.COM.

If you decide to continue with that particular design, that is.  There 
are many other (clean) ways to get configuration information passed 
along into system context.

> Is there a "correct" way to do this (like FTP or Telnet)? I realize 
> that some of the code is undocumented.

The sort of socket hand-off that most folks are probably looking for 
isn't something that's particularly supported nor documented.

The auxillary server would be the usual approach I'd use.  
<http://h71000.www7.hp.com/doc/83final/6526/6526pro_001.html#aux_sec>, 
and particularly the TCPIP$C_AUXS itemcode.   Also look in 
TCPIP$EXAMPLES: for TCPIP$TCP_SERVER_QIO_AUXS.C and 
TCPIP$TCP_SERVER_SOCK_AUXS.C.

Another option is to launch the process via the auxillary server, then 
use the persona services to switch the ownership.  (This keeps you 
clear of the user login and the rest, which would be my general 
preference.  You're under the user's own context, but the user doesn't 
have particular input into the server / daemon process.  Which usually 
means there's less around for the user to hack or to corrupt.)


-- 
Pure Personal Opinion | HoffmanLabs LLC