Permissions randomly reset all the time / unsure of "which user/group" to grant access to

Keywords: LAMP/MAMP/WAMP - AWS - Technical issue - Permissions

bndiagnostic ID: cfc5f36e-f59a-afdb-86f2-2e334df0adcb

bndiagnostic output:

? Apache: Found possible issues
? Connectivity: Found possible issues
? Resources: Found possible issues

bndiagnostic failure reason: The tool was nice but didn’t detect or address my main issue

I would think that it would compare the permissions and ownership of known sensitive directories with what they should be (or how they come stock) and identify potential problems there. It would also be helpful to see which users attempted to perform which actions that were disallowed by permissions going back at least a couple hours.

The /tmp directories that my application writes to are having their permissions reset and changed all the time automatically and I cannot figure out why. I wrote a script to 777 them all but it seems I have to re-run it each time I start a new SSH session. And also permissions bugs that I think I’ve squashed come up time and time again. Also I do not understand which processes are running as which users so that I know which users should get which perms to which dirs.

Are you talking about the /opt/bitnami/apache/htdocs/tmp directory? I understand that folder is filled by the application you deployed and it uses “daemon” as user/group because Apache uses that user to run. You shouldn’t be modifying the permissions of that folder because it is the app only who should be reading/writing there.

Are you talking about the /opt/bitnami/apache/htdocs/tmp directory?

Yes, sorry, I know I wrote /tmp but I did mean the htdocs tmp dir. That folder is constantly being written to by my application, however there are tons of permissions errors getting logged when it tries to do that.

The current permissions on that directory are as follows, can you advise if they are correct?

bitnami@staging-1:~/htdocs$ ls | grep tmp
drwxrwxr-x   4 daemon bitnami   4096 Jun 21 16:39 tmp

I guess the weird thing is that when I run top and look at the top processes running on the host, sometimes I see a php process being run by bitnami and sometimes I see a php-fpm process being run by daemon. So I’m not sure which user should have ownership of that directory, because it looks like it could be both.

The last additional detail I can add is that when I SSH into the host to run a command in our application’s CLI (they are PHP scripts) then I get tons of permissions errors whenever it writes to tmp. I believe I’m running those scripts as bitnami as that is my SSH user.

PHP processes use daemon to run. If there is any PHP process running using the bitnami user, it’s because you (either manually or automatically) launched that process (for example, you can configure a cron job and it’ll use the bitnami user). In that case, I suggest you configure the cron job to use the daemon user to run the code.

This is correct! However, as I mentioned above, you should configure your cronjobs to use daemon so all files are created by the daemon user there. You can also ensure all files belong to deamon by running these commands:

sudo chown -R daemon:bitnami /opt/bitnami/apache/htdocs/tmp
sudo chmod -R g+w /opt/bitnami/apache/htdocs/tmp

This must be correct, we do have numerous cronjobs running but I guess it didn’t occur to me they would run as my user vs. the default user for PHP. I will transition the crontab over to the daemon user, hopefully I don’t encounter any problems doing that.

Thank you for your assistance.

A quick update: it is apparently not possible to specify the user to run as when editing the crontab with crontab -e or sudo crontab -e. Additionally, it is not possible to edit the daemon user’s crontab, their “access is disabled” or something like that.

However, what is possible is to instead create /etc/cron.d/my_application.cron and use the same cron file syntax there, but adding the user to run as to the line after the time syntax but before the command syntax. So this is what I’m doing now, hopefully it works.

Correct! That way to set the user to use when running the command is explained here