CSP Gateway Configuration Guide - InterSystems Documentation

intersystems.com

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

More magazines by this user
Similar magazines