An account that can write utmp can forge a login that never happened, which is why the permission check here matters more than the output formatting. This guide gets you a read-only way to see who is logged in, inspect recent login history, and check that Linux's utmp and wtmp files are not writable by untrusted users. The workflow uses the installed tools and leaves the records alone unless you explicitly repair their permissions.
Allow about 15 minutes. You need a shell and, for the optional permission repair, an account with sudo access. The examples were checked on Ubuntu with the manpages package at version 6.7-2, libc6 2.39-0ubuntu8.9, GNU coreutils 9.4 and util-linux 2.42.4. Output will vary with the machine's sessions and history.
Linux normally stores the live-session database at /var/run/utmp and the historical login database at /var/log/wtmp. Confirm both paths and their metadata before interpreting any output:
$ stat -c '%n %a %U %G %s bytes' /var/run/utmp /var/log/wtmp
/var/run/utmp 664 root utmp 5376 bytes
/var/log/wtmp 664 root utmp 1041408 bytesThe numbers above are examples from one host. The useful checks are that the files exist, are owned by the expected system account and group, and are not writable by the file's other class. Do not assume that a different size means corruption: utmp is a sequence of fixed-size records, while wtmp grows with recorded activity.
Checkpoint: If either path is missing, stop here. The man page says that Linux utmp must always exist. Do not create an empty replacement or remove wtmp as a first troubleshooting step.
Use who for the normal human-readable view of utmp:
$ who -H
NAME LINE TIME COMMENT
alice pts/0 2026-09-27 11:12 (203.0.113.98)
alice pts/2 2026-09-27 13:00 (tmux(1998).%172)
alice pts/3 2026-09-27 16:45 (tmux(1998).%184)Read this as a snapshot, not a complete account of every user. The format records sessions for programs that write utmp; the man page explicitly warns that some programs do not. A terminal can also appear through a multiplexer or another local arrangement, so investigate an unexpected line before treating it as evidence of an intruder.
For a script, prefer an exit status and machine-readable interface supplied by the tool you have chosen rather than scraping aligned columns. who is primarily a display command. Keep any parser tied to the exact command and version installed on the target system.
Use last to read wtmp. Limit the result while you are exploring:
$ last -n 5 -F
alice pts/4 tmux(1998).%185 Sun Sep 27 17:24:28 2026 - Sun Sep 27 17:24:28 2026 (00:00)
alice pts/1 198.51.100.49 Sun Sep 27 17:24:28 2026 - Sun Sep 27 17:25:07 2026 (00:00)
alice pts/3 tmux(1998).%184 Sun Sep 27 16:45:29 2026 still logged in
alice pts/2 tmux(1998).%172 Sun Sep 27 13:00:12 2026 still logged in
alice pts/0 203.0.113.98 Sun Sep 27 11:12:09 2026 still logged inYour output may include a line such as wtmp begins .... That is a boundary of the available history, not a failed command. A missing logout time does not prove that a session is active forever: crashes, network loss and record-writing behaviour can leave an open-looking entry.
Checkpoint: Compare an unusual last line with current sessions from who, then check the service or authentication logs that are authoritative for your system. The login record is useful evidence, not a tamper-proof audit trail.
utmpdump exposes the underlying records without changing them. This is useful when you need the record type, process ID, terminal identifier, host address or timestamp:
$ utmpdump /var/run/utmp | sed -n '1,6p'
Utmp dump of /var/run/utmp
[2] [00000] [~~ ] [reboot ] [~ ] [6.8.0-139-generic ] [0.0.0.0 ] [2026-09-11T14:58:41,014846+00:00]
[6] [01225] [tty1] [LOGIN ] [tty1 ] [ ] [0.0.0.0 ] [2026-09-11T14:59:13,059298+00:00]
[7] [2533405] [ts/0] [alice ] [pts/0 ] [203.0.113.98 ] [203.0.113.98 ] [2026-09-27T10:12:11,284335+00:00]The first value is the ut_type field. Values include boot, login-process, user-process and dead-process records. Do not edit this binary file with a text editor or a hex editor. Linux's format is machine-dependent, and the manual recommends processing it on the architecture that created it.
The man page's security warning is about write access. An untrusted user who can write utmp can fake system login records and may undermine programs that depend on them. Check the permission string as well as the numeric mode:
$ namei -l /var/run/utmp /var/log/wtmp
$ stat -c '%n %A %a %U %G' /var/run/utmp /var/log/wtmpOn a typical installation, the file owner and the utmp group may write the files while the other class can read but not write them. The exact owner, group and mode are distribution choices, so preserve the existing owner and group unless your distribution documentation says otherwise.
Warning: The following commands change system state and require elevated privileges. Run them only after confirming the two paths and the intended ownership policy:
$ sudo chmod o-w /var/run/utmp /var/log/wtmp
$ stat -c '%n %A %a %U %G' /var/run/utmp /var/log/wtmpThis removes write permission for others without changing owner, group or the read and group-write bits. If you made that change accidentally, undo it with sudo chmod o+w ... only when you have confirmed that your system deliberately expects world-writable files. The documented safety boundary is that ordinary users outside the owner and group must not be able to write utmp.
Do not delete /var/run/utmp. Linux expects it to exist, and removing it can make current-session reporting fail. Do not delete /var/log/wtmp to hide a suspicious entry or reclaim space: the man page says that its removal turns off record-keeping because the maintaining programs do not create it. Preserve a copy for investigation and use your system's documented log-retention process instead.
Also avoid clearing the ut_id field in a program that writes records. The Linux man page warns that doing so can create races, corrupt entries and introduce security holes. If an application is producing bad records, fix that application's integration and test it on a disposable host.
/var/run/utmp and /var/log/wtmp were located and inspected without editing their contents.who showed the current records and last showed a bounded history.utmpdump only for read-only field inspection when the column view was unclear.stat.