chmod 070: Group Only Access and the First Match Rule

The rule this mode demonstrates is the one most people get wrong. When a process opens a file, the kernel checks whether the effective user id matches the owner. If it does, the owner bits decide the outcome and the group and other bits are never consulted. Permissions are not combined, and the first matching class is final.

So a 070 file is unreadable by its own owner, even when that owner is a member of the owning group. The group bits say read, write and execute; the owner never reaches them. Running ls shows a file that looks generously permissioned and cat returns permission denied, which is why this mode turns up in interview questions and rarely anywhere else.

What the owner does keep is the right to change the mode. chmod is authorised by ownership rather than by permission bits, so the owner can run chmod 640 and immediately read a file they were locked out of a moment earlier. The lockout is real while it lasts and completely reversible by the person it locks out.

Root ignores all of it. A privileged process reads and writes regardless of the mode, so 070 keeps out unprivileged accounts including the owner and does nothing at all against an administrator or anything running with the capability to override file permission checks.

There is no honest production use for this mode. It is a teaching case, and it is also what a mistyped 700 looks like on a bad day. If you find it in the wild, read it as evidence that something generated a mode programmatically from the wrong digit position, then decide what was actually intended before setting it.