CSP Gateway Configuration Guide - InterSystems Documentation

Conventions Used in this Document
1.8.1 Gateway components and physical installation paths
Later sections in this guide describe how the Gateway components should be configured with all supported web servers.
The installation paths for components should be regarded as examples rather than taken literally. Also, the InterSystems
installers will create and maintain separate Gateway installations for the internal (private) web server and any third-party
web server that might be present on the same host. In this context ‘third-party web server’ refers to a web server that is not
part of the software installed by InterSystems.
The precise installation location of Gateway components is not particularly critical provided:
• The physical installation paths match those given in the hosting web server configuration where appropriate.
• The security settings, in relation to required access for individual components, are adjusted appropriately. This is particularly
important for Gateway components that are accessed directly by the web server since web servers are usually
locked down to the extent that the files they are able to access (and executables that can be run) are carefully controlled.
It should be borne in mind that security considerations will also be important for any Gateway configuration (and log)
files that are accessed by Gateway binaries that are themselves bound to the web server core executable.
• The security policy of the hosting web server is respected. Some web servers – notably those shipped with Secure
Linux (SELinux) and OpenVMS (HPSWS) – are configured such that it is not possible for them to access files that lie
outside their own file system. This restriction will clearly have an impact on where certain web-server-facing Gateway
components can be installed.
There are four types of Gateway component to consider.
1. Binaries to be loaded by the web server (API based extensions).
This includes Windows DLLs, UNIX Shared Objects and OpenVMS Shareable Images:
CSPms[Sys].dll
CSPn3[Sys].(dll|so|exe)
CSPa*[Sys].(dll|so)
mod_csp*.(so|exe)
The physical location where these are installed should match the corresponding configuration directives in the hosting
web server configuration. This includes directives indicating which third-party modules should be loaded. The web
server requires permission to read and load these modules. Modules named CSP* require permission to read and write
to the Gateway configuration and log files (CSP.ini, CSP.log). These are usually created in the same location as the
Gateway binaries.
When considering access control for these modules, bear in mind that it is the web server worker processes that need
to be able to access the modules together with any dependent configuration and log files. For example, in the case of
Apache, the server is usually started with superuser permissions but the worker processes that actually serve web
requests run with a much lower level of authority (as indicated by the User and Group directives in the Apache configuration
file). It is the User and Group specified for the worker processes that should be granted permission to load the
Gateway modules and (where appropriate) the ability to read and write to the configuration and log files (CSP.ini and
CSP.log).
2. Executables to be called by the web server (CGI modules).
[nph-]CSPcgi[Sys][.exe]
The physical location where these are installed should match the corresponding configuration directives in the hosting
web server configuration. This will include directives indicating which web requests should be processed by these CGI
modules.
The worker processes of the hosting web server require execute permission for these modules. There are no further
dependencies.
CSP Gateway Configuration Guide 7