Informix Root vs Non-Root Installation
Architecture, capability differences, limitations, and container/OpenShift implications.
A root-based Informix installation is the full enterprise installation model. A genuine non-root installation is a different product installation mode with important restrictions. It is not simply a conventional installation running under a non-root container UID.
For HA/replication-heavy production environments — including HDR, RSS, Enterprise Replication, Connection Manager, conventional OS authentication, and enterprise backup/recovery — use the traditional root-based installation model. Treat container runtime privilege reduction as a separate security problem.
1. The two installation models
Informix supports two fundamentally different installation modes on Linux/UNIX. The difference is established at installation time and affects ownership, authentication, privileged operations, high availability, backup tooling, and runtime behavior.
| Area | Root-based installation | Non-root installation |
|---|---|---|
| Installer | root | Ordinary OS user |
| Installation owner | Traditional Informix ownership/permissions; informix is the normal DBSA identity | User who runs the installer becomes the installation owner/DBSA |
informix OS account | Normal/expected enterprise model | Not required in the same way |
| High-availability clusters (HDR, RSS, SDS) | Supported as part of normal enterprise topology | Not supported |
| Enterprise Replication | Supported | Not supported for servers that have different installation owners |
| ON-Bar | Supported | Not supported |
| Role-separated auditing | Supported | Not supported |
onperf | Supported | Not supported |
| OS authentication | Full traditional model available | Restricted; cannot rely purely on normal local OS login authentication |
| Encrypted connections / CLE | Supported | Supported, but the required security-layer plug-in must be installed separately |
| Shared-memory and stream-pipe connections | Normal system locations and permissions | Require the cfd option in sqlhosts, on the server and on connecting clients |
| Later conversion | Cannot be converted to a non-root installation | Cannot be converted to a root-based installation |
Conversion is unsupported in both directions. The installation model is fixed at install time.
2. What “root installation” actually means
The phrase root installation describes how Informix was installed and how privileged components, ownership, permissions, and the Informix administrative identity were established. It does not mean that every database engine process should be thought of as an unrestricted root application.
root
↓
installs Informix
↓
establishes ownership / permissions / privileged components
↓
informix account / DBSA identity
↓
normal instance administration and operation
Seeing root-owned oninit processes in a conventional deployment does
not redefine the installation as a separate “root runtime” mode.
Installation model and runtime process ownership are related, but they are not the
same classification.
3. Authentication differences
Authentication is one of the most important practical differences. A traditional installation can participate in the normal Informix OS identity model, including the usual Unix user/UID/group relationships and enterprise authentication patterns.
| Root-based | client user → Informix authentication → OS account / UID / groups |
| Non-root | installation owner is DBSA; users cannot simply depend on normal local OS-login authentication in the same way |
For enterprise environments that integrate Informix with PAM, AD, trusted-host arrangements, service accounts, and conventional Unix identity management, this distinction is architectural rather than cosmetic.
4. Shared memory and local connections
A traditional installation can use the expected system locations and permissions
for local communication information. A non-root installation does not have
permission to write to /INFORMIXTMP, the default location for
communication files, so the cfd option must be
included in the sqlhosts file to use shared-memory (onipcshm) and
stream-pipe (onipcstr) connections.
server_shm onipcshm host service cfd=/path/writable/by/owner
Non-root installations store communication files in $INFORMIXDIR/etc
by default. Connecting clients, however, check /INFORMIXTMP
first and only then $INFORMIXDIR/etc.
The usual failure mode
A local connection fails while the database server is running perfectly well, because the client and the server disagree about where the communication file lives. The
cfdvalue has to be consistent on both sides — setting it only on the server is not sufficient.
5. Enterprise feature limitations
The decisive limitation for most production Informix environments is that non-root installation mode is intentionally reduced in scope. It is aimed at easier embedding/deployment where full enterprise database-server capabilities are not required.
| Feature | Non-root installation |
|---|---|
| High-availability clusters | Not supported in the non-root installation model. This makes it unsuitable for normal HDR/RSS/SDS enterprise topologies. |
| ON-Bar | Not supported. This matters where production backup/recovery standards depend on ON-Bar and storage-manager integration. |
| Role-separated auditing | Not supported in the normal enterprise form. |
onperf | Not supported. |
| Enterprise Replication | Not supported for servers that have different installation owners; ownership becomes part of the topology constraint. |
| Authentication | Normal OS-login based authentication cannot simply be assumed; user management and mapping requirements differ. |
| Encrypted connections / CLE | Supported, but only if the required security-layer plug-in is installed separately. This is a packaging step, not a capability loss. |
| Install-type conversion | Not supported in either direction. A non-root installation does not become a root-based installation through chown/chmod changes, and there is no supported procedure that achieves it. |
6. Where non-root installation fits
Non-root installation mode is most appropriate when deployment simplicity and lack of root access are more important than the complete enterprise feature set. Typical use cases include:
- developer-contained database environments
- embedded Informix deployments
- application appliances
- restricted environments where the installer is not permitted root access
- self-contained servers that do not require full HA/backup/security integration
7. Container and OpenShift: keep the questions separate
Container security introduces a second axis. The installation model and the runtime UID are independent decisions.
| Question | Meaning |
|---|---|
| How was Informix installed? | Determines whether this is the conventional full installation or Informix genuine non-root installation mode. |
| What UID/capabilities does the container run with? | Determines the runtime security context imposed by Docker/OpenShift/Kubernetes. |
Therefore, taking a conventional $INFORMIXDIR and setting
runAsUser: 1001 does not turn it into an Informix non-root
installation. Equally, a conventional installation image running with UID 0 is
still the traditional installation model; the UID is a runtime security decision.
8. Oninit recommendation for enterprise/OpenShift deployments
For an Informix environment using HDR, RSS, Enterprise Replication, Connection Manager, normal Unix/enterprise authentication, and enterprise recovery tooling, the traditional root-based installation model should remain the product installation model.
| Stage | Action |
|---|---|
| Build image | Install Informix conventionally with the required root privileges. Preserve normal Informix ownership, permissions and enterprise feature support. |
| Runtime | Reduce container privileges separately, and only as far as verified safe. |
Do not use non-root installation mode as an SCC workaround
Giving up HA, ON-Bar and related enterprise capabilities to satisfy an OpenShift
runAsUserpolicy solves the wrong problem. The correct engineering task is to identify the minimum runtime UID/capabilities required by a conventional Informix installation and tighten the SCC/securityContext around that verified requirement.
Note that encrypted connections and column-level encryption are not themselves a reason to choose the root-based model — they are available under non-root installations provided the security-layer plug-in is installed separately.
9. Practical decision rule
| Requirement | Recommended installation model |
|---|---|
| HDR / RSS / SDS / HA topology | Root-based |
| Enterprise Replication across normal production systems | Root-based |
| ON-Bar / storage-manager backup | Root-based |
| Enterprise OS authentication / PAM / AD integration | Root-based |
| Production OpenShift deployment needing full Informix capability | Root-based install; solve runtime security separately |
| Embedded/developer appliance with no HA/ON-Bar requirement | Non-root may be appropriate |
| No root access to host and reduced capability is acceptable | Non-root may be appropriate |
10. References
- Installation owner — HCL Informix documentation — root versus non-root installation behavior and restrictions.
- Connections to a non-root installation (UNIX, Linux) — HCL Informix documentation — the
cfdoption and communication file locations. - HCL Informix security documentation — authentication and non-root installation considerations.
- IBM/HCL Informix documentation — installation-owner restrictions affecting Enterprise Replication.
Oninit® technical interpretation: the container/OpenShift guidance in this note separates Informix product installation mode from container runtime privilege policy so that enterprise database capability is not unnecessarily sacrificed to satisfy orchestration security constraints.