VPS & Server audit fixes

File System: fixing all 7 checks

The file system audit walks every local disk for the modes that turn an ordinary local account into root: world-writable files, set-id binaries, blank passwords and loose shadow permissions.

Three checks skip without root and they are the expensive ones: the two whole-disk scans, World-Writable Files and Unowned Files, plus Empty Password Accounts, which has to read /etc/shadow. SUID/SGID Files is also marked as needing root but never skips, it falls back to a partial scan and says so in the result, and /tmp Permissions skips only in the rare case that stat /tmp returns nothing at all.

7
checks in this audit
3
rated high severity
4
need root or sudo
~10s
automated run time

Transcribed from the vps-security-filesystem audit script. For what the audit covers rather than how to fix it, see the File System checklist.

Every check

Find your finding

Listed in the order the audit runs them. Take the check name from the third field of the result line and open its page.

  • World-Writable Files

    Soon

    Scans for world-writable files outside tmp directories

    MediumNeeds root3 results

  • SUID/SGID Files

    Soon

    Checks for set-id binaries, especially in user-writable paths

    HighNeeds root2 results

  • /tmp Permissions

    Soon

    Checks that /tmp has the sticky bit set (1777)

    MediumNo root3 results

  • System Log Permissions

    Soon

    Checks that core system logs are not world-readable

    MediumNo root2 results

  • Empty Password Accounts

    Soon

    Accounts in /etc/shadow with no password set

    HighNeeds root3 results

  • Account File Permissions

    Soon

    Modes on the account databases: /etc/shadow, /etc/gshadow, /etc/passwd, /etc/group

    HighNo root3 results

  • Unowned Files

    Soon

    Files left behind by a deleted user or group

    LowNeeds root3 results
Shared script behaviour

How the File System audit reads your server

Every check in this audit runs after the same preamble, and several of its results only make sense once you know what that preamble could and could not see.

Three checks scan "every local filesystem": they read /proc/mounts for ext2/3/4, xfs, btrfs, jfs, f2fs, reiserfs mount points and run find <mounts> -xdev. This deliberately includes separate /home, /var, /srv partitions that a plain find / -xdev would skip. Network filesystems (NFS, CIFS), overlayfs and tmpfs are excluded.

Why checks skip

A SKIP is never a pass

A skipped check verified nothing at all. The most common cause is privilege: 4 of the 7 checks in this audit need root for a complete result. Before every run, each script works out which of four privilege modes it is in.

The four privilege modes an audit script can run in, and what each one means for checks that need root
ModeHow it is reachedWhat it means for your results
rootThe audit runs as UID 0.Every privileged branch runs directly. No check skips for lack of permission.
nopasssudo -n true succeeds, so the account has passwordless sudo.Privileged commands run through sudo -n.
passA sudo password was supplied in the CtrlOps audit settings and accepted.Privileged commands run through sudo -S.
noneNone of the above worked.CAN_ROOT=0. Every privileged branch returns SKIP with a "Need root" message rather than guessing.

If many checks skip with a “need root” message, run the audit as root, grant the audit account sudo (with or without NOPASSWD), or supply the sudo password in the CtrlOps audit settings.

Keep going

Related audits

FAQ

File System questions

No, 200 is the ceiling. The scan is piped through head -200, so any host at or past that limit reports the phrase rather than a number, and only the first three paths are shown as examples. The result is still actionable: fix what is listed, then re-run and see whether the count drops below the cap. On a Docker host a large share of these are usually image layer contents under /var/lib/docker, which the world-writable scan does not exclude even though the Unowned Files scan does.
It is, and this is a known false positive. The comparison is numeric, so a mode of 700 sorts above the expected 640 and trips the warning even though it grants nothing at all to group or other. Anything that is genuinely tighter, such as the 000 that RHEL ships, trips it the same way. The check also never looks at ownership, so the reverse case is possible too: 640 root:users passes while every local member of that group can read the hashes.
Not blindly. /tmp and /var/tmp are already excluded from the scan, so anything reported sits outside the directories where world-writable is legitimate, but the list still mixes real findings with container image layers under /var/lib/docker, where changing modes on the host corrupts the layer. Identify what owns each path with dpkg -S or rpm -qf before touching it, and fix the deployment that created the mode rather than the file, because a chmod -R 777 in a deploy script will simply put it back on the next release.
Audit your fleet

Run all 7 File System checks, in one click

CtrlOps runs this audit over your existing SSH connection - no agents, no scripts to manage. $7/user/month after a 1 month free trial - no credit card required.

✓ Start instantly·✓ No credit card·✓ No sneaky autorenewals