Permissions issue after deployment about capistrano-magento2 HOT 11 CLOSED

@craigcarnell Have you considered adding the deployment user to the www-data group so the deployed files can be grouped under www-data allowing read / write access to the nginx/php processes? We do our deployments via a non-privileged PKA authenticated SSH session to the www-data user (which nginx and php-fpm run as), so I hadn't run into this myself yet. All other administration is done via other SSH accounts though :)

I think making these configurable would be a great idea! What do you think would make the most sense… having a configurable umask or separate permission settings for directories and files?

from capistrano-magento2.

We do deployments with a user which is in group www-data, but at the end of deployment we change all deployed files to www-data:www-data

from capistrano-magento2.

@davidalger that would make sense. I've considered doing this earlier.

I can see the benefit of running the permissions code however I do this locally so it's not a big issue. Perhaps add a config option to not run the permissions changes? That way it can be run by default and I can switch it off.

Making the umask configurable would also be a bonus.

I might think about changing our deployments to run as www-data, if that makes it easier going forward for m2 deployments.

Are there any security concerns? At the moment we deploy using a different user. nginx/php seems to have no issues accessing the files. We have the var and media folder running as www-data so it can write to them

@roman204 I will also look into this 👍

from capistrano-magento2.

@roman204: I don't think this is a good idea from a security point of view. This means that the www-data user probably has write permission on .php files? So if an exploit in the Magento 2 code is used and it is somehow possible to manipulate the filesystem from that exploit, then they will be able to modify .php files, which is a really bad thing.
Best is to use separate users, where the www-data user only has read access to .php files.

In case anybody is interested, we do this in our Fabric deployment scripts (python code):

def fix_file_permissions():
    with cd(env.release_dir):
        run('find . -type d ! -path "./pub/*" ! -path "./var/*" -print0 | xargs -0 chmod 750')
        run('find . -type f ! -path "./pub/*" ! -path "./var/*" -print0 | xargs -0 chmod 640')
        run('find ./pub ./var -type d -print0 | xargs -0 chmod 2755')
        run('find ./pub ./var -type f -print0 | xargs -0 chmod 644')
        run('chmod u+x bin/magento')
        run('chmod u+x tools/composer.phar')
        run('chmod u+x node_modules/.bin/*')
        run('chmod u+x vendor/bin/*')
    with cd(env.shared_dir):
        run('find . -type d ! -path "./pub/*" ! -path "./var/*" -print0 | xargs -0 chmod 750')
        run('find . -type f ! -path "./pub/*" ! -path "./var/*" -print0 | xargs -0 chmod 640')
        run('find ./pub ./var -type d -print0 | xargs -0 chmod 2755')
        run('find ./pub ./var -type f -print0 | xargs -0 chmod 644')

Where the owner is different from the group.

Which I think is pretty secure, but probably not super secure (watch out: I'm certainly no expert in this area)

from capistrano-magento2.

@davidalger Hi David, when could you make the permission setting an option? Thank you

from capistrano-magento2.

@craigcarnell I was able to implement this and push it up as v0.5.2 this morning. See the commit a645b6d for details, but I've added three settings. One for directory permissions, one for file permissions and one to specify executable files to add the executable bit to.

The following config (adjusted as needed) would allow you to set these on a per project basis:

set :magento_deploy_chmod_d, '2770'
set :magento_deploy_chmod_f, '0660'

from capistrano-magento2.

@hostep I'm curious, do you guys use Fabric to run Capistrano or use Fabric for the entire deploy process?

I'd love to see a better set of default permissions which would be applied on a deploy incorporating things such as read-only access on all php files and having only write access on directories which require it. I'm hesitant to do this though without putting a lot of research effort into finding out what would both work across the majority of environments, maintain better security, and not impose undue restrictions on others. Or maybe leaving these as is by default is best now that flexibility has been added to them? I'm open to ideas. :)

from capistrano-magento2.

@davidalger: no, only Fabric for M2. We used to use Capistrano in our M1 projects, but it was time for something else because we are stuck on version 2 of Capistrano on our workstations since we still have to support M1 projects and we can't install v2 and v3 of Capistrano simultaneously (but that's my own fault, it's the way I set it up 5 years ago without trying to be future-proofed).

Anyway, regarding file permissions.
The solution I presented above is also very bad security wise after thinking about it for a while.
Yesterday, I tried to come up with a workable solution with better security in mind. And I might have found one, but it is very theoretical and hasn't been tested in practice yet.

If you don't mind, I'll try to explain it, in the hope other people might find it useful or give me some hints about things that are plain wrong in my thinking or maybe suggest some improvements.

So here we go.

Users

I see the need for not 2, but 3 different users:

• the webserver
• php itself (through php-fpm)
• the deployer

I want to use the principle of least privilege where each of these users can only perform what is minimal needed and nothing else.

• So in the case of the webserver in a M2 environment, it should only have read access to static assets and just hand over php execution to php-fpm which runs as another user.
• php(-fpm) should only be able to read php scripts, but still have write permissions on specific directories because it needs to be able to write files the users upload through the backend of M2 and it needs write permissions in certain var/ directories.
• The deployer has full control over everything.

Permissions

Since we have 3 users and we have 3 levels in the default file permissions system in a unix environment, this is perfect. (There is another way using ACL's in linux which is even more flexible, but I have no experience with that).

So I have this mapping in mind:

Type of files

• All files except for specific files mentioned below:

• Files in the pub directory, or even more strict, only in the pub/media directory:

• Files in the var directory, or even more strict, only in the var/cache, var/page_cache, var/log, var/report, var/session, ...

Type of directories

(if a directory has no read access but is executable, then the user is still able to access the files within the directory, but just can't list the contents of the directory)

• All directories except for specific directories mentioned below:

• Directories in the pub directory, or even more strict, only in the pub/media directory:

=> In this case, I would also enable the setuid and setgid bit, so if php creates a new directory, it inherits the owner and group, in this case the octal representation would be 6771

• Directories in the var directory, or even more strict, only in the var/cache, var/page_cache directories:

Warning

Like I mentioned, this is highly theoretical and hasn't been tested properly in practice.
I'm far from a security expert, but I do have a keen interest in it.
I want to test this further, but I'm leaving on big hiking trip next week and won't have time to properly test all this in the very near future.

I hope this is somewhat useful to someone :)

from capistrano-magento2.

@davidalger Thanks very much for this. I was also hoping to add an option so that you could skip running the permissions code at all? If that is possible.

What permissions would php/nginx have to those files if those masks are applied? I don't want php/nginx to have write permissions to the files/folders. It only needs read to PHP and write to var and pub/media.

This is why I deployed using a seperate deployment user. Then nginx/php runs as www-data in read only mode to those files.

from capistrano-magento2.

@craigcarnell I found a really simple way to do this…If you want to disable the task, just add this to your config:

Rake::Task['magento:setup:permissions'].clear_actions

See this for details: http://capistranorb.com/documentation/advanced-features/overriding-capistrano-tasks/ Similar can be used if you want to redefine it with your own code which will run when this task is invoked during the deploy procedure.

from capistrano-magento2.

@davidalger Seemed to work thanks 👍

Skipping task `magento:setup:permissions'.
Capistrano tasks may only be invoked once. Since task `magento:setup:permissions' was previously invoked, invoke("magento:setup:permissions") at /var/lib/jenkins/.gem/ruby/gems/capistrano-magento2-0.5.1/lib/capistrano/tasks/deploy.rake:30 will be skipped.
If you really meant to run this task again, first call Rake::Task["magento:setup:permissions"].reenable
THIS BEHAVIOR MAY CHANGE IN A FUTURE VERSION OF CAPISTRANO. Please join the conversation here if this affects you.
https://github.com/capistrano/capistrano/issues/1686

from capistrano-magento2.