php 如何为 Laravel 设置文件权限？

How to set up file permissions for Laravel?

提问by Robo Robok

I'm using Apache Web Server that has the owner set to _www:_www. I never know what is the best practice with file permissions, for example when I create new Laravel 5 project.

我正在使用所有者设置为_www:_www. 我从来不知道文件权限的最佳实践是什么，例如当我创建新的 Laravel 5 项目时。

Laravel 5 requires /storagefolder to be writable. I found plenty of different approaches to make it work and I usually end with making it 777chmod recursively. I know it's not the best idea though.

Laravel 5 要求/storage文件夹可写。我发现了很多不同的方法来使它工作，我通常以777递归方式使其chmod结束。我知道这不是最好的主意。

The official doc says:

官方文档说：

Laravel may require some permissions to be configured: folders within storageand vendorrequire write access by the web server.

Laravel 可能需要配置一些权限：文件夹内 storage和vendor需要 Web 服务器的写访问权限。

Does it mean that the web server needs access to the storageand vendorfolders themselves too or just their current contents?

这是否意味着 Web 服务器也需要访问storage和vendor文件夹本身或仅需要访问它们的当前内容？

I assume that what is much better, is changing the ownerinstead of permissions. I changed all Laravel's files permissions recursively to _www:_wwwand that made the site work correctly, as if I changed chmod to 777. The problem is that now my text editor asks me for password each time I want to save any file and the same happens if I try to change anything in Finder, like for example copy a file.

我认为更好的是更改所有者而不是权限。我以递归方式将 Laravel 的所有文件权限更改为_www:_www，这使站点正常工作，就好像我将 chmod 更改为777. 问题是，现在每次我想保存任何文件时，我的文本编辑器都会要求我输入密码，如果我尝试在 Finder 中更改任何内容（例如复制文件），也会发生同样的情况。

What is the correct approach to solve these problems?

解决这些问题的正确方法是什么？

1. Change chmod
2. Change the owner of the files to match those of the web server and perhaps set the text editor (and Finder?) to skip asking for password, or make them use sudo
3. Change the owner of the web server to match the os user (I don't know the consequences)
4. Something else

1. 改变 chmod
2. 更改文件的所有者以匹配 Web 服务器的所有者，并可能将文本编辑器（和 Finder？）设置为跳过询问密码，或让它们使用 sudo
3. 更改web服务器的所有者以匹配os用户（我不知道后果）
4. 别的东西

回答by bgies

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??? :)

如果您将文件夹权限设置为 777，则您已经向任何可以找到该目录的人打开了您的服务器。够清楚？？？:)

There are basically two ways to setup your ownership and permissions. Either you give yourself ownership or you make the webserver the owner of all files.

基本上有两种方法可以设置您的所有权和权限。要么你给自己所有权，要么让网络服务器成为所有文件的所有者。

Webserver as owner (the way most people do it, and the Laravel doc's way):

Webserver 作为所有者（大多数人这样做的方式，以及 Laravel 文档的方式）：

assuming www-data (it could be something else) is your webserver user.

假设 www-data （它可能是其他东西）是您的网络服务器用户。

sudo chown -R www-data:www-data /path/to/your/laravel/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:

如果你这样做，网络服务器拥有所有文件，并且也是组，你会在上传文件或通过 FTP 处理文件时遇到一些问题，因为你的 FTP 客户端将以你的身份登录，而不是你的网络服务器，所以添加您的用户到 webserver 用户组：

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).

当然，这假设您的网络服务器以 www-data（默认 Homestead）运行，并且您的用户是 ubuntu（如果您使用 Homestead，它就是流浪者）。

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

然后将所有目录设置为 755，将文件设置为 644... 设置文件权限

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

SET directory permissions

设置目录权限

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

Your user as owner

您的用户作为所有者

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

我更喜欢拥有所有目录和文件（这样可以更轻松地处理所有内容），所以我这样做：

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

Then I give both myself and the webserver permissions:

然后我给自己和网络服务器权限：

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

Then give the webserver the rights to read and write to storage and cache

然后赋予网络服务器读写存储和缓存的权限

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 :

无论您以哪种方式设置它，您都需要向网络服务器授予读取和写入权限，以进行存储、缓存以及网络服务器也需要上传或写入的任何其他目录（取决于您的情况），因此请从上面的 bashy 运行命令：

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

现在，您是安全的，您的网站可以正常工作，并且您可以相当轻松地处理文件

回答by BassMHL

The permissions for the storageand vendorfolders should stay at 775, for obvious security reasons.

出于明显的安全原因，storage和vendor文件夹的权限应保持在775。

However, both your computer and your server Apache need to be able to write in these folders. Ex: when you run commands like php artisan, your computer needs to write in the logs file in storage.

但是，您的计算机和服务器 Apache 都需要能够写入这些文件夹。例如：当您运行类似 的命令时php artisan，您的计算机需要写入 .log 文件中的日志文件storage。

All you need to do is to give ownership of the folders to Apache :

您需要做的就是将文件夹的所有权授予 Apache ：

sudo chown -R www-data:www-data /path/to/your/project/vendor
sudo chown -R www-data:www-data /path/to/your/project/storage

Then you need to add your computer (referenced by it's username) to the group to which the server Apache belongs. Like so :

然后您需要将您的计算机（由 it's 引用username）添加到服务器 Apache 所属的组中。像这样：

sudo usermod -a -G www-data userName

NOTE:Most frequently, groupNameis www-databut in your case, replace it with _www

注意：最常见的groupName是，www-data但在您的情况下，将其替换为_www

回答by Chris Schwerdt

We've run into many edge cases when setting up permissions for Laravel applications. We create a separate user account (deploy) for owning the Laravel application folder and executing Laravel commands from the CLI, and run the web server under www-data. One issue this causes is that the log file(s) may be owned by www-dataor deploy, depending on who wrote to the log file first, obviously preventing the other user from writing to it in the future.

在为 Laravel 应用程序设置权限时，我们遇到了许多边缘情况。我们创建一个单独的用户帐户 ( deploy) 来拥有 Laravel 应用程序文件夹并从 CLI 执行 Laravel 命令，并在www-data. 这导致的一个问题是日志文件可能由www-data或拥有deploy，这取决于谁首先写入日志文件，显然会阻止其他用户在将来写入它。

I've found that the only sane and secure solution is to use Linux ACLs. The goal of this solution is:

我发现唯一合理且安全的解决方案是使用 Linux ACL。此解决方案的目标是：

1. To allow the user who owns/deploys the application read and write access to the Laravel application code (we use a user named deploy).
2. To allow the www-datauser read access to Laravel application code, but not write access.
3. To prevent any other users from accessing the Laravel application code/data at all.
4. To allow both the www-datauser and the application user (deploy) write access to the storage folder, regardless of which user owns the file (so both deployand www-datacan write to the same log file for example).

1. 允许拥有/部署应用程序的用户对 Laravel 应用程序代码进行读写访问（我们使用名为 的用户deploy）。
2. 允许www-data用户对 Laravel 应用程序代码进行读访问，但不允许写访问。
3. 完全阻止任何其他用户访问 Laravel 应用程序代码/数据。
4. 以允许两个www-data用户和应用程序的用户（deploy）的写访问存储文件夹中，而不管哪个用户拥有该文件（以便既deploy和www-data可以写入例如相同的日志文件）。

We accomplish this as follows:

我们按如下方式完成：

1. All files within the application/folder are created with the default umask of 0022, which results in folders having drwxr-xr-xpermissions and files having -rw-r--r--.
2. sudo chown -R deploy:deploy application/(or simply deploy your application as the deployuser, which is what we do).
3. chgrp www-data application/to give the www-datagroup access to the application.
4. chmod 750 application/to allow the deployuser read/write, the www-datauser read-only, and to remove all permissions to any other users.
5. setfacl -Rdm u:www-data:rwx,u:deploy:rwx application/storage/to set the default permissions on the storage/folder and all subfolders. Any new folders/files created in the storage folder will inherit these permissions (rwxfor both www-dataand deploy).
6. setfacl -Rm u:www-data:rwX,u:deploy:rwX application/storage/to set the above permissions on any existing files/folders.

1. 文件application/夹中的所有文件都使用默认的 umask 来创建0022，这导致文件夹具有drwxr-xr-x权限，文件具有-rw-r--r--.
2. sudo chown -R deploy:deploy application/（或者只是将您的应用程序部署为deploy用户，这就是我们所做的）。
3. chgrp www-data application/授予www-data组访问应用程序的权限。
4. chmod 750 application/允许deploy用户读/写，www-data用户只读，并删除任何其他用户的所有权限。
5. setfacl -Rdm u:www-data:rwx,u:deploy:rwx application/storage/设置storage/文件夹和所有子文件夹的默认权限。在存储文件夹中创建的任何新文件夹/文件都将继承这些权限（rwx对于www-data和deploy）。
6. setfacl -Rm u:www-data:rwX,u:deploy:rwX application/storage/对任何现有文件/文件夹设置上述权限。

回答by Bogdan

Change the permissions for your project folder to enable read/write/exec for any user within the group owning the directory (which in your case is _www):

更改项目文件夹的权限，为拥有该目录的组中的任何用户启用读/写/执行（在您的情况下为_www）：

chmod -R 775 /path/to/your/project

Then add your OS X username to the _wwwgroup to allow it access to the directory:

然后将您的 OS X 用户名添加到_www组中以允许它访问目录：

sudo dseditgroup -o edit -a yourusername -t user _www

回答by Stanislav Potapenko

As posted already

正如已经发布

All you need to do is to give ownership of the folders to Apache :

您需要做的就是将文件夹的所有权授予 Apache ：

but I added -Rfor chowncommand: sudo chown -R www-data:www-data /path/to/your/project/vendor sudo chown -R www-data:www-data /path/to/your/project/storage

但我为chown命令添加了-R： sudo chown -R www-data:www-data /path/to/your/project/vendor sudo chown -R www-data:www-data /path/to/your/project/storage

回答by Siddharth Joshi

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

大多数文件夹应该是正常的“755”和文件，“644”

Laravel requires some folders to be writable for the web server user. You can use this command on unix based OSs.

Laravel 需要一些文件夹对 web 服务器用户是可写的。您可以在基于 Unix 的操作系统上使用此命令。

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

回答by Ryan

The Laravel 5.4 docssay:

该Laravel 5.4文档说：

After installing Laravel, you may need to configure some permissions. Directories within the storageand the bootstrap/cachedirectories should be writable by your web server or Laravel will not run. If you are using the Homestead virtual machine, these permissions should already be set.

安装 Laravel 后，您可能需要配置一些权限。内的目录storage和bootstrap/cache目录应该是可写的Web服务器或Laravel将无法运行。如果你使用的是 Homestead 虚拟机，这些权限应该已经设置好了。

There are a lot of answers on this page that mention using 777permissions. Don't do that.You'd be exposing yourselfto hackers.

此页面上有很多提到使用777权限的答案。不要那样做。你会把自己暴露给黑客。

Instead, follow the suggestions by others about how to set permissions of 755 (or more restrictive). You may need to figure out which user your app is running as by running whoamiin the terminal and then change ownership of certain directories using chown -R.

相反，请遵循其他人关于如何设置 755（或更严格）的权限的建议。您可能需要通过whoami在终端中运行来确定您的应用程序以哪个用户身份运行，然后使用chown -R.

If you do not have permission to use sudoas so many other answers require...

如果您无权使用sudo，因为许多其他答案要求...

Your server is probably a shared host such as Cloudways.

您的服务器可能是共享主机，例如 Cloudways。

(In my case, I had cloned my Laravel application into a second Cloudways server of mine, and it wasn't completely working because the permissions of the storageand bootstrap/cachedirectories were messed up.)

（就我而言，我已经将我的 Laravel 应用程序克隆到我的第二个 Cloudways 服务器中，但它并没有完全工作，因为storage和bootstrap/cache目录的权限被搞砸了。）

I needed to use:

我需要使用：

Cloudways Platform > Server > Application Settings > Reset Permission

Cloudways Platform > Server > Application Settings > Reset Permission

Then I could run php artisan cache:clearin the terminal.

然后我可以php artisan cache:clear在终端中运行。

回答by Davron Achilov

Add to composer.json

添加到 composer.json

"scripts": {
    "post-install-cmd": [
      "chgrp -R www-data storage bootstrap/cache",
      "chmod -R ug+rwx storage bootstrap/cache"
    ]
}

After composer install

后 composer install

回答by markdwhite

The solution posted by bgles is spot on for me in terms of correctly setting permissions initially (I use the second method), but it still has potential issues for Laravel.

bgles 发布的解决方案在最初正确设置权限方面对我来说是正确的（我使用第二种方法），但它仍然存在 Laravel 的潜在问题。

By default, Apache will create files with 644 permissions. So that's pretty much anything in storage/. So, if you delete the contents of storage/framework/views, then access a page through Apache you will find the cached view has been created like:

默认情况下，Apache 将创建具有 644 权限的文件。所以这几乎是 storage/ 中的任何东西。因此，如果您删除 storage/framework/views 的内容，然后通过 Apache 访问页面，您会发现缓存视图已创建如下：

-rw-r--r-- 1 www-data www-data 1005 Dec  6 09:40 969370d7664df9c5206b90cd7c2c79c2

If you run "artisan serve" and access a different page, you will get different permissions because CLI PHP behaves differently from Apache:

如果您运行“artisan serve”并访问不同的页面，您将获得不同的权限，因为 CLI PHP 的行为与 Apache 不同：

-rw-rw-r-- 1 user     www-data 16191 Dec  6 09:48 2a1683fac0674d6f8b0b54cbc8579f8e

In itself this is no big deal as you will not be doing any of this in production. But if Apache creates a file that subsequently needs to be written by the user, it will fail. And this canapply to cache files, cached views and logs when deploying using a logged-in user and artisan. A facile example being "artisan cache:clear" which will fail to delete any cache files that are www-data:www-data 644.

就其本身而言，这没什么大不了的，因为您不会在生产中执行任何此类操作。但是如果 Apache 创建了一个随后需要用户写入的文件，它就会失败。当使用登录用户和工匠进行部署时，这可以应用于缓存文件、缓存视图和日志。一个简单的例子是“artisan cache:clear”，它将无法删除 www-data:www-data 644 的任何缓存文件。

This can be partially mitigated by running artisan commands as www-data, so you'll be doing/scripting everything like:

这可以通过将 artisan 命令作为 www-data 运行来部分缓解，因此您将执行/编写以下所有内容：

sudo -u www-data php artisan cache:clear

Or you'll avoid the tediousness of this and add this to your .bash_aliases:

或者您将避免这种乏味的操作并将其添加到您的 .bash_aliases 中：

alias art='sudo -u www-data php artisan'

This is good enough and is not affecting security in any way. But on development machines, running testing and sanitation scripts makes this unwieldy, unless you want to set up aliases to use 'sudo -u www-data' to run phpunit and everything else you check your builds with that might cause files to be created.

这已经足够了，并且不会以任何方式影响安全性。但是在开发机器上，运行测试和卫生脚本会使这变得笨拙，除非您想设置别名以使用“sudo -u www-data”来运行 phpunit 以及您检查构建的所有其他内容，否则可能会导致创建文件。

The solution is to follow the second part of bgles advice, and add the following to /etc/apache2/envvars, and restart (not reload) Apache:

解决方案是按照 bgles 建议的第二部分，并将以下内容添加到 /etc/apache2/envvars，并重新启动（而不是重新加载）Apache：

umask 002

This will force Apache to create files as 664 by default. In itself, this can present a security risk. However, on the Laravel environments mostly being discussed here (Homestead, Vagrant, Ubuntu) the web server runs as user www-data under group www-data. So if you do not arbitrarily allow users to join www-data group, there should be no additional risk. If someone manages to break out of the webserver, they have www-data access level anyway so nothing is lost (though that's not the best attitude to have relating to security admittedly). So on production it's relatively safe, and on a single-user development machine, it's just not an issue.

这将强制 Apache 默认将文件创建为 664。这本身就存在安全风险。但是，在此处主要讨论的 Laravel 环境（Homestead、Vagrant、Ubuntu）中，Web 服务器以 www-data 组下的用户 www-data 运行。所以如果不随意让用户加入www-data组，应该不会有额外的风险。如果有人设法脱离网络服务器，他们无论如何都拥有 www-data 访问级别，因此不会丢失任何内容（尽管这不是与安全相关的最佳态度）。因此，在生产环境中它相对安全，而在单用户开发机器上，这不是问题。

Ultimately as your user is in www-data group, and all directories containing these files are g+s (the file is always created under the group of the parent directory), anything created by the user or by www-data will be r/w for the other.

最终，由于您的用户在 www-data 组中，并且所有包含这些文件的目录都是 g+s（该文件始终在父目录的组下创建），因此用户或 www-data 创建的任何内容都将是 r/ w 为另一个。

And that's the aim here.

这就是这里的目标。

edit

编辑

On investigating the above approach to setting permissions further, it still looks good enough, but a few tweaks can help:

在研究上述进一步设置权限的方法时，它看起来仍然足够好，但一些调整可以提供帮助：

By default, directories are 775 and files are 664 and all files have the owner and group of the user who just installed the framework. So assume we start from that point.

默认情况下，目录为 775，文件为 664，所有文件都具有刚安装框架的用户的所有者和组。所以假设我们从那一点开始。

cd /var/www/projectroot
sudo chmod 750 ./
sudo chgrp www-data ./

First thing we do is block access to everyone else, and make the group to be www-data. Only the owner and members of www-data can access the directory.

我们做的第一件事是阻止其他人访问，并使组成为 www-data。只有 www-data 的所有者和成员才能访问该目录。

sudo chmod 2775 bootstrap/cache
sudo chgrp -R www-data bootstrap/cache

To allow the webserver to create services.json and compiled.php, as suggested by the official Laravel installation guide. Setting the group sticky bit means these will be owned by the creator with a group of www-data.

按照官方 Laravel 安装指南的建议，允许 web 服务器创建 services.json 和compiled.php。设置组粘滞位意味着这些将由具有一组 www-data 的创建者拥有。

find storage -type d -exec sudo chmod 2775 {} \;
find storage -type f -exec sudo chmod 664 {} \;
sudo chgrp -R www-data storage

We do the same thing with the storage folder to allow creation of cache, log, session and view files. We use find to explicitly set the directory permissions differently for directories and files. We didn't need to do this in bootstrap/cache as there aren't (normally) any sub-directories in there.

我们对存储文件夹做同样的事情，以允许创建缓存、日志、会话和视图文件。我们使用 find 为目录和文件显式设置不同的目录权限。我们不需要在引导程序/缓存中执行此操作，因为那里（通常）没有任何子目录。

You may need to reapply any executable flags, and delete vendor/* and reinstall composer dependencies to recreate links for phpunit et al, eg:

您可能需要重新应用任何可执行标志，并删除 vendor/* 并重新安装 composer 依赖项以重新创建 phpunit 等的链接，例如：

chmod +x .git/hooks/*
rm vendor/*
composer install -o

That's it. Except for the umask for Apache explained above, this is all that's required without making the whole projectroot writeable by www-data, which is what happens with other solutions. So it's marginally safer this way in that an intruder running as www-data has more limited write access.

就是这样。除了上面解释的用于 Apache 的 umask 之外，这就是所有需要的，而无需使 www-data 可写整个项目根，这是其他解决方案发生的情况。因此，这种方式稍微安全一点，因为作为 www-data 运行的入侵者具有更有限的写访问权限。

end edit

结束编辑

Changes for Systemd

Systemd 的变化

This applies to the use of php-fpm, but maybe others too.

这适用于 php-fpm 的使用，但可能也适用于其他人。

The standard systemd service needs to be overridden, the umask set in the override.conf file, and the service restarted:

需要覆盖标准的systemd服务，在override.conf文件中设置umask，重启服务：

sudo systemctl edit php7.0-fpm.service
Use:
    [Service]
    UMask=0002
Then:
sudo systemctl daemon-reload
sudo systemctl restart php7.0-fpm.service

回答by Luca C.

This worked for me:

这对我有用：

cd [..LARAVEL PROJECT ROOT]
sudo find . -type f -exec chmod 644 {} \;
sudo find . -type d -exec chmod 755 {} \;
sudo chmod -R 777 ./storage
sudo chmod -R 777 ./bootstrap/cache/

What it does:

它能做什么：

• Change all file permissions to 644
• Change all folder permissions to 755
• For storage and bootstrap cache (special folders used by laravel for creating and executing files, not available from outside) set permission to 777, for anything inside

• 将所有文件权限更改为 644
• 将所有文件夹权限更改为 755
• 对于存储和引导缓存（laravel 用于创建和执行文件的特殊文件夹，无法从外部访问）将权限设置为 777，对于内部的任何内容

Note: Maybe you can not, or don't need, to do it with sudo prefix. it depends on your user's permissions, group, etc...

注意：也许您不能或不需要使用 sudo 前缀来执行此操作。这取决于您的用户的权限、组等...