rbraun@polygen.uucp (Richard Braun) (11/02/90)
I'm developing a DECnet task-to-task interface for a distributed Unix application being ported to VMS. The code I've written uses DECnet nontransparent operations, and declares a server as a named object. The problem? Named DECnet objects under VMS require the SYSNAM privilege. Clients of the application probably don't want to hand out SYSNAM privilege to every user, because this privilege allows for all manner of "trojan horse" security holes. Question: under DECnet, how to I initiate a task-to-task connection *between two existing processes* (a la Berkeley sockets) without having to resort to named objects? If I have to use named objects, can I get around the security problem some other way? thanks, -rich
doelz@urz.unibas.ch (11/05/90)
In article <873@fred.UUCP>, rbraun@polygen.uucp (Richard Braun) writes: > I'm developing a DECnet task-to-task interface for a distributed > Unix application being ported to VMS. > > The code I've written uses DECnet nontransparent operations, and > declares a server as a named object. You can avoid this if you use a PROXY account, then 0= ... will start a com file in the user's directory. In the DECnet implementation of UNIX boxes, mostly the uid serves as username. .. > > Question: under DECnet, how to I initiate a task-to-task > connection *between two existing processes* (a la Berkeley sockets) > without having to resort to named objects? If I have to use named > objects, can I get around the security problem some other way? Forgive me, but why don't you use sockets on VMS? Even UCX 1.2 supports sockets, and they work. Code is portable in between systems in you ifdef the include libraries. Regards Reinhard
cornutt@freedom.msfc.nasa.gov (David Cornutt) (11/08/90)
rbraun@polygen.uucp (Richard Braun) writes: >I'm developing a DECnet task-to-task interface for a distributed >Unix application being ported to VMS. ...problem with having to give server process SYSNAM privilege... >Question: under DECnet, how to I initiate a task-to-task >connection *between two existing processes* (a la Berkeley sockets) >without having to resort to named objects? If I have to use named >objects, can I get around the security problem some other way? As far as I know, you can't. In order to create a known object, you have to have SYSNAM privilege, which, as you've correctly surmised, allows the system to be easily subverted (I'm not disclosing how, but VMS sysadmins probably already know how). However, it isn't necessary for both processes to have the privilege, just the server. (The client doesn't need to create any object.) If your server will be running all of the time, perhaps you can use the INSTALL utility to set up the server with the privilege at boot time. Incidentally, if you can, use a numbered object instead of a named one. It's somewhat more secure; if the server process dies, someone could take advantage of an unattached named object, but not a numbered object. David Cornutt, freedom.msfc.nasa.gov (.sig forthcoming) Don't get the idea that I'm a VMS head just because of this...
ereiamjh@jhunix.HCF.JHU.EDU (Tom B. O'Toole) (11/09/90)
You only need sysnam to declare a certain process as a server for an object, but you might be able to accomplish the same thing by creating an object in the ncp database. You can specify the username of the account you want the server process(s) to run under. Then if you fire the process up with an intial request, you can make it stick around by defining a logical name of the form NETSERVER$SERVERS_USERNAME to be the number of servers you want. You can't have a multi-threaded server this way, but if you pre-start as many processes as the maximum number of links you expect, you will be able to handle them with your pool of processes. I'm not sure if this is acceptable, but you didn't really specify exactly what it was you wanted to do... -- Tom O'Toole - ecf_stbo@jhuvms.bitnet - JHUVMS system programmer Homewood Computing Facilities, Johns Hopkins University, Balto. Md. 21218 ease!Trim!eeeaaaassse!trimtrimtrimeeeeeeaaaaassetrimease!trim!ease!trimeaase