Linux file permissions: follow the request that was refused

A settings file can sit exactly where you left it and still refuse to open. Even more puzzling, its listing can say that other people may read it while your own request gets “Permission denied.” Linux has not misplaced the file. It is checking who is asking and which permissions apply to that request.

Two small experiments make the check visible. First, take away your own permission to read a practice file and restore it. Then leave the file readable but close the directory on the way to it. The complaint will look much the same, even though the repair belongs in a different place.

Use your ordinary account in the disposable Ubuntu virtual machine, the separate guest computer used for this course. Keep the exercise inside the directory below, under your home folder. Do not use an administrator account such as root: it can bypass checks that you need to encounter here.

mkdir -p ~/linux-basics/access
printf 'Synthetic export configuration
' > ~/linux-basics/access/settings.txt
id
ls -ld ~/linux-basics ~/linux-basics/access
ls -l ~/linux-basics/access/settings.txt

“Others can read it” does not mean you can

The id command shows the user and groups you are acting as. Keep that identity beside the file listing. A regular file might start with -rw-r--r--: the first dash identifies a regular file, and the next nine positions form three sets for the owner, the group and other accounts.

In that example, rw- lets the owner read and write but not execute the file. Each r-- set permits reading only. For an ordinary permission check, Linux selects the applicable set. It does not search the listing for whichever set would give you the nicest answer. If you own this file, the owner's permissions are the ones that apply.

That is why removing your own read permission can leave the file readable by other people without letting you read it. Try that one change:

chmod u-r ~/linux-basics/access/settings.txt
cat ~/linux-basics/access/settings.txt
ls -l ~/linux-basics/access/settings.txt

As the ordinary owner, your cat request should fail. The listing explains why: the owner's rw- has become -w-. Nothing in the file's contents changed. The permission to read those contents did.

Restore the owner's read bit, the setting that permits reading, and ask again:

chmod u+r ~/linux-basics/access/settings.txt
cat ~/linux-basics/access/settings.txt

This time, “Synthetic export configuration” should appear. Same account, same file, same reading command. Restoring one permission was enough for this request, with no need to open the file more widely.

A readable file behind a closed directory

Now leave the file's permissions alone. Remove your execute permission from the access directory, attempt the read, then restore the permission and try once more:

chmod u-x ~/linux-basics/access
cat ~/linux-basics/access/settings.txt
chmod u+x ~/linux-basics/access
cat ~/linux-basics/access/settings.txt

The first read should fail and the second should succeed. On a directory, execute permission lets Linux pass through to a named entry. Read permission does a different job: it allows listing the names inside. Knowing that the file is called settings.txt does not itself grant permission to reach it.

If you had looked only at the file during that first failure, its read permission would have looked perfectly reasonable. Adding more permission to the file would not reopen the directory. Linux has to get through every directory in the path before the file's own read permission can help.

ls -ld shows a directory itself rather than its contents, which makes it useful for inspecting each parent along that path. On Ubuntu, namei -l, when available, brings the path components and their permissions together. Either way, you are following the route the request actually has to take.

Your successful read may not be the service's read

A service can run under a different account from yours. When your cat succeeds, you have established that your account can reach and read the file. The service still has to make its own trip through the path with its own applicable permissions. Identify the account it uses and the operation it needs before changing access.

Some systems add more checks. An access control list, or ACL, can assign additional permissions to particular accounts or groups. AppArmor and other security policies can restrict an operation as well. These experiments isolate ordinary file and directory permissions; they do not cover those additional policy systems.

sudo runs a command under another identity, commonly an administrator's. It can help with authorized inspection, but a successful administrator read does not explain why the service was denied. Changing who asks can change the answer without fixing the original request.

Leave the practice file readable by its owner and its directory traversable. You have now seen the same complaint arise in two different places: at the file and on the way to it. The next time a service cannot read its settings, the listing is more than a row of letters. Read it alongside the service's identity, then follow the path until you find the check that refused the request.

Sources

GNU Coreutils permissions describes changes to permission modes. The Linux path-resolution manual explains the directory traversal and access checks behind the second experiment.