Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make default chmod permissions configureable for files and directories #10789

Open
xrow opened this issue Oct 25, 2016 · 10 comments
Open

make default chmod permissions configureable for files and directories #10789

xrow opened this issue Oct 25, 2016 · 10 comments
Labels
Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc.

Comments

@xrow
Copy link

xrow commented Oct 25, 2016

Hi,

we had been working with piwik for some time now and we always had issues with permissions. We solved it by having the cron and webtraffic on different servers.

I was looking lately at this line. It seems that 750 seem too restricted by default since cron and webserver user need to write into the tmp dir.

https://github.com/piwik/piwik/blob/3.x-dev/core/Filesystem.php#L450

My proposal is to change to 0770. So that group apache/webserver can write too. That group is also the group of the cron user. I would hope/assume that would be also be a valid setup.

Other then that I am not sure how i can solve the issues that webserver and cron are different users.

@xrow
Copy link
Author

xrow commented Oct 27, 2016

This change fixes our problems.

sed -i 's/075/077/' core/Filesystem.php
sed -i 's/075/077/' vendor/piwik/cache/src/Backend/File.php

The the feature request would be to make default permissions configureable:

600 as default for files can be changed to 660.
700 as default for directories can be changed to 770.

@tsteur tsteur added this to the 3.0.0-b3 milestone Oct 31, 2016
@tsteur
Copy link
Member

tsteur commented Oct 31, 2016

I think it may be good to have a config setting for this. Background: For some users it is a problem to set permissions by default to 755 or 775. For other users it needs to be 777. So maybe we can quickly introduce a new config for this. Like file_allow_world_writable_permissions

@tsteur
Copy link
Member

tsteur commented Oct 31, 2016

@xrow I'm not sure whether you are familiar with patching files. I have issued a PR for this here: https://github.com/piwik/piwik/pull/10812/files could you try to apply the changes to your server and then set the config entry allow_world_writable_file_permissions to 1?

I cannot promise that this PR would be merged as it is not really good to have 777 file permissions but it may be merged

@xrow
Copy link
Author

xrow commented Oct 31, 2016

Hi @tsteur,

I checked the PR. That PR goes into the right direction, but is not ok since 777 should be avoided. #10812 maybe would solve our issue, but is not ideal.

I would try test a final PR, but #10812 is not ready.

@tsteur
Copy link
Member

tsteur commented Oct 31, 2016

You are totally right. I think the problem is actually that we do not try 0775 here: https://github.com/piwik/piwik/blob/2.17.0/core/Filesystem.php#L494 similar to https://github.com/piwik/piwik/blob/2.17.0/core/Filesystem.php#L93 . This might be actually a "bug"

@tsteur tsteur removed this from the 3.0.0-b3 milestone Nov 1, 2016
@xrow
Copy link
Author

xrow commented Nov 1, 2016

In other system I know they try to solve it by making the mask configurable for directories and files. For my scenario I would need 770 and 660 as mentioned. Is it a good idea to implement this as a feature?

@xrow xrow closed this as completed Nov 1, 2016
@xrow xrow reopened this Nov 1, 2016
@mattab
Copy link
Member

mattab commented Nov 3, 2016

In other system I know they try to solve it by making the mask configurable for directories and files.

it may be a good idea to solve it with configurable mask.
Do you maybe have example of how other system do this, and document it?

@xrow
Copy link
Author

xrow commented Nov 3, 2016

Hi,

this is quite straight forward and simple. Have a look.

https://github.com/ezsystems/ezpublish-legacy/blob/master/settings/site.ini#L970

Again... You need one mask for directories and one mask for files.

@mattab mattab changed the title Cron permissions make default chmod permissions configureable for files and directories Nov 11, 2016
@mattab mattab added the Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. label Nov 11, 2016
@mattab mattab added this to the Mid term milestone Nov 11, 2016
@lafrech
Copy link

lafrech commented Mar 2, 2017

I just experienced files/directories ownership issues and if think my use case might be related to this discussion.

Rather than using FTP, I manage web files using ssh, therefore with my own user id. Since I need files to be readable/writable by both my user and www-data, I created a dedicated group. All files/directories belong to that group, thanks to the SUID bit on the parent directory.

When piwik writes files/directories, however (session files, software updates), it does not give group write privilege, so my user can't modify / delete them.

In other words, once the parent dir is configured with the SUID bit, my user can install and run piwik without root privileges, but at some point, it can get locked out and need root privileges to delete piwik.

Maybe I shouldn't be doing this in the first place. I didn't find any alternative. Please excuse me if this is irrelevant.

@NathanQ
Copy link

NathanQ commented Aug 23, 2019

@lafrech This is a relevant question and has become an issue when updating. Fetching new files creates them as one user, but the webserver is another. Is it assumed the webserver and the either zip downloader or git user will be the same and it's ok the webserver can access everything?

@tsteur tsteur removed their assignment Jan 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc.
Projects
None yet
5 participants