How to find world-writable files and orphaned files on Linux

What to look for

A world-writable file can be changed by any local account. A world-writable directory without the sticky bit lets anyone delete or replace files in it. Files owned by a user ID that no longer exists are orphans, often left behind when an account is deleted, and a new account that reuses that UID would inherit them.

These are low-effort checks that consistently find real problems on long-lived servers.

The find commands

-perm -0002 matches files where the others write bit is set. Combining it with ! -perm -1000 on directories finds the dangerous ones without the sticky bit. -nouser and -nogroup find orphans. -xdev keeps the search on one filesystem, and excluding /proc and /sys avoids noise.

Run them as root so permission errors do not hide results, and send stderr to /dev/null.

Snippet

sudo find / -xdev -type f -perm -0002 2>/dev/null
sudo find / -xdev -type d -perm -0002 ! -perm -1000 2>/dev/null
sudo find / -xdev \( -nouser -o -nogroup \) -ls 2>/dev/null

Lab: plant and find

On a lab VM, create /opt/tool/run.sh with mode 666, a directory /srv/drop with mode 777, and a file owned by a deleted user (create a user, touch a file as them, then userdel without -r). Run the three find commands and confirm each item appears.

Fix them: chmod 755 run.sh after checking its owner, chmod 1777 or 770 on the drop directory depending on its purpose, and chown the orphan to an active owner or remove it.

Snippet

sudo mkdir -p /opt/tool /srv/drop
sudo install -m 666 /dev/null /opt/tool/run.sh
sudo chmod 777 /srv/drop
sudo useradd tempuser && sudo -u tempuser touch /tmp/leftover && sudo userdel tempuser
sudo find / -xdev \( -nouser -o -nogroup \) 2>/dev/null

Make it routine

Save the output as a baseline and rerun monthly or after big deployments. Many configuration scanners and CIS benchmark checks include these exact tests.

Investigate before fixing in production. A world-writable file might be a lock file an application genuinely needs, in which case moving it to a dedicated directory with correct ownership is better than breaking the app.

Diagram

Three findings and their fixes

Each find result has a typical cause.

World-writable file
Often a copy from a zip or a lazy fix. Set the smallest mode that works.
World-writable dir, no sticky
Anyone can delete others’ files. Add sticky or restrict to a group.
Orphaned owner
Left by a deleted account. Reassign or remove before the UID is reused.

Check yourself

1. Which find test matches world-writable files?

2. Why is an orphaned file a risk?

3. What protects a shared world-writable directory like /tmp?