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

[DX] Can we handle permissions in an easier way #11563

Closed
weaverryan opened this Issue Aug 4, 2014 · 19 comments

Comments

Projects
None yet
@weaverryan
Copy link
Member

weaverryan commented Aug 4, 2014

Hi guys!

After a conversation at symfony/symfony-docs#4070, we wondered: might it be possible to handle permissions (to the cache and logs dirs) in a way that's consistently and easily handled?

When you start with Symfony (unless you're using the built-in server), you will immediately hit permissions issues. They're annoying because they hit a new user very early, and the fix varies wildly based on your system: http://symfony.com/doc/current/book/installation.html#book-installation-permissions

Can we do better? I believe that permissions are set to 755 and not 777 due to security concerns, probably concerns on a shared server. Is that even accurate?

Thanks!

@merk

This comment has been minimized.

Copy link
Contributor

merk commented Aug 4, 2014

In our shared hosting infrastructure we dont allow php scripts with permissions of 777 to run at all, and we're not alone with that - it is definitely a security issue on shared environments.

I've always felt that the best solution is to run the webserver as the owner of the files - but this probably would generate just as much documentation as you've already got on the permissions box..

Maybe the server:run command might be better for the quickstart? Most of the other language framework's I've encountered use their own built in webservers in any quickstart guides.

@weaverryan

This comment has been minimized.

Copy link
Member Author

weaverryan commented Aug 5, 2014

@merk You're right of course about the 777. And regardless of whether we can make this better or not, I am a huge proponent of server:run. That being said, if we can improve things, awesome :).

Of course, what's interesting is that permissions only affect things in the dev environment (well, debug is true). So the obvious conclusion is: can we do something special/different when debug is true? Can we 777 there? Probably not. Can we give a very specific error message perhaps? Is there anything from other frameworks/languages we can adapt?

@merk

This comment has been minimized.

Copy link
Contributor

merk commented Aug 5, 2014

You'll still encounter permissions errors in prod if there are scripts that write to kernel.cache_dir.

If we advocated for server:run for quickstart development, the problem goes away: console commands and the web server run as the same user.

This, coupled with more extensive follow-up documentation about how to set up apache or nginx with php-fpm running as the current user removes most of the stress, doesnt it? You could just have a note about permissions for apache/nginx leading to a cookbook entry at the start of the quickstart.

A better error message would probably also be a good idea if its possible.

@merk

This comment has been minimized.

Copy link
Contributor

merk commented Aug 5, 2014

As for other languages, any project i've run in other languages runs its webserver as a specific user, never as the webserver user or nobody.

@jrobeson

This comment has been minimized.

Copy link
Contributor

jrobeson commented Aug 5, 2014

@weaverryan: as far as i can tell they all have the same issues , especially when executing via fastcgi.

Although in rails for example, you'd often run the rails app with an application server with a user named after the app.

@merk

This comment has been minimized.

Copy link
Contributor

merk commented Aug 5, 2014

A rails app with its permissions: http://stackoverflow.com/a/14890159 - notice that the last paragraph talks about the same user that owns the files.

The same thing in the official getting started guide: you run a rails webserver (ala server:run) as the same user. http://rubyonrails.org/download/

@weaverryan

This comment has been minimized.

Copy link
Member Author

weaverryan commented Aug 5, 2014

Ok then, I think we hit what @merk said:

  1. See if we might be able to give a clear permissions writing error message

  2. Heavily advocate the built-in web server method (heck, we could even advocate that in the error message above in the dev environment/debug=false)

  3. Make sure we have clear instructions on server setup. I think this is the least important - I don't see many permissions problems on production. @merk you're right that you could have permissions problems in prod, but the fix is (usually) so much easier: just make sure the directory is writable by the web server user. You don't have the problem of files needing to be overwritten like you do in the dev environment.

For this issue, only (1) is actionable in the core.

@merk

This comment has been minimized.

Copy link
Contributor

merk commented Aug 5, 2014

Yep, sounds good to me, though I dont agree with 3: you still need to be able to run console commands in production and that can still cause issues if there is a mismatch between newly generated cache files from the cli command that the webserver might need to handle later on.

@mvrhov

This comment has been minimized.

Copy link
Contributor

mvrhov commented Aug 6, 2014

I see a flaw in what's proposed. Internal server is only available as of PHP 5.4. And Symfony supports 5.3

@weaverryan

This comment has been minimized.

Copy link
Member Author

weaverryan commented Aug 6, 2014

Haha, of course - great point, I forget about this. We'll clearly need to continue to give clear documentation on both, but with emphasis on the built-in web server. We're already doing this, but we'll be going through or "get started" docs over the next few months, and we'll make sure this is all consistent.

@stof

This comment has been minimized.

Copy link
Member

stof commented Aug 6, 2014

@weaverryan the permissions of the cache files depend on the umask of the user running PHP. We create them as 777 with the umask applied. Given that the default umask is 022 in most distributions (maybe even all of them), the final permissions usually end up being 755.
This is why changing the umask is a way to solve the issue when you cannot use a cleaner solution

@weaverryan

This comment has been minimized.

Copy link
Member Author

weaverryan commented Aug 6, 2014

@stof Thanks for the clarification, I had actually always wondered how the umask worked but never looked :). Helping walk the user through the umask solution (and explaining why they might want or not want this) might also be a good way of handling this.

So overall, if we are able to have an exception message when there are cache problems that guides the user to clear steps to fix the problem (read some docs, run some script that guides you through, whatever), that would be pretty awesome.

@nicolas-grekas nicolas-grekas added the DX label Aug 8, 2014

@kevintweber

This comment has been minimized.

Copy link
Contributor

kevintweber commented Aug 10, 2014

Perhaps someone could write a composer post-install command script that would:

  1. Check to see if permissions are correctly set.
  2. If not, give the user a set of options (corresponding to the three in the documentation)
  3. Then run the corresponding command. (The user would then be required to type in their password for sudo access.)

Just an idea.

@inmarelibero

This comment has been minimized.

Copy link
Contributor

inmarelibero commented Aug 20, 2014

+1 for @kevintweber , maybe asking for the right user:group to set for app/log and app/cache directories?

@webda2l

This comment has been minimized.

@proclamo

This comment has been minimized.

Copy link

proclamo commented Aug 21, 2014

I always use app/sessions and somethimes app/spool (for mails). Maybe someone could write a console tool for create any folder with apropiate permissions. This tool could be called by the pos-install script that @kevintweber have talked.

@mvrhov

This comment has been minimized.

Copy link
Contributor

mvrhov commented Aug 21, 2014

The console tool for creating a file with correct permission is sudo -u www-data <command> Where the www-data is the user under which the webserver/php-fpm is running.

@cordoval

This comment has been minimized.

Copy link
Contributor

cordoval commented Aug 23, 2014

@proclamo it could be a good idea to expand in the PermissionsHandler from @umpirski it looks good!

@fabpot

This comment has been minimized.

Copy link
Member

fabpot commented Feb 12, 2015

This is definitely something that is addressed in the documentation as I still don't see what we can do in the core to simplify this. So, I'm closing it now as I don't anything actionnable.

@fabpot fabpot closed this Feb 12, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.