Home
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running the QNX OS 8.0.
Programming
Programmer's Guide
The QNX OS Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX OS.
Processes
Your applications should be written in a way that reflects the architecture of the QNX OS—as a set of cooperating processes. In this chapter, we see how to start processes (also known as creating processes) from code, how to terminate them, and how to detect their termination.
Process privileges
In systems where security is important, applications should run with the fewest privileges possible. This practice helps reduce the impact of possible compromises and can also help lower the privilege escalation attack surface of the device.
Procmgr abilities
The QNX OS supports procmgr abilities, process-manager settings that govern which operations a particular process is permitted to do.
Locking an ability
An important aspect of procmgr abilities is ability locking, which allows you to force a specific ability to be immutable until the next time the process starts.

QNX Momentics IDE User's Guide
This User's Guide describes version 8.0 of the Integrated Development Environment (IDE) that's part of the QNX Tool Suite.
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running the QNX OS 8.0.
- Quickstart Guide
- System Architecture
  The System Architecture guide accompanies the QNX OS and is intended for both application developers and end-users.
- OS Components & Operations
- Graphics
- Programming
  - Getting Started with the QNX OS
    Getting Started with the QNX OS: A Guide for Realtime Programmers is intended to introduce you to the QNX OS and help you develop applications and resource managers for it.
  - Programmer's Guide
    The QNX OS Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX OS.
    - Compiling and Debugging
      Let's start by looking at some things you should consider when you start to write a program for the QNX OS.
    - QNX OS Architecture and Concepts
      The QNX OS architecture consists of the microkernel and several cooperating processes. These processes communicate with each other via various forms of interprocess communication (IPC). Message passing is the primary form of IPC in QNX OS.
    - Processes
      Your applications should be written in a way that reflects the architecture of the QNX OS—as a set of cooperating processes. In this chapter, we see how to start processes (also known as creating processes) from code, how to terminate them, and how to detect their termination.
      - Starting processes: two methods
        In embedded applications, there are two typical approaches to starting your processes at boot time.
      - Process creation
        The process manager component of procnto is responsible for process creation. If a process wants to create another process, it makes a call to one of the process-creation functions, which then effectively sends a message to the process manager.
      - Process termination
      - Detecting process termination
        In an embedded application, it's often important to detect if any process terminates prematurely and, if so, to handle it.
      - Stack allocation
        Each thread has its own stack that you can allocate yourself or have the system manage.
      - Process privileges
        In systems where security is important, applications should run with the fewest privileges possible. This practice helps reduce the impact of possible compromises and can also help lower the privilege escalation attack surface of the device.
        Privilege separation
        Privilege separation is a way of designing an application so that its underlying components are divided into a number of processes with differing privileges.
        Procmgr abilities
        The QNX OS supports procmgr abilities, process-manager settings that govern which operations a particular process is permitted to do.
        Ability domains
        The process manager supports PROCMGR_ADN_ROOT and PROCMGR_ADN_NONROOT flags that indicate which domain an ability applies to.
        Ability ranges
        The procmgr_ability() function also lets you specify subranges for specific abilities. This is useful for limiting certain abilities to the smallest number of privileges possible.
        Locking an ability
        An important aspect of procmgr abilities is ability locking, which allows you to force a specific ability to be immutable until the next time the process starts.
        Dropping an ability
        You can drop an ability that your application doesn't need at all, or that it no longer needs.
        Ability inheritance
        By default, procmgr abilities aren't inherited when you create a new process by using exec*(), posix_spawn*(), or spawn*().
        Creating abilities
        Not only can servers check that their clients have the appropriate abilities, but they can create custom abilities.
        An example of privilege separation
        Here's a basic example of privilege separation consisting of a low-privileged client and a high-privileged server. The example can easily be adapted to various design paradigms.
        Resource constraint thresholds
        In many systems, it's important to guard against clumsy or malicious applications that attempt to exhaust global resources.
        User and group IDs
        A process has different kinds of user and group IDs that can be modified to affect its privileges.
      - Controlling processes via the /proc filesystem
        Implemented by the Process Manager component of procnto, the /proc virtual filesystem lets you access and control the processes and threads running in the system.
    - Multicore Processing
      Multiprocessing systems, whether discrete or multicore, can greatly improve your applications' performance.
    - Working with Access Control Lists (ACLs)
      Some filesystems, such as the Power-Safe (fs-qnx6.so) and QNX compressed filesystems, extend file permissions with Access Control Lists, which are based on the withdrawn IEEE POSIX 1003.1e and 1003.2c draft standards.
    - Understanding the Microkernel's Concept of Time
      Whether you're working with timers or simply getting the time of day, it's important that you understand how the OS works with time.
    - Handling Hardware Interrupts
      This chapter explains the QNX OS mechanisms for quickly reacting to hardware events.
    - Working with Memory
      (or The Persistence of Memory, with a nod to Salvador Dali) In the Process Manager chapter of the System Architecture guide, we looked at how the OS manages memory. This chapter describes how you can work with memory.
    - Freedom from Hardware and Platform Dependencies
      The QNX OS can run on many different hardware platforms. The way in which applications can access peripheral devices and how data is stored varies between platforms. This chapter explains our solutions for minimizing the impact of such platform dependencies.
    - Conventions for Recursive Makefiles and Directories
      In this chapter, we'll look at the supplementary files used in the QNX OS development environment. Although we use the standard make command to create libraries and executables, we also use some of our own conventions in the Makefile syntax.
    - Glossary
  - Writing a Resource Manager
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX OS system and developers who want to create a QNX OS resource manager free from vulnerabilities.
- Utilities & Libraries
- Migrating to QNX OS 8.0
QNX Software in the Cloud
QNX Software in the Cloud enables developers to use the QNX OS in the Amazon cloud environment.
QNX Toolkit for Visual Studio Code
This User's Guide describes the QNX^® Toolkit for Visual Studio Code. The guide introduces you to the QNX Toolkit by explaining the QNX development environment and how to build, run, and debug your QNX^® Operating System (OS) applications and systems.
QNX Hypervisor User's Guide
This User's Guide explains the QNX hypervisor architecture and provides instructions for installing and running a QNX Hypervisor system, changing system components and configuration, and using hypervisor features such as virtual devices (vdevs).
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation, explains how to obtain technical support, and provides some information about licensing.

Locking an ability

QNX SDP8.0Programmer's GuideDeveloper

An important aspect of procmgr abilities is ability locking, which allows you to force a specific ability to be immutable until the next time the process starts.

This aspect is useful if an ability never needs to be reobtained, especially by a process that is root. This also allows non-inheritable abilities to not be subsequently marked as inheritable, and so on. Keep in mind that if you lock an ability and don't mark it as inheritable, then if and when you spawn a new process, that process will not have the ability locked.

The following example demonstrates how to lock a capability by using the PROCMGR_AOP_LOCK flag, effectively preventing it from being changed during the lifetime of the process. The following example specifically adds additional security to the PROCMGR_AOP_SUBRANGE example:

procmgr_ability(0,
                PROCMGR_ADN_NONROOT           // Non-root domain
                  | PROCMGR_AOP_ALLOW         // Allow the ability
                  | PROCMGR_AOP_LOCK          // Prevent further changes
                  | PROCMGR_AOP_SUBRANGE      // Limit ability to a subrange
                  | PROCMGR_AID_SPAWN_SETUID, // Requested ability
                (uint64_t)800, (uint64_t)899, // Subrange for ability
                PROCMGR_AID_EOL               // End of ability list
);

Once this call is made, the PROCMGR_AID_SPAWN_SETUID ability can't be modified by anyone. We recommend that you immediately lock all abilities expected to be static after set.

Note:

Take care when locking an allowed and inheritable ability. A vulnerability can be introduced if an allowed ability is locked and inheritable and the process then forks or spawns a child that doesn't require the ability or wishes to drop it. Locking should generally be reserved for situations where you are denying an ability. Always check the return code of procmgr_ability() and test for an error value of -1 to identify—early in development—these types of problems you may have with dropping abilities.

Page updated: March 05, 2025