This FAQ primarily addresses unix systems. In modern releases, the installer creates most files with 0755 permissions.
Because IHS sometimes runs under multiple userids, changing filesystem permissions can be complicated. This FAQ only covers the
following two scenarios:
- IHS installed by root and started as root. This is the recommended and preferred configuration on unix systems.
- IHS installed by non-root user X and started by non-root user X.
Other configurations require more lengthy/meticulous configuration. Those configurations include
root-owned IHS started by a semi-privileged or a semi-privileged user installing IHS started by
an unrelated unprivileged user.
IHS started by root
The issues for an instance of IHS started by root primarily involve resources needed at request processing
time, after IHS has switched to the ID specified with the
User
directive. We will refer to this
as the
configured ID. Note that all of the requirements below are met in the default configuration.
- The root (UID 0) user implicitly has full control of the installation root.
- There is generally no need to change ownership of any product files or configuration.
- The configured ID needs to be able to read any static content it will serve.
- The configured ID needs to be able to execute any CGI content it will serve.
- The configured ID needs to be have search (execute) access to all directories between / and the directory containing
static content.
- The configured ID needs to be able to read and write to mod_disk_cache's CacheRoot. There is no default CacheRoot.
- The configured ID does NOT need write access to any IHS binaries, contents, directories, or logs not previously mentioned.
- The configured ID does NOT need read access to any IHS KeyFile.
- If using the WAS Plug-in:
- plugin-key.* needs to be readable by the configured ID if SSL is used and plugin-cfg.xml is ever
reloaded on the fly (RefreshInterval != 0 and plugin-cfg.xml updated at runtime). In environments where security is paramount,
disable this reloading.
- The optional IHS Administration Server, used by WAS to start/stop IHS and push plugin-cfg.xml and plugin-key.* to remote webservers,
requires that plugin-cfg.xml be group-writable and be owned by the admin servers own group. The Admin Server should always be
started by the same userid that starts IHS. In environments where security is paramount, do not use the IHS Admin Server.
This configuration also uses a shared group, and group write access, to the $IHSROOT/conf directory to allow httpd.conf
propogation. Obviously the selection of shared group and its membership needs to be tightly controlled.
- Changes to filesystem permissions are not preserved during fixpack or interim fix application.
Generally the mechanism by which the configured ID has read or execute permissions to the filesystem are via the other/world permissions
on files owned by root. While it may technically possible to use a shared group for this purpose, it has not been considered/designed/tested
by IBM.
IHS started as non-root
When IHS is started by a non-root ID, for the purposes of this document it's assumed that this user
ran the installation and has ownership of all files in the installation root.
- The non-root ID user implicitly has full control of the installation root.
- There is generally no need to change ownership of any product files or configuration.
- Generally, no other ID will require filesystem read or write beneath the installation root.
- Changes to filesystem permissions are not preserved during fixpack or interim fix application.