7

I get permission 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 the symlink chain 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.

Matthias Braun
  • 8,239
Jonathan
  • 1,565

2 Answers2

9

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

Jonathan
  • 1,565
1

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.

Matthias Braun
  • 8,239