web-dev-qa-db-ja.com

のファイル許可を設定する方法 Laravel 5人（および他の人）

私は所有者が_www:_wwwに設定されているApache Web Serverを使用しています。たとえば、新しいLaravel 5プロジェクトを作成するときなど、ファイル権限に関するベストプラクティスが何であるかわかりません。

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

公式文書は言う：

Laravelはいくつかのパーミッションを設定する必要があるかもしれません：storageとvendor内のフォルダーはウェブサーバーによる書き込みアクセスを必要とします。

Webサーバがstorageおよびvendorフォルダ自体にアクセスする必要があるのか​​、それとも現在のコンテンツだけにアクセスする必要があるのでしょうか。

私は、はるかに優れたものがパーミッションの代わりに owner を変更していると思います。私は全てのLaravelのファイルパーミッションを_www:_wwwに再帰的に変更しました、そしてそれは私がまるでchmodを777に変更したかのように、サイトを正しく機能させました。問題は、ファイルを保存するたびにテキストエディタがパスワードを要求することです。たとえば、ファイルをコピーするなど、Finderで何かを変更しようとした場合も同様です。

これらの問題を解決するための正しい方法は何ですか？

  1. chmodを変更
  2. ファイルの所有者をWebサーバーの所有者と一致するように変更し、おそらくテキストエディタ（およびFinder？）をパスワードの入力をスキップするように設定するか、またはSudoを使用するようにします。
  3. Osユーザーと一致するようにWebサーバーの所有者を変更します（結果はわかりません）
  4. 他に何か
phpapachelaravellaravel-5file-permissions
144
Robo Robok

この議論を見ている人にとって明らかなことを言うために…あなたのフォルダのどれかに777のアクセス権を与えるなら、あなたは誰でもそのディレクトリの中のファイルを読み、書きそして実行することを許可しています。任意のファイル、ウイルス、またはその他のファイルをアップロードするためのANYONE（世界中のあらゆるハッカーまたは悪意のある人）許可があり、そのファイルを実行すると...

あなたのフォルダのアクセス権を777に設定している場合、あなたはあなたのサーバーをディレクトリを見つけることができるものに開いています。十分にクリア？？？ :)

所有権と許可を設定するには、基本的に2つの方法があります。あなたがあなた自身に所有権を与えるか、あなたはウェブサーバをすべてのファイルの所有者にするかのどちらかです。

所有者としてのWebサーバー（ほとんどの人がそうしている方法、およびLaravel docの方法）：

www-data（それは他のものかもしれません）をあなたのWebサーバユーザと仮定します。

    Sudo chown -R www-data：www-data/path/to/your/laravel/root /ディレクトリ

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

   Sudo usermod -a -G www-data ubuntu

もちろん、これはあなたのWebサーバがwww-data（Homesteadのデフォルト）として動作していて、あなたのユーザがubuntuであることを前提としています（Homesteadを使っているならばそれは価値があります）。

それから、あなたはすべてのディレクトリを755にそしてあなたのファイルを644に設定します。

/ path/to /あなたの/ laravel/root /ディレクトリ-type f -exec chmod 644 {} \; 

SETディレクトリの権限

/ path/to /あなたの/ laravel/root /ディレクトリ-type d -exec chmod 755 {} \;

所有者としてのあなたのユーザー

私はすべてのディレクトリとファイルを所有することを好みます（それによってすべての作業がはるかに簡単になります）。

Sudo chown -R my-user：www-data/path/to/your/laravel/root /ディレクトリ

それから私は自分自身とWebサーバーの両方に権限を与えます。

/ path/to /あなたの/ laravel/root /ディレクトリ-type f -exec chmod 664 {} \; 
また、/ path/to/your/laravel/root /ディレクトリを検索します。-d type -exec chmod 775 {} \;

次にWebサーバーにストレージとキャッシュの読み書きの権利を与えます

どちらの方法で設定した場合でも、Webサーバにアップロード、書き込みが必要なストレージ、キャッシュ、その他のディレクトリに対する読み書きの許可を与える必要があるので、上記のbashyからコマンドを実行します。

Sudo chgrp -R wwwデータストレージブートストラップ/キャッシュ
 Sudo chmod -R ug + rwxストレージブートストラップ/キャッシュ

今、あなたは安全であなたのウェブサイトは機能します、そしてあなたはかなり簡単にファイルを操作することができます

410
bgies

明らかなセキュリティ上の理由から、storageおよびvendorフォルダーに対する許可は775のままにする必要があります。

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

あなたがする必要があるのは、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

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

Sudo usermod -a -G www-data userName

注： ほとんどの場合、groupNameはwww-dataですが、あなたの場合は_wwwに置き換えてください。

36
BassMHL

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

私は、Linux ACLを使用することが唯一の安全で安全な解決策であることを発見しました。このソリューションの目的は次のとおりです。

  1. アプリケーションを所有またはデプロイしているユーザーに、Laravelアプリケーションコードへの読み取りおよび書き込みアクセスを許可するには（deployという名前のユーザーを使用します）。
  2. www-dataユーザーにLaravelアプリケーションコードへの読み取りアクセスを許可しますが、書き込みアクセスは許可しません。
  3. 他のユーザーがLaravelアプリケーションのコードまたはデータにまったくアクセスできないようにします。
  4. どちらのユーザーがファイルを所有しているかにかかわらず、www-dataユーザーとアプリケーションユーザー（deploy）の両方がstorageフォルダへの書き込みアクセスを許可するため（たとえば、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/。 storageフォルダに作成された新しいフォルダ/ファイルは、これらの権限を継承します（www-dataとrwxの両方のdeploy）。
  6. 既存のファイル/フォルダに上記のパーミッションを設定するためのsetfacl -Rm u:www-data:rwX,u:deploy:rwX application/storage/。
13
Chris Schwerdt

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

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

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

Sudo dseditgroup -o edit -a yourusername -t user _www
12
Bogdan

投稿済み

あなたがする必要があるのは、Apacheにフォルダの所有権を与えることだけです：

しかし、 -R を chown commandに追加しました：Sudo chown -R www-data:www-data /path/to/your/project/vendor Sudo chown -R www-data:www-data /path/to/your/project/storage

7
Stanislav Potapenko

ほとんどのフォルダは通常の "755"とファイル、 "644"になります。

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

Sudo chgrp -R www-data storage bootstrap/cache
Sudo chmod -R ug+rwx storage bootstrap/cache
5
Siddharth Joshi

Bglesが投稿した解決策は、最初はパーミッションを正しく設定するという点で私には注目されています（私は2番目の方法を使用します）が、それでもLaravelには潜在的な問題があります。

デフォルトでは、Apacheは644のパーミッションを持つファイルを作成します。それで、それはストレージ/のほとんど何でもです。そのため、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がファイルを作成し、それが後でユーザーによって書き込まれる必要がある場合、それは失敗します。ログインユーザーと職人を使用してデプロイする場合、この can はキャッシュファイル、キャッシュされたビュー、およびログに適用できます。 www-data：www-data 644のキャッシュファイルを削除するのに失敗するでしょう。

これは、www-dataとして職人のコマンドを実行することで部分的に軽減できます。

Sudo -u www-data php artisan cache:clear

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

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

これで十分であり、セキュリティにはまったく影響しません。しかし開発マシンでは、phpunitを実行するために 'Sudo -u www-data'を使用するような別名を設定し、それ以外でビルドをチェックすることでファイルが作成される可能性がある場合を除いて.

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

umask 002

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

最終的にはあなたのユーザは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インストールガイドで推奨されているように、Webサーバーがservices.jsonとcompile.phpを作成できるようにする。グループスティッキビットを設定することは、これらがwwwデータのグループと共に作成者によって所有されることを意味します。

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

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

実行可能フラグを再適用し、vendor/*を削除し、作曲家の依存関係を再インストールしてphpunit et alのリンクを再作成する必要があるかもしれません。例えば：

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

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

終了編集

Systemdに対する変更

これはphp-fpmの使用にも当てはまりますが、他の人にも当てはまります。

標準のsystemdサービスを上書きし、umaskをoverride.confファイルに設定して、サービスを再起動する必要があります。

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

Laravel 5.4のドキュメント say：

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を実行することができます。

3
Ryan

私はEC2インスタンスにlaravelをインストールし、パーミッションエラーを修正するために3日を費やし、そしてついにそれを修正しました。それで、私はこの経験を他のものと共有したいです。

  1. ユーザーの問題ec2インスタンスにログインしたとき、私のユーザー名はec2-user、ユーザーグループはec2-userです。そしてウェブサイトはhttpdユーザーの下で動作します：Apache：ApacheそれではApacheの許可を設定するべきです。

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

    ストレージ

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

B.許可最初に、file_put_contentsを削除するために777をストレージの下に設定する指示が表示されます。だから私はストレージ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/

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

  1. そして、この作曲家更新php職人のキャッシュを忘れないでください。

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

    私はあなたがあなたの時間を節約することを願っています。がんばろう。ハッケン

2
Hacken Lee

Composer.jsonに追加する

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

composer installの後

2
Davron Achilov

私は自分のスクリプトを書くことでプロジェクトを設定する際の苦痛を和らげることにしました。

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

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

ブートストラップが完了するのを待ってください。

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

1
Jonathan

私は次のように設定しました：

  • NGINX（実行ユーザ：nginx）
  • PHP-FPM

そして、受け入れられた答えで@ bgiesが示唆しているように正しくパーミッションを適用しました。私の場合の問題はphp-fpmの設定された実行中のユーザーとグループで、元々はApacheでした。

あなたがphp-fpmでNGINXを使っているのなら、php-fpmの設定ファイルを開くべきです：

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

そしてuserとgroup optionsの値を、NGINXが動作するように設定された1つの値に置き換えます。私の場合、両方とも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サービスを再起動してください。

0
Amirreza Nasiri