1

I have encountered a very strange behaviour I do not know how to solve: the action permissions depend on where the command is executed.

My situation: I set up a Nextcloud server on a Raspberry Pi 4. The system works off of an SD card and the Nextcloud instance is on an SSD, run via Docker (using IOTstack). As far as Nextcloud is concerned, everything works as expected.

When I want to list the contents of the Nextcloud instance, I may use the root account as such:

sudo ls -lh /media/pi/storage/IOTstack/volumes/nextcloud/html/data/solenoid/files
total 4.0K
drwxr-xr-x  3 www-data www-data 4K Nov  3 11:09  Documents

Of course, this works because of root. When I try the normal account pi then I get the following:

ls -lh /media/pi/storage/IOTstack/volumes/nextcloud/html/data/solenoid/files
ls: cannot access '/media/pi/storage/IOTstack/volumes/nextcloud/html/data/solenoid/files': Permission denied

That's because everything belongs to www-data, so I try as www-data and I get:

sudo -u www-data ls -lh /media/pi/storage/IOTstack/volumes/nextcloud/html/data/solenoid/files
ls: cannot access '/media/pi/storage/IOTstack/volumes/nextcloud/html/data/solenoid/files': Permission denied

This is not normal... I should be able to see the files of the user they belong to.

I tried to cd to the mounted SSD (storage) and execute the command again:

cd /media/pi/storage/
sudo -u www-data ls -lh ./IOTstack/volumes/nextcloud/html/data/solenoid/files
total 4.0K
drwxr-xr-x  3 www-data www-data 4K Nov  3 11:09  Documents

Why? How come the permissions depend on from where the ls command is executed? Why can I list the files from /media/pi/storage and not from /home/pi, as the www-data user? Should www-data be in the pi group?

Previously I had the data stored on the SD card, under /home/pi/IOTstack..., but I wanted to store my files in a more safe location, while keeping the option of swapping the hardware. I did not encounter this issue.

The reason for accessing files in this "raw" way is to back them up over the network to another storage media.

Edit

Answering @kamil-maciorowski

namei -nom /media/pi/storage/IOTstack/volumes/nextcloud/html/data/solenoid/files
f: /media/pi/storage/IOTstack/volumes/nextcloud/html/data/solenoid/files
 drwxr-xr-x root     root /
 drwxr-xr-x root     root media
 drwxr-x--- pi       pi   pi
 drwxr-xr-x pi       pi   storage
 drwxr-xr-x pi       pi   IOTstack
 drwxr-xr-x pi       pi   volumes
 drwxr-xr-x pi       pi   nextcloud
 drwxrwx--- www-data root html
                          data - Permission denied
Solenoid
  • 133

1 Answers1

0

Useful links:

When you do

ls -lh /media/pi/storage/IOTstack/volumes/nextcloud/html/data/solenoid/files

as pi, the pathname is resolved, /, media, pi, storage, IOTstack, volumes, and nextcloud can be accessed. Then the procedure comes to the html component. The ownership and mode of html are www-data:root and drwxrwx--- respectively. When you are pi (which is neither www-data nor in the root group), the last triplet applies, it's ---. This means you cannot access html, data and further pathname components.

When you do

ls -lh /media/pi/storage/IOTstack/volumes/nextcloud/html/data/solenoid/files

as www-data, the pathname is resolved, / and media can be accessed. Then the procedure comes to the pi component. The ownership and mode of pi are pi:pi and rwxr-x--- respectively. When you are www-data (which is neither pi nor in the pi group), the last triplet applies, it's ---. This means you cannot access pi, storage and further pathname components.

You said "this is not normal", but the mechanism of access denial is the same as in the first try; the only difference is the pathname component being the culprit: html or pi. Both cases are equally normal.

When you cd /media/pi/storage/ as pi, you can do this because the modes for all the relevant directories allow you to.

When you then run

ls -lh ./IOTstack/volumes/nextcloud/html/data/solenoid/files

as www-data, the mode of /media/pi is irrelevant because pathname resolution starts from .: ., IOTstack, volumes and so on. It so happens www-data can access all these files and thus ls works.

In other words cd performed as pi puts you under the very component www-data cannot access. Then pi becomes www-data thanks to sudo, but the working directory does not change. The path given to ls starts from ., not from /, it can now be resolved and accessed. Note if you used the full path (i.e. starting from /, like in the previous tries), then it still couldn't be accessed, regardless of the current working directory.

Kamil Maciorowski
  • 81,893