Name
security — Scope for defining which permissions are retained by which user
Synopsis
security { ... }
Description
It is generally agreed that running with "root privileges" is dangerous for Internet servers. As such, Linux exposes a "security" system that allows a non-privileged user to retain certain root privileges.
The following is an example of using the Security scope in a single-node configuration:
Security { user = ecuser group = ecuser # Allow binding to privileged ports without requiring a process restart Capabilities = "cap_net_bind_service+ep" }
The following is an example of using the Security scope on a cluster node:
Security { user = ecuser group = ecuser Capabilities = "cap_net_admin+ep cap_net_bind_service+ep cap_net_raw+ep cap_sys_resource+ep" }
In a cluster configuration, when you accept the default configuration, the definition of the Security stanza in the ecelerity-cluster.conf file overrides the configuration defined in the ecelerity.conf file.
Warning
We do not recommend that the user in a Security stanza be set to root. However, if you do set user to root you will encounter permissions problems because capabilities are exclusive and not cumulative. Specifically, the dmllog.rt jlog won't be consumed, because it is written by a process that runs as ecuser, and when you run as root and define Capabilities, you lose the "root access to all files" capability unless it's defined in the capabilities set. If you must run as root, comment out the Capabilities option.
The following are the options valid in the security scope. For additional details about each option, follow the link:
Note
Changing the value of options in the security scope at runtime requires restarting the ecelerity process—issuing the ec_console command config reload will not suffice.
Scope
security is valid in the global scope.