How to List the Linux Processes That Can Change a File's Immutable Flag

If you want to know which running processes can set or clear a file's immutable attribute, stop searching /proc for the capability's name — the kernel never writes capability names there. Each process keeps its capability sets as hex bitmasks under generic field names, so a pattern like CapIm can never match anything. Run pscap for a decoded list, or test bit 9 (0x200) of the CapEff line in every /proc/<pid>/status file yourself.

What the immutable flag protects, and what unprotects it

chattr +i sets the immutable flag in a file's inode. While it is set, the file cannot be modified, deleted, renamed, or hard-linked, even by root. Changing the flag itself is gated too: setting or clearing it requires CAP_LINUX_IMMUTABLE in the calling process's effective capability set. Being uid 0 alone is not enough. In containers or hardened services where that capability was dropped from the bounding set, root gets "Operation not permitted" from chattr +i — which is exactly why the flag makes a useful guard against casual damage.

Why the grep pattern matched nothing

Every process status file carries five capability lines, and none of them is named after an individual capability:

CapInh: 0000000000000000
CapPrm: 000001ffffffffff
CapEff: 000001ffffffffff
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000

These hold the inheritable, permitted, effective, bounding, and ambient sets, encoded one bit per capability. The nearest spelling to CapIm is CapInh, but grep matches literal substrings, and CapIm is not a substring of any field name — so the search exits silently. The information you want is present; it just needs decoding.

Decode the masks yourself

CAP_LINUX_IMMUTABLE is bit 9, value 0x200. Confirm that with capsh:

$ capsh --decode=200
0x0000000000000200=cap_linux_immutable

Then, running as root so you can read every process's status file, mask bit 9 out of each CapEff value:

for s in /proc/[0-9]*/status; do
  eff=$(awk '/^CapEff/ {print $2}' "$s")
  if [ $(( 0x$eff & 0x200 )) -ne 0 ]; then
    echo "${s%/status}: $(cat "${s%/status}/comm")"
  fi
done

Keep the 0x prefix: the kernel prints the masks with leading zeros, and shells interpret a leading zero as octal, which breaks the arithmetic.

The readable route: pscap

With libcap-ng-utils installed, pscap parses the same status files and prints capability names, saving you the bit arithmetic. One caveat: a process holding every capability is reported simply as full rather than enumerated — and full includes cap_linux_immutable. Expect many full rows, because most daemons started as root never bother to drop capabilities:

$ pscap | grep crond
ppid    pid     uid     command     capabilities
1       869     root    crond       full

That single word carries a practical warning: anything cron runs inherits the full set, including the power to unseal your protected files. The flag's strength therefore depends on also locking down the configuration of every full-capability launcher on the system — cron spool entries and drop-ins under /etc/cron*, systemd units and timers, and similar.

Protecting configuration files in practice

Knowing who holds the capability is useful, but the most common failure is self-inflicted. To edit a protected file you switch to root — a setuid-root shell regains every capability — run chattr -i, make the change, and forget to re-apply +i. The file is then ordinary again, and the next cleanup script or careless rm can destroy it. Reduce that risk:

• Script the sequence. Wrap unseal, edit, validate, and re-seal in one tested script so the flag is never left off, and confirm afterwards with lsattr.
• Keep restorable backups. The flag guards against mistakes, not hardware failure. Test that you can restore the files to a scratch directory before you need to.
• Watch for changes. An integrity checker such as AIDE or tripwire will flag modifications to protected files — or a flag that has vanished.
• Shrink the trusted set. Audit the pscap output and control what each full process is allowed to execute.

Frequently Asked Questions

Why does chattr +i fail with "Operation not permitted" even as root?

Effective uid 0 is not sufficient on its own; the process's effective set must also contain CAP_LINUX_IMMUTABLE. Containers and hardened services often drop that capability, so root inside them cannot change the flag.

Which bit is CAP_LINUX_IMMUTABLE?

Bit 9, value 0x200. Verify with capsh --decode=200, which prints 0x0000000000000200=cap_linux_immutable.

What do the five Cap* fields in /proc//status mean?

CapEff is what the process can use right now, CapPrm is what it may raise into the effective set, CapInh survives exec, CapBnd caps the whole process tree, and CapAmb passes permitted bits across exec. For this question, only CapEff matters.

How do I check a single process instead of all of them?

Read its CapEff line, for example grep CapEff /proc/1234/status, then decode the value with capsh --decode=<value>, or run pscap and pick out the pid.

Is the immutable flag a real security boundary?

No. It blocks modification, deletion, rename, and linking by processes lacking CAP_LINUX_IMMUTABLE, but any process with the full capability set — most root daemons and your own root shell — can clear it at will. Treat it as a guard against accidents, not against root.