Check a process's seccomp mode without using /proc/pid/seccomp

You will check the seccomp mode of a running process by reading /proc/PID/status, then distinguish the result from the obsolete /proc/PID/seccomp interface. Allow about ten minutes. You need a Linux host with procfs mounted and permission to inspect the target process.

1. Confirm the installed documentation

The local proc_pid_seccomp(5) page comes from the Debian manpages package, version 6.7-2, and is labelled Linux man-pages 6.7. It describes /proc/PID/seccomp as a historical interface available from Linux 2.6.12 through 2.6.22. Linux 2.6.23 removed it. Do not build a new script around a file that modern kernels do not provide.

$ dpkg-query -W -f='${Package} ${Version}\n' manpages
manpages 6.7-2
$ man 5 proc_pid_seccomp

Package versions vary. The useful fact is the history stated by the page: the old file returned 0 for no seccomp mode and 1 for strict mode, and writing 1 made strict mode irreversible for that process. That write is a security-sensitive state change, so this guide does not demonstrate it.

2. Read the current process status

For a process you own, replace PID with its numeric process ID. Reading status does not change the process and normally needs no elevated privileges:

$ PID=12345
$ grep '^Seccomp:' "/proc/$PID/status"
Seccomp:        0

The field reports the process's current seccomp mode. A value of 0 means disabled, 1 means strict mode, and 2 means filter mode. Spacing varies, so match the field name rather than assuming a fixed column layout. If the process exits between choosing the PID and reading the file, the command can report that the path does not exist; obtain a fresh PID and try again.

Checkpoint: record the PID and the value you observed. A successful grep proves that the status file was read. It does not prove that the process is safe to signal, trace or restart.

3. Check a shell and its child safely

/proc/self is convenient when a program wants to inspect itself. For a shell command, /proc/$$/status names the shell whose PID is in $$:

$ printf 'shell PID: %s\n' "$$"
shell PID: 12345
$ grep '^Seccomp:' "/proc/$$/status"
Seccomp:        0
$ sh -c 'printf "child PID: %s\n" "$$"; grep "^Seccomp:" "/proc/$$/status"'
child PID: 12346
Seccomp:        0

Your PIDs and modes will differ. This is a read-only smoke check for the current environment. It does not install a filter, enter strict mode or create a sandbox.

4. Understand what the old file could and could not do

The historical file was not a general policy document. Its documented write operation accepted 1, which put the calling process into strict seccomp mode irreversibly. Further writes failed with EPERM. Strict mode is deliberately narrow and can make an ordinary program die when it calls a system call outside the allowed set.

Do not try to recreate that operation with a guessed path, a redirected write or sudo. A missing /proc/PID/seccomp is the expected result on a current kernel, not a permissions problem. Elevated privileges do not bring back a removed procfs interface.

For current code, the kernel API is seccomp(2) or the related prctl(2) operations. Use PR_GET_SECCOMP when a program needs its own numeric mode, but treat it carefully: the current kernel documentation warns that querying from a filtered process can itself be blocked by the filter. Reading the Seccomp field in /proc/PID/status is the safer inspection method described by the proc documentation.

5. Diagnose a missing or unexpected result

First check that procfs is mounted and that the target still exists:

$ test -r "/proc/$PID/status" && echo 'status is readable'
status is readable
$ test -d "/proc/$PID" && echo 'process still exists'
process still exists

If either test fails, check the PID, namespace and process lifetime. A process in another PID namespace can have a different visible PID. A service supervisor, container runtime or orchestrator may also replace a process while you are inspecting it. Use the PID visible from the same namespace as the command doing the read.

If Seccomp: is 2, the process has a seccomp filter. That says nothing by itself about which system calls are allowed or what action a denied call takes. The filter's policy and the process's other security controls still matter. Do not attach a debugger, restart the service or change its unit merely because the number is unexpected; those actions can disrupt a service and may be irreversible without an operational rollback.

6. Recover from an unsafe experiment

Reading /proc/PID/status leaves no state to undo. If an existing test program has deliberately entered strict or filter mode, its seccomp state cannot be relaxed by writing to procfs. Stop the test process through its normal supervisor, or let it exit, then start a fresh instance from the known-good command and configuration. Do not restart a production service solely to change a diagnostic value; make that a planned maintenance action with a rollback path.