How do I debug filesystem permissions?

Question

I get permissions errors when I have a process running as root, spawning a subprocess as www-data, which then accesses a dir which is owned by root, with a subfolder which is owned by www-data, which has a symlink to a dir which is owned by a user in the group www-data, which then has.... YOU GET THE IDEA. How the heck do I know where it fails in this impossibly complex chain? All I get is Permission Denied

Without getting bogged down in the details of this particular situation, how does one begin to debug a problem like this on unix?

I want to just say

debug_permissions.sh www-data /my/long/symlink/chain```

and I want it to go through and tell me where the terminal point is (where www-data fails to have permissions)

I know there is a tool
``` namei -l /path/```
but that isn't very helpful because it doesn't let me run as another user (or at least I don't know how)

If I run 
```sudo su www-data```
I get **This account is currently not available.**

I want to be able to  "become" www-data and "cd" around to the dirs and see where i fail to see things. But, that's not letting me do this and I don't want to create a new user just to do this.

Answer 1

Aha, this does it:

sudo -H -u www-data namei /my/long/symlink/chain

where www-data is the user I'm trying to debug

Answer 2

Generally, I have a couple of tactics to debug file system permission issues.

Assuming that an example user named userWhoShouldHaveAccess is supposed to be able to list the contents of the directory /dir/with/access/issues, I'll have this running in a terminal to learn whether whatever I tried worked:

watch sudo -u userWhoShouldHaveAccess ls /dir/with/access/issues

The following lets me keep an eye on the permissions from the root directory to the directory I want the user to access:

cd / && watch namei -l /dir/with/access/issues

I'll keep in mind that in order to list files in a directory, the user must traverse the whole path /dir/with/access/issues, meaning the user must have executable permissions in the target directory and all the parent directories.

I'll keep in mind that group changes to a user are only effective after logging out and logging in again, although there are workarounds for that.

I can show the user ID and the groups the user belongs to with id userWhoShouldHaveAccess.

Since there are also access control lists in addition to the owner/group/other permissions that determine access, I'll check those with

getfacl /dir/with/access/issues

If the user should be able to write, I can run this in the background to learn when writing works:

while true; do sudo -u userWhoShouldHaveAccess bash -c '(echo "Test at $(date) by $(whoami)" >> /dir/with/access/issues/test_file);sleep 1';done

Here are some basics of file permissions on Linux.