1

How do I configure Laravel such that newly created files and directories below ./storage become group writable?

The Laravel ./storage directory contains files which are dynamically generated during runtime of the application. For example, ./storage/framework/views contains compiled and cached versions of the Laravel Blade templates. The webserver runs as user and group apache:apache. Upon every upgrade of the application, I need to run the console command ./artisan optimize:clear to remove outdated, cached files. The admin user is also a member of the group apache, e.g. lets assume the account is my_user:apache.

Unfortunately, Laravel creates new files with permission 0640 and directories with permission 0750, i.e. they are only group-readable, but not group-writable. This means running ./artisan optimize:clear as my_user fails because group membership is not sufficient.

user2690527
  • 1,729
  • 1
  • 22
  • 38
  • maybe this thread fix your issue: https://stackoverflow.com/a/37266353/11545457 and https://laracasts.com/discuss/channels/general-discussion/laravel-framework-file-permission-security?reply=3193 – Sumit kumar Oct 28 '22 at 15:44
  • Can you implement some kind of ACL (Access Control List) logic on your `storage` directory? These will cause files/folders in the specific folder to be created with a default set of permissions. Implementation differs between systems (windows, linux, mac, etc.), but I've had success with this in the past. – Tim Lewis Oct 28 '22 at 15:45
  • @Sumitkumar No these do not fix the problem. I highlighted the term _newly created_ on purpose, because that is the important part. Of course I know that I can do a `chmod` after the fact and make the file group writable later, but that is not what I asked for. – user2690527 Oct 28 '22 at 16:09
  • @TimLewis If it was my own installation, I surely could use Posix ACLs. But I am actually one of the developers and people who use our application frequently run into that problem. This means our users follow best practices, have a setup as described above and then something fails. Of course, they blame us (as the developers) first, even if it is a problem of the framework. Using the Posix ACL approach would be too much to ask. We must also consider users which are on a shared hoster and cannot use ACLs. Hence, the Laravel framework should properly set the permissions right upfront. – user2690527 Oct 28 '22 at 16:14
  • is running the command as the apache user an option e.g. using `sudo -u apache php artisan optimize:clear` ? – apokryfos Oct 28 '22 at 16:15
  • @user2690527 Yup; totally fair points all around! I haven't worked with this kind of distributed system; mine have always been self-hosted on servers I could modify as required. Your users should be able to implement their own solution, like using the same user/group for the Web and CLI instances, or an ACL set-up, etc.; I personally don't know of a way to handle this aside from something hacky like a script/command to modify the permissions when these files are generated, or something similar. I'll keep an eye on this post, see if someone else finds a good solution. Best of luck! – Tim Lewis Oct 28 '22 at 16:38
  • @apokryfos Same answer as for TimLewis. **I** can do that, but many user will simply forget about it. Anything which requires manual caution will eventually fail. – user2690527 Oct 28 '22 at 16:39
  • Not sure I understand the concern. Do you mean other members of your team might not do this correctly? If so can you write some automation for deployment? – apokryfos Oct 28 '22 at 22:06

0 Answers0