writable task: changes needed/wanted?

[acharseth]

Is there any reason why the (caching) folders set writeable by the writable task is not set read-only after caching is performed?
Isn't it a security risk to have writeable php-files? What folders can be set read only and which need to retain writeable?

Why is setfacl used to set access rights, could't chmod be used? Option to force use of chmod?

[antonmedv]

1. Why are caching folders not set to read-only after caching is performed?

   • Typically, application cache directories need to be writable because the application might update, invalidate, or regenerate cache files during its normal operation. If these directories were set to read-only after caching, it would prevent such operations, potentially breaking application functionality or performance.

2. Is it a security risk to have writable PHP files?

   • Yes, having writable PHP files can be a security risk. If an attacker gains access to your server or finds an exploit in your application, they could modify or add malicious code to these writable files. For this reason, PHP files (or any executable files) should generally not be writable by the web server user unless absolutely necessary. Instead, only specific directories (like storage or cache) that require write access by the application should be writable, and they should not typically contain executable code.

3. Which folders can be set to read-only and which need to retain writable?

   • This largely depends on the specific application being deployed. As a general rule:
     • Directories containing core application code should be read-only.
     • Directories used for logs, caches, uploads, or temporary files usually need to be writable. For instance, in many PHP frameworks, directories like storage or var might need to be writable.
     • Ensure you refer to your application's documentation to determine which folders specifically need write permissions.

4. Why is setfacl used to set access rights instead of chmod?

   • setfacl (set file access control list) allows for more granular permission controls compared to chmod. With setfacl, you can specify permissions for multiple users or groups on a single file or directory. This is especially useful in shared hosting environments or when more than one user or service needs specific permissions on a file or directory.
   • Using ACLs can be a way to grant permissions without changing the file's owner or group, providing more flexibility.

5. Option to force the use of chmod?

   • While Deployer might favor setfacl for its flexibility and granularity, you can always write custom tasks or modify existing tasks to use chmod if that suits your environment or security policies better. However, remember that with chmod, you might lose some granularity in permissions management.

When deploying PHP applications, it's crucial to find a balance between functionality and security.

[antonmedv]

Certainly! Let's address your questions in context with the Laravel framework:

1. Caching folder in Laravel:

   • Laravel uses various directories within the bootstrap/cache and storage directories for caching configuration, views, and other data. While you can use artisan commands like config:cache, route:cache, and view:cache to generate cache files, these directories aren't static. For example:
     • The storage/framework/views directory stores compiled Blade templates, and these can be regenerated on-the-fly as templates are modified.
     • The storage/framework/sessions directory is used for file-based session handling and would have regular write operations.
     • The storage/logs directory is where logs are written.
   • Given the dynamic nature of these directories, setting them to read-only after caching would disrupt the normal operation of a Laravel application. Even if you cache configurations or routes, other aspects of the application may still need write access to these directories.

2. chmod option in Deployer:

   • Yes, you're correct! If you want to use chmod in Deployer to manage writable directories instead of the default behavior (which might use setfacl or other methods), you can set the writable_mode option to 'chmod'. By doing so, Deployer will use chmod to manage file and directory permissions. This can be set using the following command within your deploy script:

     set('writable_mode', 'chmod');

To summarize, for Laravel, while you can use artisan commands to manage cache files, there are many directories that need to remain writable for the application to function correctly. And yes, in Deployer, you can set the writable_mode to 'chmod' to use chmod for permissions management.

[acharseth]

Thanks for your great summary, @antonmedv !

Is it possible to use several writable_modes at the same time, like chown, chgrp, and chmod? If so, how?

Do you use an array, something like:

set('http_user', 'some_user');
set('http_group', 'some_group');
set('writable_chmod_mode', '7750');
set('writable_mode', ['chown', 'chgrp','chmod']);

I assume these will operate recursively both on the writeable directories and files within?

Do you set this globally or pr host, or both is possible?

[acharseth]

I tried using an array like this but it is not supported. Would it not be natural to support this? You would normally want to set several of these, not just one?

[antonmedv]

True. Will be cool to have it as a feature.

[acharseth]

I guess this should be made as a feature request so I close this discussion. Thanks for all your input @antonmedv it is greatly appreciated!