The only folder front facing should be everything in /public

Not sure why you would of changed permissions of folders/files apart from app/storage which needs write permissions for cache/session (if you have that).

Great, so let me rephrase what you said. All the folders/files should be read-only expect for public folder and app/storage. Public and app/storage will have chmod 777, everything else in the framework is chmod 644, is that correct?

Thanks!

Most folders should be normal "755" and files, "644".

Laravel requires some folders to be writable for the web server user. You can use these commands on any *nix-based OS.

Using ACL

// nginx = web server user
// systemuser = your local user which you use to login via ssh
sudo setfacl -Rdm u:nginx:rwx,u:systemuser:rwx storage
sudo setfacl -Rm u:nginx:rwx,u:systemuser:rwx storage

If you don't have ACL, you can use these but they're not so great;

sudo chgrp -R www-data storage bootstrap/cache
sudo chmod -R ug+rwx storage bootstrap/cache

Bashy, thank you very much for your help! This is exactly what I was looking for.

No problem, also if you have any upload folders or folders that the webserver user needs to write to, 777 them or 755 with owner as webserver user :)

find {laravel-folder}/ -type d -exec chmod 755 {} ;

find {laravel-folder}/ -type d -exec chmod ug+s {} ;

find {laravel-folder}/ -type f -exec chmod 644 {} ;

chown -R {username}:www-data {laravel-folder}

chmod -R 777 {laravel-folder}/storage

chmod -R 777 {laravel-folder}/bootstrap/cache/

and now you can forget about it

@imatsu No no no no. Why 777?

This is better

sudo chgrp -R www-data storage bootstrap/cache
sudo chmod -R ug+rwx storage bootstrap/cache

Shouldn't make everything read/writable for web server user...

777 permission is the only permission configuration that works for me

@djap96 Then you're allowing other users on the system to write to storage folders, including cache, session and anything else you put in storage.

Just to state the obvious for anyone viewing this discussion.... if you give any of your folders 777 permissions, you are allowing ANYONE to read, write and execute any file in that directory.... what this means is you have given ANYONE (any hacker or malicious person in the entire world) permission to upload ANY file, virus or any other file, and THEN execute that file...

IF YOU ARE SETTING YOUR FOLDER PERMISSIONS TO 777 YOU HAVE OPENED YOUR SERVER TO ANYONE THAT CAN FIND THAT DIRECTORY. Clear enough??? :)

What bashy says above is absolutely correct, although not totally complete.

The NORMAL way to set permissions is to have your files owned by the webserver:

    sudo chown -R www-data:www-data /path/to/your/root/directory

if you do that, the webserver owns all the files, and is also the group, and you will have some problems uploading files or working with files via FTP, because your FTP client will be logged in as you, not your webserver, so add your user to the webserver user group:

  sudo usermod -a -G www-data ubuntu

Of course, this assumes your webserver is running as www-data (the Homestead default), and your user is ubuntu (it's vagrant if you are using Homestead.

Then you set all your directories to 755 and your files to 644... SET file permissions

sudo find /path/to/your/root/directory -type f -exec chmod 644 {} \;    

SET directory permissions

sudo find /path/to/your/root/directory -type d -exec chmod 755 {} \;

I prefer to own all the directories and files (it makes working with everything much easier), so I do:

sudo chown -R www-data:www-data /path/to/your/root/directory

Then I give both myself and the webserver permissions:

sudo find /path/to/your/root/directory -type f -exec chmod 664 {} \;    
sudo find /path/to/your/root/directory -type d -exec chmod 775 {} \;

Whichever way you set it up, then you need to give read and write permissions to the webserver for storage, cache and any other directories the webserver needs to upload or write too (depending on your situation), so run the commands from bashy above :

sudo chgrp -R www-data storage bootstrap/cache
sudo chmod -R ug+rwx storage bootstrap/cache

Now, you're secure and your website works, AND you can work with the files fairly easily

@bgies - can you clarify something please?

When you said: IF YOU ARE SETTING YOUR FOLDER PERMISSIONS TO 777 YOU HAVE OPENED YOUR SERVER TO ANYONE THAT CAN FIND THAT DIRECTORY.

What do you mean by this "ANYONE THAT CAN FIND THAT DIRECTORY"? How can one find my directory if I have i.e. vps or dedicated server? Or this is just for shared hostings?

http://askubuntu.com/questions/20105/why-shouldnt-var-www-have-chmod-777

@nate.a.johnson - So I guess that's it. If you share hosting with someone else it's bad idea, but if you have your own server it doesn't matter, because if you have malicious user in your shell I guess it's bigger server security problem.

It's never safe to make things world writeable and world executable. I'd try to avoid that unless absolutely necessary. For example, even if you are on a private server, if you allow uploads to a folder that is 777, a hacker could upload a script, execute it and really do just about anything they wanted to do.

Just be safe when setting up your permissions.

Yes, upload directory is something you need to be very careful.

As a general rule of thumb, no matter what it has to do with, if anyone ever suggests you should chmod 777 anything or likewise allow "all" permissions in Windows just walk away from the advice entirely. The spread of advice like that on the internet is just one of the reasons why Wordpress has it's reputation in security. Part of being a developer (whether it's ultimately going to run on Windows Server, Linux, or FreeBSD) is knowing some quality server administration skills, you can't escape it. Also on a bit of an off-topic, some advice on picking a server OS: the right one to use is the one you actually know how to use.

Please run this in the sequence they are

sudo find {laravel-folder}/ -type f -exec chmod 644 {} ;

sudo find {laravel-folder}/ -type d -exec chmod 755 {} ;

sudo chmod -R 777 {laravel-folder}/storage

sudo chmod -R 777 {laravel-folder}/bootstrap/cache/

The most security-informed consensus above seems to suggest files have 644 and directories 755.

I am not sure why you want to be giving all users any permissions in your laravel codebase. For this reason, I'd suggest 640 and 750.

Further, I see no reason to limit access to your own user. So I give myself full RWX access (i.e. 740 and 750), meaning I can execute shell commands etc on the production server. This is handy for running (for example) $ npm run production to have Laravel Mix compile all your stuff. I do this in a CI script.

Finally, if you set the setgid on your directories, anything created inside them will automatically be given the www-data group, which means if your own user creates files in the site codebase (e.g. by running Laravel Mix as above) these files will automatically be readable by your server.

To summarise, I suggest files get 740, and directories get 2750, and the storage and bootstrap/cache directories get 2770 (the leading 2 is the setgid bit).

so ive spent the past day mucking around with laravel permissions and using the stringent permissions guide given as "best secure practice" by this thread, and having real issues editing and even creating new files in the dirs!!

super frustrating to say the least.

centos 7...webserver runs as apache:apache im currently user marke with apache as primary group and wheel as secondary group.

if i set files (as root or sudo of course) as 644 i cant write them as marke of course..only apache user can write them but i am not trying to log is as apache and in fact think it would be poor practice to give any real user access that that username.

Are you guys advocating that I should log in as apache? or even give another more insecure user/developer access to that account?? that seems like madness to me.

Or am I missing something fundamental here? I can't see how I am because 644 only give write access to owner.

I look forward to hearing where I'm off.

This is good to use 600 permission for .env files.

@bashy running that command will make the storage folder 774. Is that okay? Are intending for that to happen?

@kendanblvnp I've updated my reply as ACLs are implemented more in Linux. See if those work better. 774 is fine. The last number is the 'public' permissions so as long as it's not 7, it's not readable and writable by other users.

Best Answer on this worked for me (log file not having permission to write on a new install), but it's worth pointing out to the people who were struggling with this and choosing an unsafe 777 work around:

www-data is not always the user running your webserver (apache, etc)

In my server's case (bitnami on AWS --doing a clean install, not using their pre-installed laravel) 'daemon' was the user needed for the 'group' permission.

The key is that your webserver's user ('www-data' in the Best Answer example) is able to write to the necessary folders. Setting the group to your SSH/SFTP access user might let YOU write to the folders/files you need, but not allow the webserver to do so.

Cheers.

@SimonEsposito That's why ACL is best since it'll allow you to set who can read/write/execute and doesn't matter about owner/group.

Check this out, it got it working for me, https://www.linkedin.com/pulse/selinux-laravel-framework-rodrigo-alvares/ on centos7 Do not forget to run restorecon -Rv /var/www/html/ This did the trick for me on centos 7 on a laravel project that i set up and access via virtual box.

I'm running this on a Laravel Forge server, and periodically (perhaps after a deploy or smething) the file permissions on the Laravel.log file are changing, and I have to go to back in and run these commands. Does anyone know the cause of this?

IMO, It's not correct to set all the files on your website to be owned by the web-server (www-data for example). 'www-data' should only be the owner of any directory it requires write access to such as upload directory or cache directory.

If you give www-data ownership of all the files and someone discovers a security flaw in your php code then your webserver can now overwrite any files in the system that it owns. i.e. the security flaw can be escalated. Any process that can be controlled by an external agent should have the absolute minimum of ownership.

If all the web files are owned by you (except cache and uploads) this flaw won't allow the files to be overwritten. Now it may allow a file to be uploaded to an upload directory but because the directory is outside public it cannot be accessed.

sudo chown -R you:you /path/to/your/root/directory

sudo chown -R www-data /path/to/your/uploads

sudo chown -R www-data /path/to/your/cache

This also means you don't need to add yourself to the www-data group for ftp etc.

@MACGROOVER - This solution works for me, many thanks.

this work for me https://github.com/BookStackApp/BookStack/issues/436

chown -R username:www-data ./storage

chmod -R 775 ./storage

I changed permissions to 775 on storage and bootstrap/cache. It works for a few days but then when new files are created on storage/cache, they are set to 755 so permission issues are back again. Am i doing something wrong ?