Laravelのファイル権限を設定するにはどうすればよいですか？

所有者がに設定されているApache Webサーバーを使用しています_www:_www。新しいLaravel 5プロジェクトを作成するときなど、ファイルのアクセス許可のベストプラクティスは何なのかわかりません。

Laravel 5では、/storageフォルダーが書き込み可能である必要があります。私はそれを機能させるために多くの異なるアプローチを見つけました、そして私は通常それを777再帰的にchmodにすることで終わります。私はそれが最善の考えではないことを知っています。

公式のドキュメントは言う：

Laravelでは、いくつかの権限を構成する必要がある場合があります。その中にフォルダーが storageありvendor、Webサーバーによる書き込みアクセスが必要です。

それは、Webサーバーがstorageとvendorフォルダー自体または現在のコンテンツだけにアクセスする必要があるということですか？

私ははるかに良いことは、権限の代わりに所有者を変更することだと思います。Laravelのすべてのファイル権限を再帰的_www:_wwwに変更し、chmodをに変更したかのように、サイトを正しく機能させました777。問題は、ファイルを保存するたびにテキストエディターからパスワードを要求されることです。ファイルをコピーするなど、Finderで何かを変更しようとすると、同じことが起こります。

これらの問題を解決するための正しいアプローチは何ですか？

1. 変化する chmod
2. ファイルの所有者をWebサーバーの所有者と一致するように変更し、おそらくテキストエディター（およびFinder？）を設定して、パスワードの要求をスキップするか、ファイルを使用させます。 sudo
3. osユーザーと一致するようにWebサーバーの所有者を変更します（結果はわかりません）
4. 他の何か

このディスカッションを表示している誰にとっても明らかなことを述べるために....フォルダーに777のアクセス許可を与えると、誰でもそのディレクトリ内の任意のファイルの読み取り、書き込み、および実行を許可することになります。 ANYONE（全世界の任意のハッカーまたは悪意のある人物）の任意のファイル、ウイルス、またはその他のファイルをアップロードする許可、そしてそのファイルを実行...

フォルダのアクセス許可を777に設定している場合は、そのディレクトリを見つけることができる任意のユーザーに対してサーバーを開いています。十分にクリア？？？:)

所有権と権限を設定するには、基本的に2つの方法があります。自分に所有権を与えるか、Webサーバーをすべてのファイルの所有者にします。

所有者としてのWebサーバー（ほとんどの人が行う方法とLaravelのドキュメントの方法）：

www-data（それは何か他のものである可能性があります）があなたのウェブサーバーユーザーであると仮定します。

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

これを行うと、Webサーバーはすべてのファイルを所有し、グループでもあります。FTPクライアントはWebサーバーではなくユーザーとしてログインするため、ファイルのアップロードやFTPを使用した作業で問題が発生します。ユーザーをwebserverユーザーグループに追加します。

sudo usermod -a -G www-data ubuntu

もちろん、これは、Webサーバーがwww-data（Homesteadのデフォルト）として実行され、ユーザーがubuntu（Homesteadを使用している場合はvagrant）であることを前提としています。

次に、すべてのディレクトリを755に設定し、ファイルを644に設定します。SETファイルのアクセス許可

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

SETディレクトリー許可

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

所有者としてのユーザー

私はすべてのディレクトリとファイルを所有することを好むので（すべてを簡単に操作できます）、次のようにします。

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

次に、自分とWebサーバーの両方のアクセス許可を与えます。

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 {} \;

次に、ウェブサーバーにストレージとキャッシュの読み取りと書き込みの権限を与えます

どちらの方法で設定する場合でも、ウェブサーバーにアップロードや書き込みを行うために必要なストレージ、キャッシュ、その他のディレクトリ（状況によって異なります）に対して読み取りおよび書き込み権限を付与する必要があるため、上記のbashyからコマンドを実行します。

sudo chgrp -R www-data storage bootstrap / cache
sudo chmod -R ug + rwxストレージブートストラップ/キャッシュ

これで、安全でWebサイトが機能し、ファイルを簡単に操作できます

storageとvendorフォルダの権限は、775明らかなセキュリティ上の理由から、のままにする必要があります。

ただし、コンピュータとサーバーの両方がApacheでこれらのフォルダに書き込むことができる必要があります。例：のようなコマンドを実行する場合php artisan、コンピューターはのログファイルに書き込む必要がありますstorage。

フォルダーの所有権を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

次にusername、Apacheが属しているグループにコンピューター（で参照される）を追加する必要があります。そのようです ：

sudo usermod -a -G www-data userName

注：最も頻繁に、groupNameですwww-dataが、あなたの場合、それを_www

Laravelアプリケーションの権限を設定するときに、多くのエッジケースに遭遇しました。deployLaravelアプリケーションフォルダーを所有し、CLIからLaravelコマンドを実行するための個別のユーザーアカウント（）を作成し、でWebサーバーを実行しますwww-data。これにより発生する問題の1つは、ログファイルは、誰が最初にログファイルに書き込んだwww-dataかdeployに応じて、またはによって所有されている可能性があり、明らかに他のユーザーが今後ログファイルに書き込むことができないことです。

正気で安全な唯一の解決策は、Linux ACLを使用することです。このソリューションの目標は次のとおりです。

1. アプリケーションを所有またはデプロイするユーザーに、Laravelアプリケーションコードへの読み取りおよび書き込みアクセスを許可するには（という名前のユーザーを使用しますdeploy）。
2. www-dataユーザーにLaravelアプリケーションコードへの読み取りアクセスを許可するが、書き込みアクセスは許可しない。
3. 他のユーザーがLaravelアプリケーションコード/データにまったくアクセスできないようにするため。
4. 両方可能にするためにwww-data、ユーザとアプリケーションユーザ（deployストレージフォルダへの）書き込みアクセスを、関係なく、どのユーザの（両方のように、ファイルを所有deployし、www-data例えば同じログファイルに書き込むことができます）。

これは次のように実現します。

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-datadeploy
6. setfacl -Rm u:www-data:rwX,u:deploy:rwX application/storage/ 既存のファイル/フォルダに上記の権限を設定します。

プロジェクトフォルダーの権限を変更して、ディレクトリを所有するグループ（この場合は_www）内のすべてのユーザーに対して読み取り/書き込み/実行を有効にします。

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

次に、OS Xユーザー名を_wwwグループに追加して、ディレクトリへのアクセスを許可します。

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

すでに投稿されたとおり

フォルダーの所有権をApacheに与えるだけです。

しかし、私は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

ほとんどのフォルダは通常の「755」、ファイルは「644」である必要があります

Laravelでは、Webサーバーユーザーが書き込み可能なフォルダーがいくつか必要です。このコマンドは、UNIXベースのOSで使用できます。

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

composer.jsonに追加

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

後 composer install

Laravel 5.4のドキュメントは言います：

Laravelをインストールした後、いくつかの権限を構成する必要があるかもしれません。storageおよび内のbootstrap/cacheディレクトリは、Webサーバーから書き込み可能である必要があります。そうしないと、Laravelは実行されません。Homestead仮想マシンを使用している場合、これらの権限はすでに設定されているはずです。

このページには、777権限の使用について言及する多くの回答があります。それをしないでください。あなたはハッカーに身をさらすことになるでしょう。

代わりに、755（またはより制限的な）のアクセス権を設定する方法について、他のユーザーの提案に従ってください。whoamiターミナルで実行することにより、アプリを実行しているユーザーを特定し、を使用して特定のディレクトリの所有権を変更する必要がある場合がありますchown -R。

sudo他の多くの回答が必要とするように使用する権限がない場合...

サーバーはおそらくCloudwaysなどの共有ホストです。

（私の場合、Laravelアプリケーションを私の2つ目のCloudwaysサーバーに複製しましたが、storageおよびのbootstrap/cacheディレクトリの権限がめちゃくちゃになったため、完全に機能していませんでした。）

私は使用する必要がありました：

Cloudways Platform > Server > Application Settings > Reset Permission

その後php artisan cache:clear、ターミナルで実行できます。

bglesによって投稿された解決策は、最初に権限を正しく設定するという点で私にとっては定評があります（私は2番目の方法を使用します）が、Laravelには潜在的な問題がまだあります。

デフォルトでは、Apacheは644の権限を持つファイルを作成します。ですから、それはstorage /のほとんどすべてです。したがって、storage / framework / viewsのコンテンツを削除した場合、Apacheを介してページにアクセスすると、キャッシュされたビューが次のように作成されていることがわかります。

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

「artisan serve」を実行して別のページにアクセスすると、CLI PHPの動作がApacheとは異なるため、異なる権限が付与されます。

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

本番環境ではこれを行わないため、これ自体は大した問題ではありません。しかし、Apacheが後でユーザーが書き込む必要のあるファイルを作成すると、失敗します。そして、これは、ログインしたユーザーと職人を使用してデプロイするときに、キャッシュファイル、キャッシュビュー、およびログに適用できます。「artisan cache：clear」の簡単な例は、www-data：www-data 644であるキャッシュファイルの削除に失敗します。

これは、artisanコマンドをwww-dataとして実行することで部分的に軽減できるため、次のようなすべてのことを実行/スクリプト化します。

sudo -u www-data php artisan cache:clear

または、この面倒な作業を避け、これを.bash_aliasesに追加します。

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

これで十分であり、セキュリティにはまったく影響しません。ただし、開発マシンでは、「sudo -u www-data」を使用してphpunitを実行するエイリアスを設定したり、ビルドをチェックしたりしてファイルが作成される可能性があるすべての場合を除いて、テストおよびサニテーションスクリプトを実行するとこれは扱いにくくなります。

解決策は、bglesアドバイスの2番目の部分に従い、以下を/ etc / apache2 / envvarsに追加し、Apacheを再起動する（リロードしない）ことです。

umask 002

これにより、Apacheはデフォルトで664としてファイルを作成します。これ自体、セキュリティ上のリスクをもたらす可能性があります。ただし、ここで主に説明されているLaravel環境（Homestead、Vagrant、Ubuntu）では、Webサーバーはwww-dataグループのユーザーwww-dataとして実行されます。したがって、ユーザーがwww-dataグループへの参加を勝手に許可しない場合、追加のリスクはありません。誰かがWebサーバーから抜け出すことができたとしても、いずれにしてもwww-dataアクセスレベルを持っているので、何も失われません（ただし、セキュリティに関係することは明らかに最善の態度ではありません）。したがって、本番環境では比較的安全であり、シングルユーザー開発マシンでは問題になりません。

最終的にユーザーがwww-dataグループに属し、これらのファイルを含むすべてのディレクトリがg + s（ファイルは常に親ディレクトリのグループの下に作成されます）であるため、ユーザーまたはwww-dataによって作成されたものはすべてr /になります。他のw。

そして、それがここの目的です。

編集する

上記の方法でアクセス許可をさらに設定することを検討すると、それでも十分に見えますが、いくつかの微調整が役立ちます。

デフォルトでは、ディレクトリは775、ファイルは664で、すべてのファイルには、フレームワークをインストールしたばかりのユーザーの所有者とグループがあります。したがって、その時点から始めると仮定します。

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

私たちが最初に行うことは、他の全員へのアクセスをブロックし、グループをwww-dataにすることです。www-dataの所有者とメンバーのみがディレクトリにアクセスできます。

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

公式のLaravelインストールガイドで提案されているように、ウェブサーバーが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

キャッシュ、ログ、セッション、ビューファイルの作成を可能にするために、ストレージフォルダーでも同じことを行います。findを使用して、ディレクトリとファイルに対して異なる方法でディレクトリのアクセス許可を明示的に設定します。（通常は）サブディレクトリがないため、ブートストラップ/キャッシュでこれを行う必要はありませんでした。

phpunitなどへのリンクを再作成するには、実行可能フラグを再適用し、vendor / *を削除してcomposer依存関係を再インストールする必要がある場合があります。例：

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

それでおしまい。上で説明したApacheのumaskを除いて、これは、プロジェクトルート全体をwww-dataで書き込み可能にすることなく必要なすべてです。これは、他のソリューションで発生することです。したがって、www-dataとして実行されている侵入者の書き込みアクセスが制限されるという点で、この方法はわずかに安全です。

編集を終了

Systemdの変更

これはphp-fpmの使用に適用されますが、他の場合も同様です。

標準の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

これは私のために働きました：

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/

それがすること：

• すべてのファイル権限を644に変更します
• すべてのフォルダのアクセス許可を755に変更します
• ストレージとブートストラップキャッシュ（ファイルを作成および実行するためにlaravelで使用される特別なフォルダー。外部からは使用できません）の場合は、許可を777に設定します。

注：sudo接頭辞を使用してこれを行うことはできないか、必要ないかもしれません。ユーザーの権限、グループなどによって異なります...

私は、プロジェクトのセットアップの苦痛を軽減するために、独自のスクリプトを書くことにしました。

プロジェクトルート内で以下を実行します。

wget -qO- https://raw.githubusercontent.com/defaye/bootstrap-laravel/master/bootstrap.sh | sh

ブートストラップが完了するのを待って、準備完了です。

使用する前にスクリプトを確認してください。

EC2インスタンスにlaravelをインストールし、許可エラーを修正するために3日間を費やし、ついに修正しました。この経験を他の人と共有したいと思います。

1. ユーザーの問題ec2インスタンスにログインしたとき、ユーザー名はec2-userで、ユーザーグループはec2-userです。そして、ウェブサイトはhttpd user：apache：apacheの下で動作するので、apacheに権限を設定する必要があります。

2. フォルダーとファイルのアクセス許可A.フォルダー構造まず、このようなフォルダー構造がストレージ下にあることを確認する必要があります

   ストレージ

   • フレームワーク
     • キャッシュ
     • セッション
     • 景色
   • ログフォルダー構造は、使用するLaravelのバージョンによって異なる場合があります。私のlaravelバージョンは5.2で、バージョンに応じて適切な構造を見つけることができます。

B.許可最初に、777をストレージの下に設定してfile_put_contentsを削除する手順を確認しました。だから私はストレージchmod -R 777ストレージへの許可777を設定しましたが、エラーは修正されませんでした。ここでは、1つを検討する必要があります。ストレージ/セッションおよびビューにファイルを書き込む人。それはec2-userではなく、Apacheです。はい、そうです。「apache」ユーザーは、セッションおよびビューフォルダにファイル（セッションファイル、コンパイル済みビューファイル）を書き込みます。したがって、これらのフォルダへの書き込み権限をapacheに与える必要があります。デフォルトでは、SELinuxは/ var / wwwフォルダーがapacheデーモンによって読み取り専用であるべきだと言っています。

このため、selinuxを0に設定できます：setenforce 0

これは一時的に問題を解決できますが、これによりmysqlが機能しなくなります。これはあまり良い解決策ではありません。

次のコマンドを使用して、ストレージフォルダに読み取り/書き込みコンテキストを設定できます（テストするには、setenforce 1を忘れないでください）。

chcon -Rt httpd_sys_content_rw_t storage/

その後、問題は修正されます。

3. そして、この作曲家はphp artisan cache：clearを更新することを忘れないでください

   これらのコマンドは、後または前に役立ちます。

   時間を節約してください。幸運を。ハッケン

私は次の構成を持っていました：

• nginxの（ユーザーが実行しています。nginx）
• PHP-FPM

承認された回答で提案されている@bgiesに従って、権限を正しく適用しました。私の場合の問題は、元々はphp-fpmの設定された実行中のユーザーとグループでしたapache。

php-fpmでNGINXを使用している場合は、php-fpmの構成ファイルを開く必要があります。

nano /etc/php-fpm.d/www.config

そしてuser、groupオプションの値を1つのNGINXで置き換えるように構成します。私の場合、どちらもnginx：

... ; Unix user/group of processes ; Note: The user is mandatory. If the group is not set, the default user's group ; will be used. ; RPM: apache Choosed to be able to access some dir as httpd user = nginx ; RPM: Keep a group allowed to write in log dir. group = nginx ...

それを保存し、nginxおよびphp-fpmサービスを再起動します。

Laravel開発者にとって、ディレクトリの問題は少し面倒な場合があります。私のアプリケーションでは、オンザフライでディレクトリを作成し、ローカル環境でこのディレクトリにファイルを正常に移動していました。次に、サーバーで、新しく作成したディレクトリにファイルを移動するときにエラーが発生しました。

これが私がやったことと、最後に成功した結果です。

1. 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 {} \;
2. chcon -Rt httpd_sys_content_rw_t /path/to/my/file/upload/directory/in/laravel/project/
3. その場で新しいディレクトリを作成しながら、私はコマンドを使用しました mkdir($save_path, 0755, true);

本番サーバーでこれらの変更を行った後、新しいディレクトリを作成し、ファイルをそれらに移動しました。

最後に、Laravelでファイルファサードを使用すると、次のようなことができます。 File::makeDirectory($save_path, 0755, true);

これに対するさらに良い解決策を見つけました。phpがデフォルトで別のユーザーとして実行されているために発生します。

これを修正するには

sudo nano /etc/php/7.0/fpm/pool.d/www.conf

次に、 user = "put user that owns the directories" group = "put user that owns the directories"

次に：

sudo systemctl reload php7.0-fpm