Read a Process Personality from /proc Without Guessing

You will finish with a reproducible way to inspect a process's Linux execution domain, understand the hexadecimal value in /proc/<pid>/personality, and prove when a child process has inherited a personality flag. The examples use the local Linux man-pages 6.7 documentation and util-linux 2.41.3.

Allow about fifteen minutes. You need a shell and a Linux system with procfs mounted. Reading your own process does not need elevated privileges. Reading another user's process may be rejected by the kernel's ptrace access check, so do not start with sudo as a way to make an unexplained result disappear.

1. Check the file and read your own process

The file is read-only. It exposes the execution domain selected for a process by the personality(2) system call, and reports the value in hexadecimal notation. Start with the shell's own process:

$ test -r /proc/self/personality && echo readable
readable
$ cat /proc/self/personality
00000000

/proc/self is a procfs link resolved by the kernel for the process doing the read. The exact value is host- and launcher-dependent. On an ordinary Linux process, 00000000 represents the base Linux personality, but treat the output as a value to inspect rather than text that names a mode.

Checkpoint: if the file is missing, check that procfs is mounted and that you are actually on Linux. If it exists but cannot be read for another PID, record that as an access-control result.

2. Read a specific PID safely

Replace PID with a process ID you are allowed to inspect. This is an ordinary read-only command:

$ PID=12345
$ test -r "/proc/$PID/personality" && cat "/proc/$PID/personality"
00000000

A process can exit between the test and the read. A missing file, a changed PID or a permission error is therefore normal failure handling, not evidence that the process has no personality. Use ps -p "$PID" -o pid=,comm= to check that the PID still names the process you intended.

The file has no setting interface. Do not try to write a new value to it, and do not describe it as a configuration file. To change a personality, a program must call personality(2) or use a launcher such as setarch(8).

3. Display the name and the raw value with setarch

If util-linux is installed, setarch --show gives a human-readable view of the current personality:

$ setarch --version
setarch from util-linux 2.41.3
$ setarch --show
PER_LINUX

The name is useful, but it does not replace the procfs value. The personality is a 32-bit value: the low byte identifies the base personality and the upper bytes contain flags that alter selected kernel behaviour. Read /proc/self/personality inside the command you are investigating when you need the exact value.

Do not assume that every value has a useful name. Some historical execution domains have little or no effect on current kernels, and flags can be combined. The man-page's descriptions of PER_LINUX, PER_LINUX32 and the flags are more reliable than pattern-matching a number from a log.

4. Prove inheritance with a harmless child

A personality belongs to a process. Use setarch --uname-2.6 to launch a short-lived child with the documented UNAME26 flag, then inspect that child from inside:

$ setarch --uname-2.6 -- /bin/sh -c 'cat /proc/self/personality; printf "\n"; uname -r'
00020000

2.6.68-139-generic

The hexadecimal value 00020000 is the UNAME26 flag in this run. The kernel makes uname(2) report a 2.6-style version, so the second line is intentionally not the host's normal release string. Your reported version will differ. The child exits when the shell command finishes, and no persistent system setting is changed.

Checkpoint: repeat the check without the flag:

$ /bin/sh -c 'printf "personality="; cat /proc/self/personality; printf "release="; uname -r'
personality=00000000
release=6.14.0-27-generic

The release shown above is illustrative of this machine and will vary. The useful comparison is the personality value and the fact that the flag affects the child only.

5. Inspect a memory-layout flag without changing the host

--addr-no-randomize sets the ADDR_NO_RANDOMIZE flag for the launched process. It is security-sensitive because address-space-layout randomisation is a defence against some memory-exploitation techniques. Use it only for a controlled diagnostic, never as a blanket workaround for a service:

$ setarch --addr-no-randomize -- /bin/sh -c 'cat /proc/self/personality; printf "\n"'
00040000

This command changes the child process's personality, not the kernel's global policy. Do not combine it with an untrusted program merely to make that program easier to debug. If a debugger or test requires the flag, record the exact launcher command and remove it when the test is complete.

6. Diagnose confusing results

If cat /proc/$PID/personality prints No such file or directory, the process probably exited or the PID was wrong. If it prints Permission denied, the ptrace access mode PTRACE_MODE_ATTACH_FSCREDS is the relevant boundary. Check ownership, dumpability and the host's security policy before escalating privileges.

If a child reports a surprising value, inspect the complete command line and its ancestors. A wrapper, test runner, container entrypoint or debugger may have set flags before your program started. Compare the value inside the target process, not in the parent shell.

Do not infer that a hexadecimal flag guarantees a particular application result. The kernel may ignore obsolete personalities, and some flags apply only to specific architectures or system calls. Use the documented effect and a focused test such as uname, rather than relying on the number alone.