ファイルパーミッションの変更

コンピュータのファイルシステムでは、ディレクトリやファイルの一つ一つにパーミッションが設定されており、その読み込み、編集、アクセスを誰に (何に) 許可するかが指定されています。これは、WordPress が特定の関数を有効化するために wp-content ディレクトリ内のファイルに書き込むためのアクセスが必要になる場合があるので、重要です。

パーミッションモード

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

パーミッションモードは、以下の値を所有者 (user)、グループ (group)、他のユ―ザ (other) に割り当てて算出します。算出は、以下の図のように行えます。

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

パーミッションモードの例

値	文字列	説明
0477	-r–rwxrwx	所有者に read (4)、グループと他のユーザに read、write、execute (7) を許可
0677	-rw-rwxrwx	所有者に read、write (6)、グループと他のユーザに read、write、execute (7) を許可
0444	-r–r–r–	所有者、グループ、他のユーザに read (4) を許可
0666	-rw-rw-rw-	所有者、グループ、他のユーザに read、write (6) を許可
0400	-r——–	所有者に read (4) を許可、グループと他のユーザは権限なし (0)
0600	-rw——-	所有者に read、write (6) を許可、グループと他のユーザは権限なし (0)
0470	-r–rwx—	所有者に read (4)、グループに read、write、execute (7) を許可、他のユーザは権限なし (0)
0407	-r—–rwx	所有者に read (4) を許可、グループは権限なし (0)、他のユーザに read、write、execute (7) を許可
0670	-rw-rwx—	所有者に read、write (6)、グループに read、write、execute (7)を許可、他のユーザは権限なし (0)
0607	-rw—-rwx	所有者に read、write (6) を許可、グループは権限なし (0)、他のユーザに read、write、execute (7) を許可

WordPress のパーミッションスキーム

パーミッションはホストごとに異なるため、このガイドでは一般的な原則のみを詳しく説明します。すべてのケースをカバーできるわけではありません。このガイドは、標準な設定で稼働しているサーバーに適用されます (「suexec」メソッドを使用した共有ホスティングについては、以下を参照してください)。

一般的に、すべてのファイルの所有権はWebサーバー上のユーザー (ftp) アカウントに設定され、またそのアカウントから書き込み可能である必要があります。共有ホストでは、ファイルの所有権をWebサーバープロセス自体にすべきではありません (所有権がwww、apache、nobody ユーザーなどにはならないということです)。

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

WordPress でのパーミッションは、基本的にほぼすべてのユーザで共通の設定になりますが、使用するサーバ、ユーザの行うインストールのタイプ、およびインストール時のシステム全体の umask 値などにより異なる場合があります。

注記: 経験豊富なユーザーが WordPress をインストールしてくれた場合、ファイルのパーミッションを変更する必要はないでしょう。パーミッションエラーの問題が発生しない限り、あるいはそうしたい場合を除き、おそらくこれをいじる必要はありません。

注記: WordPress を自分でインストールした場合、ファイルのパーミッションを変更する必要がある場合があります。いくつかのファイルやディレクトリは、より厳しいパーミッションで「強化」されるべきです。特に、wp-config.php ファイルはそうです。このファイルは初期状態では644のパーミッションで作成されており、このままにしておくのは危険です。Security and Hardening を参照してください。

一般的に、WordPress のすべてのコアファイルは、あなたのユーザーアカウント (または異なる場合は httpd アカウント) だけが書き込み可能であるべきです。(時には、インストールを管理するために複数の ftp アカウントが使用され、すべての ftp ユーザーが知られていて信頼できる場合、すなわち、共有ホストではない場合、group writable を割り当てることが適切かもしれません。詳しくはサーバー管理者に聞いてください)。ただし、mod_rewrite Permalinks やその他の .htaccess 機能を利用する場合は、WordPress が /.htaccess ファイルにも書き込めることを確認する必要があります。

組み込みのテーマエディターを使用する場合は、すべてのファイルをグループで書き込み可能にする必要があります。ファイルパーミッションを変更する前に、この機能を使用してみてください。動作するはずです。 (これは、異なるユーザーが WordPress パッケージとプラグインまたはテーマをアップロードした場合に当てはまります。これは、管理者によってインストールされたプラグインとテーマの問題ではありません。異なる ftp ユーザーグループでファイルをアップロードする場合、書き込み可能なグループが必要です。共有ホスティングでは、グループが信頼できるユーザー専用であることを確認してください… apache ユーザーはグループに含まれるべきではなく、ファイルを所有するべきではありません。)

一部のプラグインでは /wp-content/ フォルダーを書き込み可能にする必要がありますが、そのような場合はインストール中に通知されます。場合によっては、755 のアクセス許可を割り当てる必要があります。/wp-content/cache/ およびおそらく /wp-content/uploads/ ( MultiSite /wp-content/blogs.dir/ についてもこれを行う必要がある場合があります)

/wp-content/ の下の追加のディレクトリは、それらを必要とするプラグイン / テーマごとに文書化する必要があります。パーミッションは異なります。

/
|- 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 モジュール、シンプルだが効果的。
mpm-itk, apache モジュール。
mod_fcgid, Apache モジュールで、より広範な設定を持つ FastCGI サーバー。
PHP-FPM, Apache と Nginx で使用する、共有 OPCode を持つ代替 FastCGI サーバー。

FTP クライアントの使用

FTP programs (“クライアント”) を使用すると、リモートホスト上のファイルとディレクトリのアクセス許可を設定できます。この機能は、プログラムメニューで chmodまたは パーミッションの設定 と呼ばれることがよくあります。

In WordPress install, おそらく変更したくなる2つのファイルは、インデックスページと、レイアウトを制御する css です。ここでは、index.phpを変更する方法を説明します – プロセスはどのファイルでも同じです。

下のスクリーンショットで、最後の列をご覧ください – これはパーミッションを示しています。少しわかりにくいですが、とりあえず文字の並びを確認してください。

初期のパーミッション

「index.php」を右クリックし、「ファイルのパーミッション」を選択します
ポップアップ画面が表示されます。

チェックボックスは気にしないでください。「Numeric value:」を削除して、必要な数字(この場合は「666」)を入力するだけです。そして、「OK」をクリックします。

Permissions have been altered.

Don’t worry about the check boxes. Just delete the ‘Numeric value:’ and enter the number you need – in this case it’s 666. Then click OK.

Permissions have been altered.

これで、ファイルのパーミッションが変更されたことが確認できます。

隠しファイルの表示

デフォルトでは、ほとんどの FTP クライアント, (FileZilla を含む)がファイル名がピリオド (.) で始まるファイルを非表示にしています。しかし、パーミッションを変更するために隠しファイルを表示する必要があるかもしれません。例えば、パーマリンクを制御するファイルである「.htaccess」ファイルを作成する必要がある場合は、書き込み可能な状態にする必要があります。

FileZilla では、隠しファイルを表示する場合、メニューバーから [サーバ] → [強制的に隠しファイルを表示] にチェックを入れる必要があります。画面表示が更新され、常に隠しファイルが表示されるようになります。

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

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

コマンドラインを使って

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

Unix Permissions

すべて wp-content ディレクトリ内のファイルを2つの手順で書き込み可能にできますが、すべてのファイルとフォルダーを書き込み可能にする前に、まず次のことを行う必要があります。ディレクトリだけを変更するなど、より安全な代替手段を試してください。最初にこれらのコマンドをそれぞれ試してみてください。うまくいかない場合は、再帰的に実行してください。これにより、テーマの画像ファイルも書き込み可能になります。 DIR を書き込みたいフォルダに置き換えます

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を試すことができます。これにより、すべてのユーザー、グループ、およびプロセスがすべてのファイルとフォルダーを読み取り、書き込み、および実行できるようになります。

パーマリンクを使用している場合、新しいページ、リダイレクト、カテゴリなどを追加するなどの設定を変更したときにWordPressが更新できるようにするために、 .htaccess&nbspのパーミッションを変更しなければなりませんが、これは mod_rewrite Permalinks が使われているときに .htaccess ファイルの更新を必要とします…。

WordPress のメインディレクトリに移動します
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 のユーザーアカウントによって「所有」されています。これらのアカウントは、サーバー上のファイルへのアクセスが制限されていますが、これには十分な理由があります。ユーザーアカウントが所有する個人的なファイルやフォルダをWorld-Writableに設定することで、文字通り World Writable にすることができるのです。これで、www-data、dhapache、nobody の各ユーザーは、サーバーの運営、ページの提供、php インタプリタの実行など、ユーザーアカウントのファイルへのフルアクセスを持つことになります。

これは、サーバー上の基本的にどのプロセスでも乗っ取ることによって、誰かがあなたのファイルにアクセスできるようにする手段を提供するものであり、これにはマシン上の他のユーザーも含まれます。ですから、自分のマシンのパーミッションを変更する際には、慎重に考える必要があります。私はこれまで767以上のパーミッションが必要なものに出会ったことはありません。

最悪の結果

フォルダーまたはファイルに777の許可を使用することで起こりうる最悪の事態は、悪意のあるクラッカーやエンティティが悪質なファイルをアップロードしたり、現在のファイルを改変してコードを実行できる場合、彼らがあなたのブログを完全に制御でき、データベース情報やパスワードを含むあらゆる情報にアクセスできることです。

回避策を見つける

WordPress プラグインを使うことで、比較的簡単にセキュリティの強化を行い、リスクを回避することできます。プラグイン製作者、またはサーバのサポートサービスにコンタクトを取り、回避策を講じてください。

安全なファイルパーミッションを探す

.htaccess ファイルは、サーバプロセスの所有者がアクセスするファイルのひとつです。パーミッションを制限しすぎた場合、サーバがファイルにアクセスできなくなり、エラーの原因となります。しかし適切なパーミッション設定を得るときには、まず限定的な設定から始め、動作が確認できるレベルまで開放していく手順を踏みます。

パーミッションの設定例

以下の例では、phpスクリプトを実行するために cgi-bin ディレクトリに配置されたカスタムコンパイルされた php-cgi バイナリおよびカスタム php.ini ファイルがあります。.htaccess ファイルによって、インタプリタと php.ini ファイルへの直接的なブラウザーからのアクセスが防止されています。

デフォルトパーミッション (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
604 -rw----r--  /home/user/cgi-bin/.htaccess
600 -rw-------  /home/user/cgi-bin/php.ini
711 -rwx--x--x  /home/user/cgi-bin/php.cgi
100 ---x------  /home/user/cgi-bin/php5.cgi

.htaccess のパーミッション

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

php.ini のパーミッション

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

php.cgi のパーミッション

755 > 711 ここでは、プロバイダから標準で提供される vanilla PHP や mod_php の代わりに、カスタムコンパイルされた php.cgi バイナリを使用しています。通常は 755 が設定されています。

php5.cgi のパーミッション

755 > 100 – ユーザーアカウントが php cgi を実行しているプロセスの所有者であるという設定のため、他のユーザーやグループはアクセスを必要としないので、実行アクセス以外のすべてのアクセスを無効にします。これは、本当に動くので面白いです。ファイルの読み込み、ファイルへの書き込みなどを試すことができますが、このファイルへのアクセスは、phpスクリプトを実行することだけです。そして、ファイルの所有者であるあなたは、いつでもパーミッションモードを再び変更することができます。

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

SELinux

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

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

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

Debian ベースのディストリビューションを使用している場合は、おそらく問題ありません。

以下のコマンドを実行します (on rpm based systems);

# 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 が引き起こす問題のひとつは、URL の書き換えに必要な「.htaccess」ファイルの書き出しから wp-admin ツールがブロックされることです。この挙動を検査するためのコマンドがいくつかあります

# 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を無効にして、問題の原因かどうかを判断することができます ;

# setenforce
usage:  setenforce [ Enforcing | Permissive | 1 | 0 ]

チェンジログ

2022-09-11: Changing File Permissions からのオリジナルコンテンツです。

原文

カテゴリー

翻訳・改善にご協力ください