Inspect Linux Keyrings with /proc/keys and /proc/key-users

You will inspect the Linux kernel's keyring inventory without creating, deleting or changing a key. The two files have different jobs: /proc/keys lists visible individual keys, while /proc/key-users summarises key usage by owning user ID. Allow about ten minutes. You need a shell and a Linux system with the proc filesystem mounted. The examples use Linux 6.8.0-139-generic and the locally installed Linux man-pages package 6.7-2, so treat the displayed output as representative rather than a fixed interface for every kernel.

1. Confirm the files are available

These are read-only checks and normally need no elevated privileges. First verify the running kernel and that both paths exist:

$ uname -r
6.8.0-139-generic
$ test -r /proc/keys && echo /proc/keys-readable
/proc/keys-readable
$ test -r /proc/key-users && echo /proc/key-users-readable
/proc/key-users-readable

If either test fails, check that procfs is mounted and that you are on Linux. Do not create files with those names in another directory: a regular file is not the kernel interface described by proc_keys(5).

2. Read the visible key inventory

Print a small sample first. This avoids flooding a terminal on a busy host and does not alter key state:

$ sed -n '1,12p' /proc/keys
027558b5 I--Q---     7 perm 3f030000  1004  1004 keyring   _ses: 1
09c9bc02 I--Q---     4 perm 3f030000  1004   987 keyring   _ses: 1
20f4aa03 I--Q---     4 perm 1f3f0000  1004 65534 keyring   _uid.1004: empty
2146c11c IR-Q---   198 expd 3f030000  1004  1004 keyring   _ses: empty

The exact rows depend on the machine, the logged-in users and the services running. The first value is a key serial number, followed by status information and a reference count. The word after the status and count identifies the permission or expiry field, then the output shows the owner UID, group ID, key type and description. A keyring description such as _ses: identifies a keyring; the final count or empty describes its links in this display.

Do not interpret the file as a dump of secret payloads. The keyrings documentation describes IDs, types, descriptions, access rights and expiry as key attributes, but payload access is controlled separately and depends on the key type and permissions. Seeing a row does not grant permission to read its data.

3. Count and filter without changing anything

Use ordinary text tools to answer simple inventory questions. This counts visible rows and lists the key types appearing in the current view:

$ wc -l < /proc/keys
6
$ awk '{print $9}' /proc/keys | sort | uniq -c
      6 keyring

The column position in a description is not a stable parsing API: descriptions can contain spaces, and kernel output can evolve. Treat this awk example as a quick check for the simple rows shown here, not as a production parser. If you need a durable application interface, use the key-management system calls or a keyutils library rather than scraping procfs.

To look for a particular description without exposing more output than necessary, filter locally:

$ grep -F -- '_uid.' /proc/keys
20f4aa03 I--Q---     4 perm 1f3f0000  1004 65534 keyring   _uid.1004: empty

An empty result means no matching visible row at that moment. It does not prove that no such key exists: visibility and permissions matter, and the inventory can change as processes and credentials come and go.

4. Compare per-UID usage and quotas

/proc/key-users is a summary indexed by owning UID. Read a few lines and keep the UID separate from the counters:

$ sed -n '1,12p' /proc/key-users
    0:   239 238/238 208/1000000 6810/25000000
  113:     2 2/2 2/200 26/20000
 1004:     6 6/6 6/200 60/20000

The first number is the UID. The following values report key and keyring counts and the current-versus-limit quota figures maintained for that UID. The exact spacing is for humans, so preserve the line as evidence when investigating a host rather than assuming that every field is a shell-friendly name. A high count or a quota limit is not, by itself, proof of a leak: sessions, services and kernel components can legitimately retain keys.

Compare one UID without changing the system:

$ awk '$1 == "1004:" {print}' /proc/key-users
1004:     6 6/6 6/200 60/20000

If the UID is not present, the kernel currently has no summary row for that exact value in the file you read. Check the spelling of the colon and remember that a user can have no retained key record even while other users do.

5. Investigate a surprising entry safely

Start with context, not deletion. Record the current UID, process list and a fresh copy of the two inventories:

$ id
uid=1004(example) gid=1004(example) groups=1004(example)
$ ps -eo pid,uid,comm --sort=uid | sed -n '1,12p'
$ sed -n '1,40p' /proc/keys > /tmp/proc-keys.snapshot
$ sed -n '1,40p' /proc/key-users > /tmp/proc-key-users.snapshot

The snapshot commands write only under /tmp; they do not modify kernel keys. They can still reveal key descriptions and account information, so protect the files as sensitive diagnostic material and remove them when the investigation is complete:

$ rm -- /tmp/proc-keys.snapshot /tmp/proc-key-users.snapshot

This removal is irreversible for those snapshots, but it does not touch the kernel keyrings. Before running it, check the paths exactly. Never replace it with a broad command such as rm -rf /tmp/*.

6. Know when elevated access is relevant

Reading these proc files is normally an unprivileged operation, but the rows you can see are governed by the kernel's key permissions and the calling credentials. If a diagnostic tool reports permission denied, do not assume that sudo cat /proc/keys is a safe universal fix. Elevated access can expose more security-sensitive metadata and changes the question you are testing. First record the failure and inspect the proc mount and file permissions:

$ findmnt -T /proc/keys -o TARGET,FSTYPE,OPTIONS
$ stat -c '%A %U:%G %n' /proc/keys /proc/key-users

Only use an approved administrative session when your incident or system policy requires a privileged comparison. These commands do not edit keyrings, but the information may help reveal authentication or encryption-related state. Do not copy the output into public tickets without reviewing descriptions and account identifiers.