Abilities

Root and non-root abilities

In traditional UNIX-like operating systems, a process that runs with a user ID of zero (UID 0; the root user or superuser) has extensive system-wide permissions that users that run as any other user ID don't.

Both sets of abilities can be configured to allow a non-root process to become more privileged than normal and a root process to become less privileged.

Static vs. custom abilities

Because a process's abilities may also be tested by a server process that receives a message from it, abilities can control things outside the domain of the kernel and process manager. To make this capability more useful, the set of 70 or so static abilities may be augmented by additional custom abilities, allowing processes to use abilities to control access to whatever they see fit.

For a list of static and custom abilities defined by QNX, go to the Abilities Reference chapter.

Configuring abilities

Use of abilities allows the privileges assigned to a process to be tailored to its needs rather than being all or nothing. QNX recommends that you configure abilities using security policies. For a full discussion of the advantages of this feature, go to the Security Policies chapter.

The pre-security-policies way to configure abilities is to start up a process as root with the full set of abilities. After completing initialization, the process reconfigures its non-root set of abilities, granting privileged abilities it will require and dropping others. It then calls setuid() to switch permanently to non-root and continues with just what it needs for its operation. For more information, go to the procmgr_ability() entry in the C Library Reference.

The pidin utility allows you to display abilities information about a process. See the pidin entry in the Utilities Reference.

Ability ranges

Some abilities may have one or more subranges associated with that ability that further refine how the ability is granted:

• If the ability is allowed and there are no subranges, then the ability is granted unconditionally.
• If the ability is denied, then the subranges are ignored.
• If you specify a subrange for an allowed ability, it is only allowed for a request that matches the subrange.
• For access checks that span a range, the entire range must be covered by a single subrange. For example, the PROCMGR_AID_MEM_PHYS ability with the enabled subranges 100–200 and 190–300 does not allow a request for the subrange 150–250.
• If the ability is not inherited, then the subranges are discarded when the process spawns or execs.

Ability names

Every ability has a name that is used in security policies and in the output of tools such as pidin and secpolgenerate. When you use an ability programmatically with functions such as procmgr_ability() and ConnectClientInfoAble(), you must use the ability's equivalent numeric identifier instead.

For static abilities, constants are available and formed by adding the prefix PROCMGR_AID_ to the ability name in uppercase. For example, the constant for the able_create ability is PROCMGR_AID_ABLE_CREATE. The static constants for abilities are defined in /usr/include/sys/procmgr.h.

Custom abilities have no predefined constant. Instead, you can obtain the ability's numeric identifier by passing the ability name to either procmgr_ability_lookup() or procmgr_ability_create().