# Privileged Workflows

Namespace Runner Instances run the runner software itself in a container. This approach facilitates software packaging and enables [custom base images](/content/docs/solutions/github-actions/custom-base-images.md).

If your workflow requires deeper access to the host system, Namespace can run your workflow as privileged and in the host pid namespace. A common case that requires this is modifying kernel settings using sysctl.

Another case is tooling that creates its own mount or user namespaces, such as bubblewrap (`bwrap`), which some sandboxing and Nix workflows rely on. Without privileged mode these tools fail with an error like `pivot_root: Operation not permitted`. Enabling `container.privileged` resolves it.

See the [Runner Controls overview](/content/docs/solutions/github-actions/runner-controls.md) for how to pass these settings via a profile or labels.

**With runner profiles**

To make the runner container privileged append the feature `container.privileged`. Similarly, you can select the host pid namespace with `container.host-pid-namespace`.

```yaml {2} theme={null}
runs-on:
  - namespace-profile-e2e-large;container.privileged=true;container.host-pid-namespace=true
```

**With runner labels**

If you are configuring the runners with labels, you can make the runner container privileged by enabling the feature `container.privileged` and can run in the host pid namespace with `container.host-pid-namespace`, e.g.

```yaml {3} theme={null}
runs-on:
  - nscloud-ubuntu-22.04-arm64-4x16-with-features
  - namespace-features:container.privileged=true;container.host-pid-namespace=true
```

## Next steps

* [Runner Controls overview](/content/docs/solutions/github-actions/runner-controls.md)
* [Swap space](/content/docs/solutions/github-actions/runner-controls/swap.md)