Changing File Permissions

短い説明

Linux ファイルの権限 は主に3つの要素で構成されています — ファイルまたはフォルダーの所有者が持つ権限、ファイルまたはフォルダーを所有するグループのメンバーが持つ権限、そして他の誰もがファイルやフォルダーにアクセスまたは変更するための権限です。これら3つの権限要素は通常、所有者の権限レベル、グループの権限レベル、そして全員の権限レベルの順に3つの数字で表されます。技術的には4つ目の要素がありますが、それはWordPressを安全に保つために知っておく必要はありません。ここでは議論しません。

ユーザー、グループ、そして他のすべての人に対して、3種類のアクセスがあります。それは読み取りアクセス、書き込みアクセス、実行アクセスです。読み取りアクセスはファイルやディレクトリの内容を読むことを許可します。書き込みアクセスはファイルやディレクトリを変更することを許可します。そして実行アクセスはファイルをプログラムやスクリプトのように実行することを許可します。

権限モード

7      5      5
user   group  world
r+w+x  r+x    r+x
4+2+1  4+0+1  4+0+1  = 755

権限モードは、ユーザー、ファイルグループ、および他のすべての人のために次の値を合計することによって計算されます。図はその方法を示しています。

• Read 4 – ファイルを読み取ることが許可されている
• Write 2 – ファイルを記述/変更することが許可されている
• eXecute 1 – 読み取り/書き込み/削除/変更/ディレクトリ

7      4      4
user   group  world
r+w+x  r      r
4+2+1  4+0+0  4+0+0  = 744

例の権限モード

## WordPressの権限スキーム

権限はホストによって異なるため、このガイドでは一般的な原則のみを詳述します。すべてのケースをカバーすることはできません。このガイドは、標準セットアップを実行しているサーバーに適用されます（共有ホスティングで「suexec」メソッドを使用している場合は、以下を参照してください）。

通常、すべてのファイルはウェブサーバー上のユーザー(ftp)アカウントが所有し、そのアカウントによって書き込み可能であるべきです。共有ホストでは、ファイルは決してウェブサーバープロセス自体（時にはwww、またはapache、またはnobodyユーザー）によって所有されるべきではありません。

WordPressから書き込みアクセスが必要なファイルは、WordPressによって使用されるユーザーアカウントによって所有またはグループ所有されるべきです（これはサーバーアカウントとは異なる場合があります）。たとえば、サーバーにファイルをFTPで送受信できるユーザーアカウントがあるかもしれませんが、サーバー自体は別のユーザー、別のユーザーグループ（たとえば、dhapacheやnobody）を使用して実行されるかもしれません。WordPressがFTPアカウントとして実行されている場合、そのアカウントは書き込みアクセスを持っている必要があります。つまり、ファイルの所有者であるか、書き込みアクセスを持つグループに属している必要があります。後者の場合、権限はデフォルトよりも緩やかに設定されることになります（たとえば、フォルダーは755ではなく775、ファイルは644ではなく664）。

WordPressのファイルとフォルダーの権限は、実行したインストールの種類やインストール時のシステム環境のumask設定に応じて、ほとんどのユーザーにとって同じであるべきです。

注意: 経験豊富なユーザーがあなたのためにWordPressをインストールした場合、ファイル権限を変更する必要はないでしょう。権限エラーの問題が発生していない限り、またはあなたが望むのでない限り、これをいじるべきではありません。

注意: 自分でWordPressをインストールした場合、ファイル権限を変更する必要があるでしょう。一部のファイルやディレクトリは、特にwp-config.phpファイルについて、より厳格な権限で「強化」されるべきです。このファイルは最初に644の権限で作成され、そうしたままにしておくのは危険です。セキュリティと強化を参照してください。

通常、すべてのコアWordPressファイルは、あなたのユーザーアカウント（または異なる場合はhttpdアカウント）によってのみ書き込み可能であるべきです。（ただし、複数のFTPアカウントがインストールを管理するために使用されることがあり、すべてのFTPユーザーが知られていて信頼できる場合、つまり共有ホストでない場合、グループ書き込みを割り当てることが適切な場合があります。詳細についてはサーバー管理者に問い合わせてください。）ただし、mod_rewriteパーマリンクや他の.htaccess機能を利用する場合は、WordPressが/.htaccessファイルにも書き込めることを確認する必要があります。

組み込みのテーマエディタを使用したい場合、すべてのファイルはグループ書き込み可能である必要があります。ファイル権限を変更する前にそれを試してみてください。うまくいくはずです。（これは、異なるユーザーがWordPressパッケージやプラグインまたはテーマをアップロードした場合に当てはまるかもしれません。管理者を介してインストールされたプラグインやテーマには問題ありません。異なるFTPユーザーでファイルをアップロードする場合、グループ書き込みが必要です。共有ホスティングでは、グループが信頼できるユーザーのみに限定されていることを確認してください…apacheユーザーはグループに含まれてはいけませんし、ファイルを所有してはいけません。）

一部のプラグインは、/wp-content/フォルダーを書き込み可能にする必要がありますが、その場合はインストール中に通知されます。場合によっては、755の権限を割り当てる必要があるかもしれません。/wp-content/cache/や/wp-content/uploads/についても同様です（MultiSiteを使用している場合、/wp-content/blogs.dir/についてもこれを行う必要があるかもしれません）。

/wp-content/以下の追加ディレクトリは、それらを必要とするプラグイン/テーマによって文書化されるべきです。権限は異なります。

|<br>|- index.php
|- wp-admin
|   |- wp-admin.css
|- wp-blog-header.php
|- wp-comments-post.php
|- wp-commentsrss2.php
|- wp-config.php
|- wp-content
|   |- cache
|   |- plugins
|   |- themes
|   |- uploads
|- wp-cron.php
|- wp-includes
|- xmlrpc.php

suexecを使用した共有ホスティング

上記は、PHPバイナリを実行するために「suexec」アプローチを使用する共有ホスティングシステムには適用されないかもしれません。これは多くのウェブホストによって使用される一般的なアプローチです。これらのシステムでは、phpプロセスはphpファイル自体の所有者として実行され、よりシンプルな構成と特定の共有ホスティングのケースに対してより安全な環境を提供します。

注意: suexecメソッドは、単一サイトサーバー構成では決して使用すべきではありません。これは特定の共有ホスティングのケースに対してのみより安全です。

そのようなsuexec構成では、正しい権限スキームは理解しやすいです。

• すべてのファイルは実際のユーザーアカウントによって所有されるべきであり、httpdプロセスに使用されるユーザーアカウントではありません。
• グループ所有権は無関係です。ウェブサーバープロセスの権限チェックに特定のグループ要件がない限り、通常はそうではありません。
• すべてのディレクトリは755または750であるべきです。
• すべてのファイルは644または640であるべきです。例外: wp-config.phpは440または400にするべきで、他のユーザーがサーバー上で読み取るのを防ぎます。
• すべてのディレクトリに777を与えるべきではありません。アップロードディレクトリでさえも。phpプロセスはファイルの所有者として実行されているため、所有者の権限を取得し、755のディレクトリに書き込むことができます。

この特定のタイプのセットアップでは、WordPressは適切な所有権で直接ファイルを作成できることを検出し、プラグインのアップグレードやインストール時にFTP資格情報を要求しません。

このセットアップでシステム管理者によって使用される一般的な方法は次のとおりです。

• suPHP、php-cgiを介して実行され、2013年以降メンテナンスされていません。
• mod_ruid2、apacheモジュール、2013年以降メンテナンスされていません。
• mpm-itk、apacheモジュール。
• mod_fcgid、Apacheモジュールおよびより広範な構成を持つFastCGIサーバー。
• PHP-FPM、ApacheおよびNginxで使用するための共有OPCodeを持つ代替FastCGIサーバー。
  

FTPクライアントの使用

FTPプログラム（「クライアント」）を使用すると、リモートホスト上のファイルやディレクトリの権限を設定できます。この機能は、プログラムメニューでchmodまたはset permissionsと呼ばれることがよくあります。

WordPressのインストールでは、変更したいと思う可能性が高い2つのファイルは、インデックスページとレイアウトを制御するCSSです。index.phpを変更する方法は次のとおりです – このプロセスは任意のファイルに対して同じです。

以下のスクリーンショットで、最後の列を見てください – それが権限を示しています。少し混乱するかもしれませんが、今は文字の順序に注意してください。

初期権限

‘index.php’を右クリックし、「ファイル権限」を選択します。

ポップアップ画面が表示されます。

ファイル権限の変更

チェックボックスについて心配しないでください。「数値値:」を削除し、必要な数値を入力します – この場合は666です。次にOKをクリックします。

権限が変更されました。

ファイル権限が変更されたことが確認できます。

隠しファイルを表示する

デフォルトでは、ほとんどのFTPクライアント、特にFileZillaは、隠しファイル（ピリオド（.）で始まるファイル）を表示しません。しかし、ある時点で、ファイルの権限を変更するために隠しファイルを表示する必要があるかもしれません。たとえば、permalinksを制御するファイルである.htaccessファイルを、書き込み可能にする必要があるかもしれません。

FileZillaで隠しファイルを表示するには、上部メニューから「表示」を選択し、「隠しファイルを表示」を選択する必要があります。ファイルの表示が更新され、以前は隠されていたファイルが表示されるはずです。

FileZillaが常に隠しファイルを表示するようにするには、[編集]、[設定]、[リモートファイルリスト]の下で、「常に隠しファイルを表示」ボックスをチェックします。

最新バージョンのFileZillaでは、「隠しファイルを表示」オプションが「サーバー」タブに移動されました。「隠しファイルを強制的に表示」を選択します。

コマンドラインの使用

ホスティングアカウントにシェル/SSHアクセスがある場合、chmodを使用してファイル権限を変更できます。これは経験豊富なユーザーにとって好ましい方法です。chmodを使用し始める前に、いくつかのチュートリアルを読んで、何が達成できるかを理解することをお勧めします。誤った権限を設定すると、サイトがオフラインになる可能性があるため、時間をかけてください。

• Unixの権限

``````bash
chmod -v 746 DIR
chmod -v 747 DIR
chmod -v 756 DIR
chmod -v 757 DIR
chmod -v 764 DIR
chmod -v 765 DIR
chmod -v 766 DIR
chmod -v 767 DIR
`

これらが書き込みを許可しない場合は、すべてを再度順番に試してください。ただし、今回は-vを-Rに置き換え、フォルダー内の各ファイルを再帰的に変更します。それでも書き込みできない場合は、777を試すことができます。

Chmodについて

chmodは、ファイルの「change mode」を意味するUnixコマンドです。-Rフラグは、wp-content内のすべてのファイルとディレクトリに変更を適用することを意味します。766は、ディレクトリを変更するモードであり、これはディレクトリがWordPressおよびシステム上のすべての他のユーザーによって読み取り可能で書き込み可能であることを意味します。最後に、変更するディレクトリの名前wp-contentがあります。766が機能しない場合は、777を試すことができ、これによりすべてのユーザー、グループ、およびプロセスによってすべてのファイルとフォルダーが読み取り可能、書き込み可能、実行可能になります。

Permalinksを使用している場合は、.htaccessの権限も変更して、WordPressが新しいページ、リダイレクト、カテゴリなどの設定を変更する際に更新できるようにする必要があります。mod_rewriteパーマリンクを使用している場合は、.htaccessファイルを更新する必要があります。

• 1. WordPressのメインディレクトリに移動します。
• 2. chmod -v 666 .htaccessに入ります。

注意: セキュリティの観点から、少しの保護でも、世界書き込み可能なディレクトリよりは好ましいです。744のような低い許可設定から始め、機能するまで上げていきます。必要な場合にのみ777を使用し、できれば一時的な期間のみ使用してください。

777の危険性

この権限の問題の核心は、サーバーの構成方法です。FTPまたはSSHを使用してサーバーにアクセスするために使用するユーザー名は、ページを提供するためにサーバーアプリケーション自体が使用するユーザー名ではない可能性が高いです。

7      7      7
user   group  world
r+w+x  r+w+x  r+w+x
4+2+1  4+2+1  4+2+1  = 777

しばしば、Apacheサーバーはwww-data、dhapache、またはnobodyユーザーアカウントによって「所有」されています。これらのアカウントは、非常に良い理由からサーバー上のファイルへのアクセスが制限されています。個人のファイルやフォルダーを、ユーザーアカウントによって所有されるものを世界書き込み可能に設定することで、実際にそれらを世界書き込み可能にしているのです。これにより、www-data、dhapache、nobodyユーザーがサーバーを実行し、ページを提供し、PHPインタープリターを実行する際に、あなたのユーザーアカウントのファイルに完全にアクセスできるようになります。

これにより、誰かがサーバー上の基本的に任意のプロセスをハイジャックすることによってあなたのファイルにアクセスする手段が提供され、他のユーザーも含まれます。したがって、マシン上の権限を変更することについて慎重に考えるべきです。私は767以上の権限が必要なものに出会ったことがないので、777を見たときはなぜそれが必要なのかを尋ねてください。

最悪の結果

フォルダーやファイルに777の権限を使用した結果、最悪の事態は、悪意のあるクラッカーやエンティティが巧妙なファイルをアップロードしたり、現在のファイルを変更してコードを実行させることができた場合、ブログに完全に制御されることです。データベース情報やパスワードも含まれます。

回避策を見つける

通常、印象的なWordPressプラグインによって提供される強化された機能をリスクを冒さずに利用することは非常に簡単です。プラグインの著者またはサーバーサポートに連絡して、回避策をリクエストしてください。

安全なファイル権限の見つけ方

.htaccessファイルは、サーバーを実行しているプロセスの所有者によってアクセスされるファイルの1つです。したがって、権限を低く設定しすぎると、サーバーがファイルにアクセスできなくなり、エラーが発生します。これが、最も安全な設定を見つける方法です。最初は制限を厳しくし、機能するまで権限を増やします。

権限設定の例

以下の例は、PHPスクリプトを実行するためにcgi-binディレクトリに配置されたカスタムコンパイルされたphp-cgiバイナリとカスタムphp.iniファイルを示しています。インタープリターとphp.iniファイルがウェブブラウザで直接アクセスされないように、.htaccessファイルで保護されています。

デフォルトの権限 (umask 022)

644 -rw-r--r--  /home/user/wp-config.php
644 -rw-r--r--  /home/user/cgi-bin/.htaccess
644 -rw-r--r--  /home/user/cgi-bin/php.ini
755 -rwxr-xr-x  /home/user/cgi-bin/php.cgi
755 -rwxr-xr-x  /home/user/cgi-bin/php5.cgi

セキュリティ権限

600 -rw-------  /home/user/wp-config.php
6**0**4 -rw----r--  /home/user/cgi-bin/.htaccess
6**00** -rw-------  /home/user/cgi-bin/php.ini
7**11** -rwx--x--x  /home/user/cgi-bin/php.cgi
**100** ---x------  /home/user/cgi-bin/php5.cgi

.htaccessの権限

644 > 604 – .htaccessファイルのグループ所有者に読み取り権限を与えるビットが削除されました。644は通常、.htaccessファイルに必要で推奨されます。

php.iniの権限

644 > 600 – 以前は、サーバーにアクセスできるすべてのグループとすべてのユーザーがphp.iniにアクセスできました。サイトからリクエストするだけでもアクセスできました。厄介なことに、php.iniファイルはphp.cgiによってのみ使用されるため、php.cgiプロセスがアクセスできることを確認する必要がありました。php.cgiは、両方のファイルを所有するのと同じユーザーとして実行されるため、その単一のユーザーだけがこのファイルにアクセスできるようになります。

php.cgiの権限

755 > 711 このファイルは、ホスティング会社が提供するmod_phpまたはデフォルトのバニラphpの代わりに使用されるコンパイルされたphp-cgiバイナリです。このファイルのデフォルトの権限は755です。

php5.cgiの権限

755 > 100 – ユーザーアカウントがphp cgiを実行するプロセスの所有者であるため、他のユーザーやグループはアクセスする必要がなく、実行アクセスを除いてすべてのアクセスを無効にします。これは興味深いことで、実際に機能します。ファイルを読み取ったり、ファイルに書き込んだりすることはできますが、このファイルに対して持っている唯一のアクセスはphpスクリプトを実行することです。そして、ファイルの所有者として、権限モードを元に戻すことができます。

$ cat: php5.cgi: Permission denied
./php5.cgi:  Welcome

SELinux

Security Enhanced linuxは、プロセスを特定のコンテキストにサンドボックス化するためのメカニズムを提供するカーネルセキュリティモジュールです。これは、ウェブページがオペレーティングシステムの他の部分で実行できるアクションを制限するのに特に役立ちます。セキュリティポリシーによって拒否されたアクションは、通常のファイル権限エラーと区別するのが難しいことがよくあります。

selinuxは通常、Redhatファミリーのディストリビューション（例：CentOS、Fedora、Scientific、Amazonなど）にインストールされます。

selinuxが問題かどうかを判断する方法

Debianベースのディストリビューションを使用している場合、問題ない可能性が高いです。

次のコマンドを実行します（rpmベースのシステムで）;

$ rpm -qa | grep selinux
selinux-policy-targeted-3.13.1-166.el7_4.7.noarch
selinux-policy-3.13.1-166.el7_4.7.noarch
libselinux-2.5-11.el7.x86_64
libselinux-python-2.5-11.el7.x86_64
libselinux-utils-2.5-11.el7.x86_64

権限の拒否の原因かどうかを確認するには:

$ getenforce
Enforcing

selinuxが引き起こす問題の1つは、wp-adminツールがURL書き換えに必要な.htaccessファイルを書き込むのをブロックすることです。この動作を検査するためのいくつかのコマンドがあります。

$ audit2allow -w -a
type=AVC msg=audit(1517275570.388:55362): avc:  denied  { write } for  pid=11831 comm="httpd" path="/var/www/example.org/.htaccess" dev="vda1" ino=67137959 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=file
   Was caused by:
   The boolean httpd_unified was set incorrectly.
   Description:
   Allow httpd to unified
   Allow access by executing:
   # setsebool -P httpd_unified 1

および

$ ausearch -m avc -c httpd
----
time->Tue Jan 30 01:30:31 2018
type=PROCTITLE msg=audit(1517275831.762:55364): proctitle=2F7573722F7362696E2F6874747064002D44464F524547524F554E44
type=SYSCALL msg=audit(1517275831.762:55364): arch=c000003e syscall=21 success=no exit=-13 a0=55b9c795d268 a1=2 a2=0 a3=1 items=0 ppid=11826 pid=11829 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1517275831.762:55364): avc:  denied  { write } for  pid=11829 comm="httpd" name="bioactivator.org" dev="vda1" ino=67137958 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=dir
----

問題の原因がselinuxであるかどうかを判断するために、一時的にselinuxを無効にすることができます。

$ setenforce
usage:  setenforce \[ Enforcing | Permissive | 1 | 0 \]

変更履歴

• 2022-09-11: ファイル権限の変更からの元のコンテンツ。