Technical Articles

Informix Privilege Architecture: Root, Non-Root, HA, and Containers

Why the conventional engine keeps SUID-root binaries, what the non-root model actually removed, why Enterprise Replication was adapted to it and HDR was not, and what all of that means under OpenShift.

This is the companion to Informix Root vs Non-Root Installation, which covers the two installation models and their supported differences. That article answers what. This one attempts why — and is careful about the difference between an answer IBM published and an answer the evidence merely points towards.

How to read this article

The central question here — why high-availability clusters remain unavailable to non-root installations — has no published vendor answer. An article that guesses and sounds confident would be worse than useless, so every substantive claim below carries its basis:

OFFICIAL	Stated directly in IBM® or HCL product documentation.
HISTORICAL	Contemporaneous IBM or IIUG conference material. Evidence of design intent at the time; not a current support statement.
INFERRED	Our conclusion from documented behaviour. IBM and HCL have not stated it, and it may be wrong.

Section 15 sets out exactly what would confirm or demolish the inferences, and invites correction from anyone holding the material.

1. Why conventional installations retain root-owned SUID binaries

OFFICIAL. A conventional Informix® installation ships a defined set of utilities as SUID root and SGID informix:

SUID root, SGID informix:
  onaudit  onbar_d  ondblog  onedcu  oninit  onmode
  onshowaudit  onsmsync  onsnmp  onsrvapd  ontape  snmpdm

SGID informix:
  oncheck  onedpdu  onload  onlog  onparams
  onpload  onspaces  onstat  onunload  xtree

OFFICIAL. These utilities do not run at all if the installation path is not secure — a deliberate precaution against tampering. The privilege model and the directory-security model are a single design, not two.

HISTORICAL. The 2013 IIUG session All About Private Servers states what that privilege buys, in the speaker’s own framing. A regular server is owned by user informix and group informix; programs in $INFORMIXDIR/bin are SUID and SGID; some VPs run with root privileges; and the server can use those privileges to create files in a user’s home directory, run the commands for a SYSTEM statement as the invoking user, and make changes that only root is permitted to make.

That is the honest answer to “why does Informix need root?”. Not one privileged operation, but a family of them, concentrated in identity handling and file access on behalf of other users.

2. Why `oninit` specifically is SUID root

OFFICIAL. The documented default mode of oninit is established indirectly but beyond argument. To allow DBSA-group users other than informix to run it, IBM instructs an administrator to log in as root and change the permissions on $INFORMIXDIR/bin/oninit from 6754 to 6755:

$INFORMIXDIR/bin/oninit
owner: root
group: informix
mode:  6754
       ^^
       SUID root + SGID informix

OFFICIAL. IBM’s error documentation supplies one concrete, citable consequence. Error 35589 concerns the file-descriptor limit: running oninit without setuid causes the server to use the descriptor limit inherited from the invoking shell, and file descriptors are consumed by chunks and network connections. Running as root is identified as one way around the resulting restriction.

Do not overstate this

The descriptor limit is a documented example of root privilege being functionally significant rather than merely historical packaging. It is not a statement that this is the reason, or the only reason, oninit is SUID root. We have found no IBM or HCL source identifying a single privileged operation as the complete explanation, and the evidence in section 1 suggests there isn’t one.

3. What happens when `informix` invokes `oninit`

OFFICIAL. On UNIX, Linux and Mac OS X you must be logged in as user root, user informix, or the non-root database server owner to run oninit.

OFFICIAL — and standard UNIX semantics. When user informix executes a binary whose mode is 6754, the setuid bit causes the process to take root as its effective user ID. Nothing unusual is happening; this is what the setuid bit is for. The real UID remains informix; the effective UID becomes root.

informix  ->  exec $INFORMIXDIR/bin/oninit   (mode 6754, owner root)
              real uid:      informix
              effective uid: root
              effective gid: informix

4. Why the master `oninit` may appear as root

This causes more confused incident calls than any other item in this article.

INFERRED from documented behaviour and UNIX semantics. A ps listing showing the master oninit owned by root, on a server that the DBA started as informix, is the expected result of a correctly installed conventional Informix. It is not evidence of a misconfiguration, it is not evidence that somebody started the engine as root, and it does not mean the installation has become a different kind of installation.

The reverse inference is the dangerous one. Seeing root-owned oninit processes and concluding “this must be a root installation, so let us make it a non-root installation instead” confuses a runtime observation with an installation model that can only be chosen at install time. See section 11.

5. Root-based privilege model versus the private-server model

HISTORICAL. The cleanest statement of the contrast comes from the 2013 IIUG material, which sets the two side by side:

	Regular server	Private server
Owned by	User `informix`, group `informix`	An ordinary user — not root, not `informix`
`$INFORMIXDIR/bin`	Programs are SUID and SGID	Programs are neither SUID nor SGID
Virtual processors	Some VPs run with root privileges	No VPs run with root privileges
Files for other users	Can create them	Cannot
`SYSTEM` statement	Can switch users	Cannot switch users; runs as the server owner
The owner’s group	Completely trusted	Not trusted

HISTORICAL. The 2011 session states the design decision that produced the right-hand column, and is candid about its scale: “No root privileges, no SUID or SGID is radical.” The same slide floats possible mitigations that were evidently under discussion — reinstating SUID or SGID programs, group-write plus SGID on a role directory, root-assisted operation for SYSTEM, file operations and authentication. None of these shipped. The private server stayed radical.

6. What actually changes in the non-root architecture

HISTORICAL. The 2011 session enumerates the engine-level consequences, and the list is more informative than any summary of it:

Cannot switch UID or GID without root privileges — so the SYSTEM statement runs as the server owner.
Private servers cannot write in /INFORMIXTMP, which affects server discovery, shared-memory connections and IPC stream connections.
Cannot create files everywhere — affecting SET EXPLAIN, SET DEBUG FILE, LOTOFILE, and FILETOBLOB / FILETOCLOB file reads.
Cannot use the Unix password, because that requires root privileges. PAM and GSSCSM continue to work; mapped users become important.
Processor affinity does not work.
The resident shared-memory option does not work.
Changing owner or group on files: the operation is either not attempted, or its error is ignored.
Chunk permissions become 600 rather than 660; the main shared-memory segment gets no group or public access.
Startup security checks become more complex — hence onsecurity -p, which checks permissions appropriately for a private server.

INFERRED. Read as a set, these are not feature removals. They are the specific places where the engine previously relied on being able to act as somebody else, or to write somewhere it does not own. That is the shape of the whole problem, and it is worth carrying into section 7.

7. ER versus HDR, RSS and SDS

This is the question the whole article exists for. The facts are clear; the explanation is not.

What is documented and historical

HISTORICAL. In 11.70, the 2011 session lists under Not Supported (Yet): MACH 11 — HDR, SDS, RSS — and ER; I-Star; ON-Bar with ISM; role separation; SNMP. ER and the HA cluster technologies were in the same bucket, with the same parenthesis.
HISTORICAL. In 2013 the wording had softened to “ER, HDR, RSS, SDS are problematic”, alongside “distributed query is problematic”.
OFFICIAL. Informix 12.10 delivered Enterprise Replication among non-root servers. The restriction in current documentation is only that ER is unavailable for servers that have different owners.
OFFICIAL. Distributed queries on non-root installations also became supported, once REMOTE_USERS_CFG or REMOTE_SERVER_CFG is set — the alternatives to ~/.rhosts and /etc/hosts.equiv respectively.
OFFICIAL. High-availability clusters remain unavailable in a non-root installation, in current 14.10 documentation.

So: three capabilities entered the 11.70 restriction list together. Two came out. One did not.

INFERRED — what this suggests

The two that came out, ER and distributed query, were both unblocked by the same class of fix: a way to express trusted users and trusted hosts that a non-root owner can maintain, replacing files only root can be trusted to own. That is a server identity and trust problem, and IBM engineered around it.

Because those same trusted-server mechanisms are equally applicable to the connections an HA cluster makes, remote authentication alone does not appear to explain why HDR, RSS and SDS stayed behind. Something else is load-bearing.

The architectural difference between the two families is the obvious candidate. ER is logical replication between independent server instances:

logical changes
    -> ER capture
    -> ER queues
    -> network transport
    -> remote apply on an independent instance

HDR, RSS and SDS are not that. They are extensions of the engine’s own recovery and server-role machinery:

PRIMARY
    -> physical / logical recovery stream
    -> secondary recovery state
    -> chunk, log and checkpoint state
    -> role transitions
    -> promotion / demotion

OFFICIAL. One documented detail is at least consistent with this reading. Starting a secondary server uses oninit -PHY — physical recovery without logical recovery — followed by onmode -d secondary or onmode -d RSS to attach it to the primary. Both oninit and onmode are in the SUID-root utility set of a conventional installation.

What we are not claiming

That oninit and onmode are SUID root does not establish that secondary-server startup or role transition requires root privilege. Every Informix installation runs oninit, including private servers, which start perfectly well without it. The observation is suggestive, not probative.

We have found no IBM or HCL statement that high availability is excluded from non-root installations because some named subsystem requires some named privileged operation. Until such a source turns up, the honest position is that the restriction is documented and the reason is not.

8. What is documented and what is inferred about the HA restriction

Statement	Basis
HA clusters are unavailable in a non-root installation.	OFFICIAL
ER is available among non-root servers with the same owner, from 12.10.	OFFICIAL
Trusted-server and trusted-user configuration exists that does not need root-owned files.	OFFICIAL
HDR, SDS, RSS and ER were all excluded in 11.70, described as “Not Supported (Yet)”.	HISTORICAL
The exclusion was framed by the implementing engineer as incomplete work rather than as an architectural impossibility.	HISTORICAL — this rests on the word “Yet” and on the 2013 word “problematic”.
Remote authentication alone does not explain the surviving HA restriction.	INFERRED
The surviving dependency lies somewhere in recovery, storage, role-transition or privileged server-control paths.	INFERRED — plausible, unproven.
HA was never reworked or certified for non-root operation, rather than being impossible.	INFERRED — this is the reading we find most consistent with the evidence.

For anyone planning a deployment, none of this uncertainty matters: the restriction is real and current, and an HA topology requires a root-based installation. The uncertainty matters only to the explanation.

9. OpenShift: SCCs, arbitrary UIDs and privilege escalation

OFFICIAL (Red Hat). OpenShift’s restricted and restricted-v2 security context constraints are built around unprivileged workloads: project-assigned UIDs, restricted privilege escalation, SELinux confinement and limited host access.

OFFICIAL (Informix). A conventional Informix installation assumes root-owned installation assets, user informix, SUID-root and SGID-informix utilities, and conventional DBSA ownership.

These two models disagree, and the disagreement has three distinct edges.

Arbitrary UIDs. OpenShift may assign a runtime UID such as:

1000710000

INFERRED from the OpenShift security model and Informix’s documented ownership model. That UID is not informix, is not present in /etc/passwd, does not own the Informix files, and is not a DBSA in Informix’s security model. A conventional installation therefore generally needs a fixed or explicitly permitted runtime identity rather than OpenShift’s generic arbitrary-UID pattern.

Privilege escalation. Hardened workloads commonly set:

securityContext:
  allowPrivilegeEscalation: false

OFFICIAL behaviour, INFERRED consequence. That setting exists precisely to prevent a process from gaining privileges through mechanisms such as setuid and setgid executables. Applied to a conventional Informix installation running as an unprivileged UID, it can therefore prevent the product from exercising the privilege model IBM deliberately built into oninit. The setting and the installation are not merely in tension; they target the same mechanism from opposite directions.

UID 0 is not a privileged container. OpenShift’s anyuid SCC and a fully privileged container are different things. Permitting UID 0 does not by itself grant host PID access, host networking, unrestricted capabilities or host filesystem access. The claim “if Informix runs as UID 0 in OpenShift the pod must be fully privileged” is simply false, and it is worth rebutting, because it is frequently the argument that pushes a team towards a non-root installation they will later regret.

10. Why `runAsNonRoot` is not an Informix non-root installation

Four configurations are routinely conflated. They are not the same:

A. Conventional root-based Informix on Linux
B. Conventional root-based Informix packaged in a container
C. An Informix non-root installation, as the product defines it
D. A container forced to run with runAsNonRoot: true

OFFICIAL plus INFERRED clarification. B and D do not become C. Informix’s non-root installation is a distinct installation type with different ownership, different authentication, different IPC behaviour and a different supported feature set, established when the installer runs. A runtime security context, applied later to an image built the conventional way, changes none of those things. It only changes what the installed product is allowed to do — which, per section 9, may be less than the product needs.

HISTORICAL. That conventional container images are built as root is not controversial. The reference Dockerfile in IIUG 2016 session A14, Dockerized Informix, opens with FROM centos:centos7 followed by USER root.

11. Why stripping SUID or recursively changing ownership is not equivalent

OFFICIAL. Conversion between installation models is unsupported in both directions. You cannot change the owner of the database server, and you cannot convert or upgrade a non-root installation to a standard root-based one, or the reverse.

Therefore neither of the following produces a supported non-root installation:

chown -R informix:informix $INFORMIXDIR
chmod -s $INFORMIXDIR/bin/oninit

INFERRED. What those commands actually produce is a root-based installation with its security properties altered, outside any support statement, and with the privileged operations of section 1 now failing in ways the engine was not designed to encounter. A genuine non-root installation is not a root-based installation with permissions removed — it is a build in which no SUID or SGID programs were ever created, the owner’s group is never trusted, no virtual processor holds root privilege, and the startup security checks know all of this. Section 6 lists the engine behaviour that changes accordingly. None of it is reachable with chmod.

12. SELinux, persistent volumes and storage

OFFICIAL OpenShift concepts, with operational inference. Access to a containerised Informix’s storage is governed by several independent layers at once:

UID / GID ownership
  + Unix mode bits
  + SELinux label and context
  + SCC
  + capabilities
  + storage class / PVC behaviour

A correct chown and chmod therefore does not by itself guarantee access. For Informix this applies to every persistent path the engine depends on: dbspace chunks, logical log and physical log locations, the message log, backup targets, temporary areas, and generated runtime configuration.

Raw and host block devices raise the difficulty further, because they demand tighter integration with host device security than a filesystem PVC does. And the combination that causes the most trouble in practice is an arbitrary project UID meeting a persistent volume whose contents were written by a previous pod under a different UID.

OFFICIAL. One Informix-specific storage constraint is worth repeating in this context: to use onipcstr connections, the installation directory must be on a local file system, since a named domain socket cannot be created on a non-local one.

13. Security implications and trade-offs

HISTORICAL. The case for the non-root model was never that it is less capable. It was that root privileges are rigorously controlled in regulated industries; that some embedded systems have no root to speak of; that requiring user informix and group informix is itself friction; and that, as the 2013 session puts it, auditors question SUID and SGID programs.

All four remain valid reasons. The trade-off is simply that the model which answers them also removes HA clustering, ON-Bar, role-separated auditing, onperf, ER between differently-owned servers, and OS-level password authentication — and that the choice cannot be revisited without reinstalling.

INFERRED. For a containerised enterprise deployment the more productive framing is usually not “which installation model satisfies the SCC” but “what is the minimum runtime privilege a conventional installation genuinely needs, and can the SCC be written around that?”. The first question trades away database capability to satisfy a platform policy. The second treats them as the separate problems they are. Where the answer to the second is genuinely “no” — a hard organisational prohibition on SUID binaries or on any deviation from restricted-v2 — then the non-root model is the honest option, and the HA and backup architecture has to be designed around its absence from the start rather than discovered later.

14. Private Server and Mapped Users: the original design intent

HISTORICAL. IIUG Insider issue #133, July 2011, announced an IBM Chat with the Lab session titled All about Informix Private Server and Mapped Users. The announcement records that Informix 11.70 introduced the ability to install and run without access to user root or user informix, and explains that because such a server cannot use normal OS authentication, Informix introduced Mapped Users.

That pairing is the point. Mapped Users is not an adjacent security feature that happened to arrive in the same release — it is the replacement for a capability the private server had to give up. IBM also published developerWorks material on the private installation feature from the client perspective, which IIUG referenced again in later Insider issues.

OFFICIAL. The mechanism as it stands today: the DBSA creates internal users; database users can be given OS properties — UID, GID, home directory — that the server uses when acting on their behalf; and from 11.70.xC3 the OS administrator can constrain which OS users and groups may act as surrogates, via /etc/informix/allowed.surrogates.

INFERRED. Seen against section 7, the history has a consistent shape. Every capability the private server recovered — authentication via mapped users, ER, distributed query — was recovered by replacing a root-owned identity mechanism with one the installation owner can maintain. The capabilities never recovered are the ones whose dependency was not identity.

15. Evidence map and unresolved questions

This article rests on an inference, and we would rather it were tested than repeated. The following would settle it.

What would confirm the inference

Any IBM or HCL statement naming a specific subsystem — physical recovery, checkpoint coordination, shared-disk access, role transition — as the reason HA is excluded from non-root installations.
Q&A notes, audio or transcript from the 2011 IBM Chat with the Lab session All about Informix Private Server and Mapped Users, where the question was most likely to have been asked and answered directly.
Any release note or RFE response explaining why ER was enabled for same-owner non-root servers in 12.10 while HA was not.

What would demolish it

A statement that the HA restriction is a support, test-matrix or certification decision rather than a technical dependency — which would make the architectural reasoning in section 7 beside the point, however tidy it looks.
Evidence that HA in a non-root installation works but is simply not supported.

Where we have looked

The IIUG conference archive from 2007 to 2019, in full: the 2011 and 2013 Leffler sessions are the substantive finds, and neither explains the HA exclusion. Current IBM 12.10 and 14.10 documentation on installation ownership, non-root connections, utility privileges and oninit. The 12.10 Enterprise Replication release material. No source found so far states the reason.

If you were in the room for that Chat with the Lab session, or hold the deck, audio or notes, we would genuinely like to hear from you — this article will be updated and the correction credited.

16. References

Product documentation

Users and group membership for running utilities — IBM Informix 14.10 — the SUID root and SGID informix utility lists, and the secure-installation-path requirement.
The oninit utility — IBM Informix 14.10 — who may run oninit; the 6754 to 6755 change for DBSA-group users; oninit -PHY and its relationship to onmode -d secondary and onmode -d RSS.
Installation owner — IBM Informix 14.10 — the two installation models, the unsupported-feature list, and the impossibility of conversion.
Connections to a non-root installation (UNIX, Linux) — IBM Informix 12.10 — communication files, the cfd option, and distributed queries on non-root installations.
What’s new in Enterprise Replication, Informix 12.10 — ER among non-root servers.
REMOTE_SERVER_CFG and REMOTE_USERS_CFG configuration parameters — IBM Informix 12.10.
IBM Informix error messages — error 35589, on the file-descriptor limit inherited from the shell when oninit runs without setuid.
Red Hat OpenShift Container Platform documentation — security context constraints, project UID ranges, and the distinction between anyuid and privileged.

Historical and supporting material

Jonathan Leffler, IBM. Installing and Running IDS 11.70 Without Using Root Privileges. IIUG 2011 conference, session C18, 18 May 2011. Source for the “Not Supported (Yet)” list, the installer’s behaviour, the engine-level changes in section 6, and the unimplemented mitigations in section 5.
Jonathan Leffler, IBM. All About Private Servers — Tips, Tricks and Traps. IIUG 2013 conference, session B10. Source for the regular-versus-private comparison in section 5, the root-privilege uses in section 1, and “ER, HDR, RSS, SDS are problematic”.
Rakesh Naik, IBM. Test Drive some of the NEW Informix 11.70 features. IIUG 2012 conference, session H04. 11.70.xC3 shared-memory and stream-pipe support for non-root installations; /etc/informix/allowed.surrogates.
IIUG Insider issue #133, July 2011 — announcement of the IBM Chat with the Lab session All about Informix Private Server and Mapped Users.
Stefan Schaller. Dockerized Informix. IIUG 2016 conference, session A14 — reference Dockerfile building as USER root.
IIUG 2016 Informix 12.10 certification preparation material — ER among non-root servers; trusted-server configuration parameters.

Oninit® technical interpretation: the documented restrictions in this article are reproduced as published. The explanation offered for the surviving high-availability restriction is our inference from the evidence available to us, is labelled as such throughout, and should not be read as IBM’s or HCL’s stated rationale.