A ticket comes in: "The service cannot read its file." That has to be tested as the service itself.
A root process passes most file access checks. A successful sudo cat therefore proves one thing: the file exists and root can read it. It tells you nothing about the service: you need the service's account, the same path, and the same operation.
sudo has a form for this, sudo -u USER COMMAND: the command runs as the named account, if the policy allows it. For example, the nginx web server on Ubuntu runs as the www-data account:
The first command prints the UID and groups of a www-data process; the second shows whether the service can read the file. You need no www-data password: sudo checks the policy for whoever calls it.
| Command | Runs as | What success proves |
|---|---|---|
cat summary.txt |
student | you can read the file |
sudo cat summary.txt |
root | the file exists and root can read it |
sudo -u www-data cat summary.txt |
www-data | the service can read the file |
Before a fix, write down what you see: the id output of the user in question, the path, the owner, the group, and the error message. After the fix, repeat the same operation as the same user.
The exercise changes the conditions: the directory belongs to a service, and the file in it must be prepared so that the service owns it.
Prepare a file for a service
The /srv/queue directory belongs to www-data, the account the web server runs as. Create an empty jobs.txt in it, owned by user and group www-data.
Goals · 0 of 2
- Create jobs.txt in /srv/queue not done yet
- Make www-data the file's owner and group not done yet