Assign service ownership

Filesystem permissions should express which process owns and reads each dataset. When you look at /srv/data in a year, the owner and mode of each directory should tell you exactly which service the data belongs to.

World-writable directories hide ownership mistakes. Everything works, right up until you can’t tell what wrote a file, or a misbehaving service scribbles over another service’s data.

Create a dedicated account

Each service gets its own system account, with no login shell and no password:

sudo adduser --system --group appsvc

--system creates a low-UID account meant for services, and --group gives it a matching private group. Nobody logs in as appsvc; it exists only so files and processes can carry its identity.

Create a dedicated service directory

sudo install -d -o appsvc -g appsvc -m 0750 /srv/data/app

install -d creates the directory with owner, group, and mode in one step. The mode 0750 means: the service account has full access, members of its group can read, and everyone else gets nothing.

Test allowed and denied paths

Run the service as its account and test create, read, and delete operations:

sudo -u appsvc touch /srv/data/app/probe.txt
sudo -u appsvc rm /srv/data/app/probe.txt

Both should succeed silently. Then prove the boundary holds. An unrelated account should be denied:

sudo -u nobody touch /srv/data/app/denied.txt
# touch: cannot touch '/srv/data/app/denied.txt': Permission denied

That error is the test passing. If the write succeeds, the directory is more open than you think; check its mode and parents with ls -ld /srv /srv/data /srv/data/app.

The chmod 777 trap

At some point a service or container will fail with a permission error, and the Internet will tell you to run chmod -R 777 on the data directory. Do not solve container or service errors with recursive chmod 777. It makes the error disappear by erasing the ownership model entirely, and every process on the machine can now modify that data.

Resolve the actual UID, GID, and required access instead. Find out what identity the process runs as, for a container with docker exec app id, then either run the service as the owning account or chown the directory to match. The fix is one precise line, not a blanket permission.