ArchWiki - 利用者の投稿記録 [ja]

USB インストールメディア

2026-04-25T16:34:08Z

Oech3: catのspliceサポートについて追加/* 基本的なコマンドラインユーティリティを使う */

[[Category:Arch の入手とインストール]]
[[de:Installation von einem USB-Stick]]
[[en:USB flash installation medium]]
[[es:USB flash installation medium]]
[[fr:USB flash installation medium]]
[[pt:USB flash installation medium]]
[[ru:USB flash installation medium]]
[[tr:USB flash installation medium]]
[[zh-hans:USB flash installation medium]]
{{Related articles start}}
{{Related|光学ディスクドライブ}}
{{Related|Archiso}}
{{Related|マルチブート USB ドライブ}}
{{Related articles end}}
このページでは Arch Linux のインストーラーを USB ドライブ (別名: ''"フラッシュドライブ", "USB スティック", "USB キー"'' など) に書き込む様々な方法を記述します。[[Wikipedia:ja:Live USB|Live USB]] システムは Arch Linux のインストールやシステムメンテナンス、システムの回復に使用できます。{{ic|/}} に [[Overlayfs]] を使うので、コンピュータを一度シャットダウンすると、すべての変更は破棄されます。

USB ドライブからの Arch Linux のフルインストールをしたい場合 (すなわち永続的な設定もする場合) は、[[リムーバブルメディアに Arch Linux をインストール]] を参照してください。ブータブル Arch Linux USB スティックをレスキュー USB として使いたい場合は、[[chroot]] を参照してください。

以下の手順に進む前に、https://archlinux.org/download/ から ISO をダウンロードし、[[インストールガイド#署名の検証|ファイルの整合性を検証]]してください。

== ISO をそのまま使う (BIOS と UEFI) ==

{{Warning|以下は USB フラッシュドライブ上の全データを不可逆的に削除するため、以下のことを行う前にフラッシュドライブ上に重要なファイルが残っていないことを確認してください。}}

{{Note|ISO を USB フラッシュドライブや SD カードではなく、ハードディスクドライブやソリッドステートドライブに書き込みたい場合、ドライブの論理セクタサイズが 2048 バイト ([[Wikipedia:ja:ISO 9660|ISO 9660]] のセクタサイズ) 以下であり、かつそのサイズにアライメントされていることを確認してください。これはつまり、この ISO はこの方法を使って 4Kn [[Advanced Format]] ドライブに書き込むことはできないことを意味します。}}

=== GNU/Linux で ===

==== 基本的なコマンドラインユーティリティを使う ====

以下のツールは {{Pkg|coreutils}} ({{Pkg|base}} [[メタパッケージ]]によってインストールされます) であるため、この方法はシンプルで汎用性があり、おすすめできます。

{{ic|ls -l /dev/disk/by-id/usb-*}} を実行して USB ドライブの名前を調べ、{{ic|lsblk}} を実行してそのドライブがマウント'''されていない'''ことを確認してください。

以下のコマンドを実行する際、{{ic|/dev/disk/by-id/usb-''My_flash_drive''}} の部分はあなたのドライブに合わせて変更してください (例: {{ic|/dev/disk/by-id/usb-Kingston_DataTraveler_2.0_408D5C1654FDB471E98BED5C-0:0}})。(パーティション番号を'''付けないでください'''。つまり、{{ic|/dev/disk/by-id/usb-Kingston_DataTraveler_2.0_408D5C1654FDB471E98BED5C-0:0'''-part1'''}} や {{ic|/dev/sdb'''1'''}} のようにしては'''いけません'''):

* {{man|1|cat}} を使う: {{bc|# cat ''path/to/''archlinux-''version''-x86_64.iso > /dev/disk/by-id/usb-''My_flash_drive''}}
* {{man|1|cp}} を使う: {{bc|# cp ''path/to/''archlinux-''version''-x86_64.iso /dev/disk/by-id/usb-''My_flash_drive''}}
* [[dd]] を使う: {{bc|1=# dd bs=4M if=''path/to/''archlinux-''version''-x86_64.iso of=/dev/disk/by-id/usb-''My_flash_drive'' conv=fsync oflag=direct status=progress}}
* [[tee]] を使う: {{bc|# tee < ''path/to/''archlinux-''version''-x86_64.iso > /dev/disk/by-id/usb-''My_flash_drive''}}
* {{Pkg|pv}} を使う: {{bc|# pv ''path/to/''archlinux-''version''-x86_64.iso > /dev/disk/by-id/usb-''My_flash_drive''}}

これらのツールの比較と観点、そしてなぜ ''dd'' があまり使われないのかについては、[https://unix.stackexchange.com/questions/224277/is-it-better-to-use-cat-dd-pv-or-another-procedure-to-copy-a-cd-dvd/224314#224314] と [https://www.vidarholen.net/contents/blog/?p=479] を見てください。また、''cat'' (9.10から {{man|2|splice}}サポートあり) は''dd''よりも高速であることに注意してください。

{{Tip|
* コマンドを実行した後に {{ic|sync}} を root 権限で実行することで、ドライブを抜く前にバッファが完全に書き込まれることを保証できます。
* USB の Arch ISO の UEFI バージョンがハングする場合やロードできない場合、メディアの作成手順を同じ USB ドライブで複数回繰り返してみてください。これでうまく行かない場合、マザーボードのファームウェアをアップデートしてみると良いかもしれません。}}

{{Note|Arch ISO イメージを書き込んだ USB ドライブを空の使用可能なストレージデバイスに戻すには、その USB ドライブを[[パーティショニング|再パーティショニング]]したり[[フォーマット|再フォーマット]]したりする前に、{{ic|wipefs --all /dev/disk/by-id/usb-''My_flash_drive''}} を root として実行して、ISO 9660 ファイルシステムシグネチャを削除する必要があります。}}

==== KDE ISO Image Writer を使う ====

KDE ISO Image Writer は {{Pkg|isoimagewriter}} でインストールできます。このツールは USB ドライブを自動で検出します。ISO ファイルは手動で選択する必要があります。''.sig'' ファイルで署名することが推奨されますが、"create" をクリックすればスキップすることもできます。

==== GNOME Disk Utility を使う ====

GNOME を使っている Linux ディストリビューションなら {{Pkg|nautilus}} と {{Pkg|gnome-disk-utility}} を使うことで簡単にライブ CD が作成できます。{{ic|.iso}} ファイルを右クリックして、 "Open With Disk Image Writer" を選択してください。GNOME Disk Utility が開いたら、"Destination" ドロップダウンメニューからフラッシュドライブを選択して "Start Restoring" をクリックしてください。

==== MultiWriter を使う ====

{{pkg|gnome-multi-writer}} は、ISO ファイルを複数の USB デバイスに一度に書き込める、シンプルな [[GTK]]3 ベースのグラフィカルツールです。

==== Kindd を使う ====

[https://github.com/LinArcX/Kindd Kindd] は、dd の Qt ベースグラフィカルフロントエンドです。{{AUR|kindd}} で利用できます。

==== Popsicle を使う ====

[https://github.com/pop-os/popsicle Popsicle] は、ISO ファイルを複数の USB デバイスに並列で書き込むためのツールで、PopOS 開発チームにより作成されました。Rust で記述されており、GTK を使用します。{{AUR|popsicle}} で利用可能です。

==== SUSE Studio ImageWriter を使う ====

[https://github.com/openSUSE/imagewriter SUSE Studio ImageWriter] は、OpenSUSE 開発チームにより作成された、Qt ベースのツールです。{{AUR|imagewriter}} で利用可能です。

==== xorriso-dd-target を使う ====

({{Pkg|libisoburn}} の) [https://dev.lovelyhq.com/libburnia/libisoburn/raw/master/xorriso-dd-target/xorriso-dd-target xorriso-dd-target] は、間違ったストレージデバイスへの上書きリスクの軽減を試みるシェルスクリプトです。最も安全なモードは {{ic|-plug_test}} という名前です。例えば、[[sudo]] を使って root に昇格できる通常ユーザとしてこのツールを使うには:

$ xorriso-dd-target -with_sudo -plug_test -DO_WRITE -image_file archlinux-''version''-x86_64.iso

詳細は {{man|1|xorriso-dd-target}} を見てください。

==== USBImager を使う ====

[https://gitlab.com/bztsrc/usbimager/ USBImager] は、圧縮ディスクイメージを USB ドライブに書き込んだり、検証したり、バックアップを作成したりする、マルチプラットフォームのグラフィカルアプリケーションです。{{AUR|usbimager}} で利用できます。

=== Windows で ===

==== KDE ISO Image Writer を使う ====

KDE ISO Image Writer は [https://apps.kde.org/isoimagewriter/ isoimagewriter] で ''.exe'' ファイルとしてダウンロードできます。このツールは USB ドライブを自動で検出します。ISO ファイルは手動で選択する必要があります。''.sig'' ファイルで署名することが推奨されますが、"create" をクリックすればスキップすることもできます。

==== win32diskimager を使う ====

[https://sourceforge.net/projects/win32diskimager/ win32diskimager] は、Windows からイメージを USB スティックや SD/CF カードに書き込むためのグラフィカルツールです。ISO イメージを選択して、書き込み先の USB ドライブ文字を選択し (先にフォーマットする必要があります)、''Write'' をクリックしてください。

==== USBwriter を使う ====

Linux の {{ic|dd}} と同じように簡単に使うことができます。Arch Linux の ISO をダウンロードして、管理者権限で [https://sourceforge.net/p/usbwriter/wiki/Documentation/ USBwriter] ユーティリティを使って USB フラッシュメモリに書き込むだけです。

==== USBImager を使う ====

[https://gitlab.com/bztsrc/usbimager/ USBImager] は、圧縮ディスクイメージを USB ドライブに書き込んだり、検証したり、バックアップを作成したりする、マルチプラットフォームのグラフィカルアプリケーションです。

==== Rufus を使う ====

[https://rufus.akeo.ie/ Rufus] は多目的の USB ISO 書き込みツールです。このツールはグラフィカルな UI を提供し、ドライブが正しくフォーマットされていなくても書き込むことができます。

単に Arch Linux の ISO と、ブータブルな Arch Linux を作成したい USB ドライブを選択し、''START'' をクリックするだけです。

{{Note|デフォルトの ISO イメージモードを使って作成した USB ドライブが正しく起動しない場合、'''DD イメージモード'''を代わりに使用する必要があります。モードを切り替えるには、''パーティション構成'' ドロップダウンメニューから ''GPT'' を選択してください。''START'' をクリックしたあとに、モード選択のダイアログが表示されるので、''DD イメージモード''を選択してください。}}

{{Tip|[https://github.com/pbatard/rufus/issues/691 永続的なデータ保存のための追加パーティション]を追加するには、保存領域のサイズを選択するためのスライダーを使ってください。永続的なパーティションの機能を使う際は、''パーティション構成''ドロップダウンメニューで ''MBR'' を選択して、''ターゲットシステム''で ''BIOS または UEFI'' を選択してください。さもないと、ドライブは BIOS と UEFI の両方で使用できなくなります。}}

==== Cygwin を使う ====

[https://www.cygwin.com/ Cygwin] をインストールするときに {{ic|dd}} パッケージを選択してください。

イメージファイルをホームディレクトリに置いてください:

C:\cygwin\home\''User''\

管理者として cygwin を実行します (cygwin からのハードウェアへのアクセスが必要です)。次のコマンドで USB ドライブに書き込みます:

dd if=archlinux-''version''-x86_64.iso of=\\.\''x'': bs=4M

{{ic|archlinux-''version''-x86_64.iso}} の部分は {{ic|cygwin}} ディレクトリ内にある iso イメージファイルへのパスです。{{ic|\\.\''x'':}} の部分は USB フラッシュドライブで、{{ic|''x''}} は windows が決めた文字になります、例: {{ic|\\.\d:}}。

cygwin 6.0 では正しいパーティションを見つけてください:

cat /proc/partitions

そして出力を見て ISO イメージを焼きこみます。例:

dd if=archlinux-''version''-x86_64.iso of=/dev/sdb bs=4M

==== dd for Windows を使う ====

Windows に対応した GPL ライセンスの dd が http://www.chrysocome.net/dd から利用できます。Cygwin と比べてダウンロード容量は少なくてすみます。使用方法は、上の Cygwin の方法に従って下さい。

初めに dd for Windows の最新バージョンをダウンロードしてください。ダウンロードが完了したら、圧縮ファイルを {{ic|Downloads}} ディレクトリかどこかに展開してください。

そして、管理者として ''Command Prompt'' を立ち上げてください。次に、{{ic|Downloads}} ディレクトリにディレクトリを変更 ({{ic|cd}}) してください。

Arch Linux の ISO は ''dd'' の実行可能ファイルがある場所と同じフォルダに置いた方が便利です、どこか他のところに ISO を置いた場合はフルパスを記述する必要があります。

使用するコマンドは以下のようになります:

# dd if=archlinux-''version''-x86_64.iso od=\\.\''x'': bs=4M

{{Note|Windows のドライブ文字はパーティションに紐付けられています。ディスク全体を選択できるようにするため、''dd for Windows'' には {{ic|od}} パラメータが存在し、上記のコマンドで使用しています。このパラメータが使えるのは ''dd for Windows'' だけであり、他の ''dd'' 実装では存在しないので注意してください。}}

==== flashnul を使う ====

[https://github.com/amarao/flashnul/blob/master/README.md flashnul] はフラッシュメモリ(USB-Flash, IDE-Flash, SecureDigital, MMC, MemoryStick, SmartMedia, XD, CompactFlash など)の機能を検証したりメンテナンスしたりするユーティリティです。

コマンドプロンプトから flashnul を {{ic|-p}} 付きで実行してください。そして、どのデバイスインデックスが、対象の USB ドライブであるかを判断してください。例:

{{hc|C:\>flashnul -p|
Avaible physical drives:
Avaible logical disks:
C:\
D:\
E:\
}}

正しいデバイスを見つけたら、デバイスにイメージを書き込むことができます。{{ic|-L}} とデバイスインデックス、イメージへのパスを付けて flashnul を実行してください。例:

C:\>flashnul '''E:''' -L ''path\to\''archlinux-''version''-x86_64.iso

データを書き込んでいいと確信しているのであれば yes と入力してください。そして、書き込みが終わるまで少し待ってください。アクセス拒否のエラーが発生した場合、開いているエクスプローラーのウインドウをすべて閉じてください。

{{Note|コマンドプロンプトは管理者として開いてください。さもないと、flashnul はフラッシュメモリをブロックデバイスとして開くことができず、Windows が提供するドライブハンドルを通してしか書き込むことができません。}}

=== macOS で ===

==== macOS dd を使う ====

まず USB ドライブを確認する必要があります。{{ic|/Applications/Utilities/Terminal}} を開いて以下のコマンドでストレージデバイスを全て確認できます:

$ diskutil list

USB デバイスは {{ic|/dev/disk2 (external, physical)}} のように表示されます。名前や容量から消去したいデバイスであることを確認できたら、識別子を使って下のコマンドを実行してください ({{ic|/dev/disk''X''}} を確認できた識別子に置き換えてください)。

通常 masOS では USB デバイスは自動的にマウントされるため、{{ic|dd}} を使ってブロック単位で書き込む前にアンマウントする必要があります (エジェクトではありません)。ターミナルで、以下を実行:

$ diskutil unmountDisk /dev/disk''X''

それから ISO イメージファイルをデバイスにコピーしてください:

{{Note|
* BSD から継承した {{ic|dd}} (macOS のデフォルトの {{ic|dd}} も含む) は、小文字の {{ic|m}} サフィックスを使います。これは、この記事の他の部分で使用されている GNU {{ic|dd}} とは異なります。
* {{ic|disk}} の前に {{ic|r}} を付けると raw モードになり、転送をより速くすることができます。
* 新しいバージョンの macOS では、dd コマンドは {{ic|1=status=progress}} をサポートしており、進捗状況を表示させることができます。以下のように手動で進捗状況を表示させることも可能です。
}}

# dd if=''path/to''/archlinux-''version''-x86_64.iso of=/dev/'''r'''disk''X'' bs=1m

このコマンドは何も出力せずに動きます。進捗を表示させるには、{{ic|Ctrl+t}} を押して SIGINFO を送信してください。{{ic|disk''X''}} には {{ic|s1}} サフィックスを含めるべきではないことに注意してください。さもないと、その USB デバイスは UEFI モードでしか起動できず、レガシーモードでは起動できません。完了すると macOS が ''セットしたディスクは、このコンピュータで読み取れないディスクでした。'' とエラーを吐くことがあります。''無視'' を選択してください。これで USB デバイスはブータブルになります。

==== USBImager を使う ====

[https://gitlab.com/bztsrc/usbimager/ USBImager] は、圧縮ディスクイメージを USB ドライブに書き込んだり、検証したり、バックアップを作成したりする、マルチプラットフォームのグラフィカルアプリケーションです。

=== Android で ===

==== EtchDroid を使う ====

[https://etchdroid.depau.eu/ EtchDroid] は、Android のための OS イメージ書き込みツールです。Android 5 以降、root 権限が無くとも動作します。問題が生じた場合は、上流の [https://github.com/EtchDroid/EtchDroid/issues/ GitHub] を確認してください。

Arch Linux インストーラーを作成するには、ISO イメージを Android デバイス上にダウンロードしてください。(必要であれば USB-OTG アダプタを使って) USB ドライブを Android デバイスに挿入してください。EtchDroid を開き、''Flash raw image'' を選択し、Arch ISO を選択し、USB ドライブを選択してください。USB API の使用許可を付与し、確認してください。

イメージの書き込み中は携帯を机の上に置いておいてください: 多くの USB-OTG アダプタは少しぐらつくので、間違えて抜けてしまうかもしれません。

== 手動フォーマットを使う ==

=== BIOS と UEFI ===

==== GNU/Linux で ====

この方法は {{ic|dd}} でイメージを直接書き込むより少し複雑ですが、ドライブをデータストレージとして使える状態のままにすることができます (既存の[[パーティショニング|パーティション分割されたデバイス]]の中のパーティションに ISO をインストールします)。

{{Note|ここでは、対象のパーティションを {{ic|/dev/disk/by-id/usb-''My_flash_drive''-part''n''}} と表記します。{{ic|''My_flash_drive''}} と {{ic|''n''}} の部分はあなたのシステムに合わせて置き換えてください。}}

* {{ic|/dev/disk/by-id/usb-''My_flash_drive''}} 上に[[パーティショニング#パーティションテーブル|パーティションテーブル]]を作成してください (まだ作成していないのであれば)。
* デバイス上にパーティションを作成してください(まだ作成していないのであれば)。パーティション {{ic|/dev/disk/by-id/usb-''My_flash_drive''-part''n''}} は [[FAT32]] にフォーマットされていなければなりません。
* USB フラッシュデバイスにあるその FAT32 ファイルシステムをマウントしてください。そして、ISO イメージの内容をそこへ[[アーカイブと圧縮|展開]]してください。例えば:

# mount /dev/disk/by-id/usb-''My_flash_drive''-part''n'' /mnt
# bsdtar -x -f archlinux-''version''-x86_64.iso -C /mnt

BIOS ブートを行うには、ファイルが存在しているボリュームを指定する必要があります。デフォルトでは、UUID {{ic|''YYYY-mm-dd-HH-MM-SS''-00}} (適切な UTC のリリース日と時間) が使用されます。{{ic|/mnt/boot/syslinux/archiso_sys-linux.cfg}} 内の {{ic|1=archisodevice=}} パラメータはデバイスの[[永続的なブロックデバイスの命名|永続的なデバイス識別子]]に置き換えてください。例えば: {{ic|1=archisodevice=UUID=''YOUR-UUID''}}。

{{Note|{{ic|archisolabel}} や {{ic|archisodevice}} を間違えると、作成したメディアから起動できなくなります。}}

BIOS システム用の [[Syslinux]] のファイルはすでに {{ic|/mnt/boot/syslinux}} へコピーされています。
FAT ファイルシステムを[[ファイルシステム#ファイルシステムのアンマウント|アンマウント]]し、{{Pkg|syslinux}} と {{Pkg|mtools}} を[[インストール]]して、パーティションを起動可能にするために以下のコマンドを実行してください:

# umount /mnt
# syslinux --directory boot/syslinux --install /dev/disk/by-id/usb-''My_flash_drive''-part''n''
# dd bs=440 count=1 conv=notrunc if=/usr/lib/syslinux/bios/mbr.bin of=/dev/disk/by-id/usb-''My_flash_drive''

{{Note|
* {{ic|/dev/disk/by-id/usb-''My_flash_drive''}} に [[GPT|GUID パーティションテーブル]]が存在する場合、{{ic|mbr.bin}} は {{ic|gptmbr.bin}} に置き換えてください。詳細は [[Syslinux#手動]] を見てください。
* [[MBR]] パーティションテーブルの場合は、"boot" フラグを設定する必要があります。詳細は [[Syslinux#MBR パーティションテーブル]] を見てください。
}}

==== Windows で ====

{{Note|
* UEFI ブータブル USB を作成するのに '''Bootable USB Creator ユーティリティ'''を使ってはいけません。手動フォーマットの場合、USB ドライブに ISO を dd するのに ''dd for Windows'' を使わないで下さい。
* 下のコマンド内の '''X:''' は Windows での USB フラッシュドライブを意味しています。
* Windows はパスを分けるのにバックスラッシュ {{ic|\}} を使っているので、下のコマンドでもバックスラッシュを使っています。
* 全てのコマンドは Windows のコマンドプロンプトで'''管理者として'''実行する必要があります。
* {{ic|>}} は Windows のコマンドプロンプトを示しています。
}}

* [https://rufus.ie/ Rufus USB partitioner] を使って USB ドライブをパーティショニングし、フォーマットしてください。パーティション構成オプションは '''MBR for BIOS and UEFI''' を、ファイルシステムは '''FAT32''' を選んで下さい。"Create a bootable disk using ISO image" と "Create extended label and icon files" オプションのチェックを外して下さい。
* '''Volume Label''' は好きに設定してください。このステップは公式 ISO ([[Archiso]]) に必要です。このステップは、前の "パーティショニングとフォーマット" のステップで Rufus を使用することでも可能です。
* ISO を (ZIP アーカイブの解凍と同じように) USB フラッシュドライブに [https://www.7-zip.org/ 7-Zip] を使って展開してください。
* {{ic|''X'':\boot\syslinux\archiso_sys-linux.cfg}} を編集して、{{ic|1=archisodevice=UUID=''YYYY-mm-dd-HH-MM-SS''-00}} の部分を全て {{ic|1=archisodevice=LABEl=''YOUR_LABEL''}} に置き換えてください。{{ic|''YOUR_LABEL''}} の部分は、先ほど設定したボリュームラベルです。
* https://www.kernel.org/pub/linux/utils/boot/syslinux/ から最新の公式 syslinux 6.xx バイナリ (zip ファイル) をダウンロードして展開してください。Syslinux のバージョンは ISO イメージで使われているバージョンと合わせてください。
* 以下のコマンドを実行してください (管理者として実行した Windows のコマンドプロンプトで実行):

> cd bios\
> for /r %Y in (*.c32) do copy "%Y" "''X'':\boot\syslinux\" /y
> copy mbr\*.bin ''X'':\boot\syslinux\ /y

* 以下を実行して Syslinux を USB にインストールしてください (64ビット版 Windows では {{ic|win64\syslinux64.exe}} を使ってください):

> cd bios\
> win32\syslinux.exe -d /boot/syslinux -i -a -m ''X'':

{{Note|
* ただファイルをコピーしただけでは起動可能なデバイスにはなりません。最後のコマンドは、Syslinux のファイルを USB のパーティションの VBR にインストールし、そのパーティションを MBR パーティションテーブル上で "active/boot" に設定し、MBR ブートコードを USB デバイスに書き込みます。
* {{ic|-d}} スイッチには Unix 環境と同じようにスラッシュで区切るパスを使います。
}}

=== BIOS のみ ===

==== GNU/Linux で ====

===== USB-ZIP ドライブの作成 =====

一部の古い BIOS 環境では、USB-ZIP ドライブからの起動しかサポートされていないことがあります。この方法では USB ハードドライブからの起動を可能とします。

* {{Pkg|syslinux}} と {{Pkg|mtools}} を[[インストール]]してください。
* {{ic|ls /dev/disk/by-id/usb-*}} で USB ドライブを確認します。
* {{ic|mkdiskimage -4 /dev/disk/by-id/usb-''My_flash_drive'' 0 64 32}} を実行してください。しばらく時間がかかります。

ここからは手動フォーマットの手順に従ってください。ZIP ドライブのためパーティションは {{ic|/dev/disk/by-id/usb-''My_flash_drive''-part4}} になります。

{{Note|ドライブを FAT32 でフォーマットしてはいけません。FAT16 のままにしてください。}}

=== UEFI のみ ===

UEFI のみでブートさせる場合、FAT でフォーマットされた USB フラッシュドライブへ ISO のコンテンツを展開するだけで十分です。

ドライブ上に EFI システムパーティションを作成する必要はありません。すべての UEFI (実装) は、USB フラッシュドライブ上の任意の FAT ボリュームから起動できるからです。最も互換性の高いセットアップは、{{ic|0c}} "W95 FAT32 (LBA)" タイプの単一のアクティブ (ブータブル) プライマリパーティションを持つ MBR パーティションテーブルを使用することです。[https://lists.gnu.org/archive/html/grub-devel/2019-05/msg00063.html]

{{Tip|セキュアブートがカスタムの鍵で設定されている場合、[[セキュアブート#公式の ISO をカスタムの鍵で署名する]] を参照して、どのファイルを署名する必要があるかを確認してください。}}

==== GNU/Linux で ====

この方法では、ファイルを ISO イメージから USB フラッシュドライブへ展開します。

* もしまだなら、[[パーティショニング#パーティションテーブル|パーティションテーブル]]を {{ic|/dev/disk/by-id/usb-''My_flash_drive''}} に作成し、[[パーティション]] をデバイス上の ({{ic|/dev/disk/by-id/usb-''My_flash_drive''-part''n''}}) に作成してください。
* もしまだなら、そのパーティションを [[FAT32]] にフォーマットしてください: {{bc|# mkfs.fat -F 32 /dev/disk/by-id/usb-''My_flash_drive''-part''n''}}
* そのファイルシステムを[[マウント]]してください: {{bc|# mount /dev/disk/by-id/usb-''My_flash_drive''-part''n'' /mnt}}
* そのマウントしたファイルシステムに ISO イメージを展開してください: {{bc|1=# bsdtar -x -f archlinux-''version''-x86_64.iso -C /mnt}}
# ファイルシステムを[[アンマウント]]してください。

==== Windows で ====

この方法では、ファイルを ISO イメージから USB フラッシュドライブへコピーします。

# USB フラッシュドライブをパーティショニングし、FAT32 にフォーマットしてください。
# {{ic|archlinux-''version''-x86_64.iso}} を右クリックし、''マウント''を選択してください。
# 新しく作成した DVD ドライブに移動し、すべてのファイルとフォルダを USB フラッシュドライブにコピーしてください。
# コピーが終わったら、DVD ドライブを右クリックして、''取り出し''を選択してください。
# USB フラッシュドライブを取り出してください。

==== macOS で ====

''DiskImageMounter'' と ''Disk Utility'' のどちらも isohybrid ISO をマウントすることはできません。しかし、macOS には ''libarchive'' が同梱されているため、''bsdtar'' を使って ISO をフラッシュドライブに展開することができます。

# まだ行っていないならば、''Disk Utility'' を使って USB フラッシュドライブをパーティショニングし、そのパーティションを FAT32 でフォーマットしてください。
# そのボリュームをマウントしてください。
# ''Terminal'' アプリケーションを開き、''bsdtar'' を使って ISO イメージを先のマウント済みのファイルシステムに展開してください: {{bc|$ bsdtar -x -f archlinux-''version''-x86_64.iso -C /Volumes/''your-flash-drive''}}
# 終わったら、USB フラッシュドライブをアンマウントし、取り出してください。

== マルチブート USB ドライブを使う ==

この方法では archiso を含む複数の ISO をひとつの USB デバイスから起動できるようにします。他の方法よりも既存の USB ドライブを新しい ISO にアップデートするのが簡単です。[[マルチブート USB ドライブ]]を参照してください。

=== ventoy を使う ===

[[Ventoy]] は、ISO/WIM/IMG/VHD(x)/EFI ファイルの起動可能な USB ドライブを作成するためのオープンソースなツールです。ventoy では、ディスクを何回もフォーマットする必要はありません。ただ ISO/WIM/IMG/VHD(x)EFI ファイルを USB ドライブにコピーするだけで、それらを直接起動できます。一度に多くのファイルをコピーでき、ventoy は起動するファイルを選択するブートメニューを提供します。{{AUR|ventoy-bin}} で利用可能です。

=== Windows で ===

==== RAM からインストールメディアをロードする ====

[[Syslinux]] と [[RAM ディスク]] ([https://wiki.syslinux.org/wiki/index.php/MEMDISK MEMDISK]) を使って RAM から ISO イメージをロードする方法です。システムメモリ上で全てを実行するので、それに見合った RAM が積まれていなければなりません。MEMDISK を使って Arch Linux をインストールするために必要な RAM の最低量は 500 MB から 1 GB です。

Arch Linux と MEMDISK のシステム要件については[[インストールガイド]]と [http://www.etherboot.org/wiki/bootingmemdisk#preliminaries こちら] に詳しく載っています。[https://bbs.archlinux.org/viewtopic.php?id=135266 フォーラムスレッド] も参照してください。

{{Tip|一度ロードが完了しグラフィカルメニューが表示されたら、USB スティックを抜いてもオーケーです。そのままスティックを他のマシンで使ってもかまいません。また、起動に使った USB スティックに Arch をインストールすることもできます。}}

===== USB フラッシュドライブの準備 =====

USB スティックを FAT32 でフォーマットし、新しくフォーマットしたドライブに以下のフォルダを作ります:
* {{ic|Boot}}
** {{ic|Boot/ISOs}}
** {{ic|Boot/Settings}}

===== 必要なファイルを USB フラッシュドライブにコピー =====

ブートしたい ISO を {{ic|Boot/ISOs}} フォルダにコピーしてください。その後、[https://www.kernel.org/pub/linux/utils/boot/syslinux/ ここ] から {{pkg|syslinux}} の最新版を取ってきて以下のファイルをコピーしてください。
* {{ic|./win32/syslinux.exe}} をデスクトップかダウンロードフォルダに置いて下さい。
* {{ic|./memdisk/memdisk}} を USB フラッシュドライブ上の {{ic|Settings}} フォルダに置きます。

===== 設定ファイルの作成 =====

必要なファイルをコピーしたら、{{ic|/boot/Settings}} フォルダの中に {{ic|syslinux.cfg}} ファイルを作ります:
{{Warning|{{ic|INITRD}} 行には、{{ic|ISOs}} フォルダにコピーした ISO ファイルの名前を使って下さい。}}
{{hc|/Boot/Settings/syslinux.cfg|2=
DEFAULT arch_iso

LABEL arch_iso
MENU LABEL Arch Setup
LINUX memdisk
INITRD /Boot/ISOs/archlinux-2017.04.01-x86_64.iso
APPEND iso}}
Syslinux について詳しくは [[Syslinux]] を参照してください。

===== 最後の手順 =====

最後に {{ic|syslinux.exe}} と同じところに {{ic|*.bat}} を作り、実行します (Vista や Windows 7 を使っているときは"管理者として実行"します):

{{hc|C:\Documents and Settings\username\Desktop\install.bat|
@echo off
syslinux.exe -m -a -d /Boot/Settings X:
}}

== 推奨されない方法 ==

{{Warning|以下の方法は推奨されません。}}

=== etcher を使う ===

etcher にはアナリティクスとファーストパーティの広告があります。[https://github.com/balena-io/etcher/issues/2057]、[https://github.com/balena-io/etcher/blob/37769efbeda0abe7993d95e2b2aea2f461edd307/lib/gui/app/pages/main/MainPage.tsx#L151]、[https://github.com/balena-io/etcher/blob/37769efbeda0abe7993d95e2b2aea2f461edd307/docs/MAINTAINERS.md#publishing] を見てください。

=== Universal USB Installer を使う ===

* ダウンロードページには偽の ''Download'' ボタンがあり、マルウェアが含まれているかもしれません。
* Universal USB Installer は ISO をそのまま書き込みません。そのため、syslinux バージョンの不一致により BIOS ブートが壊れます。[https://bbs.archlinux.org/viewtopic.php?pid=1344629] を見てください。
* Arch Linux のインストールイメージのブートローダは {{ic|ARCH_''YYYYXX''}} というラベルのボリュームに ISO の内容が存在することを期待します。Universal USB Installer はファイルシステムのラベルをアップデートせず、ブートローダの設定も修正しません。

=== UNetbootin を使う ===

* UNetbootin は ISO をそのまま書き込みません。そのため、syslinux バージョンの不一致により BIOS ブートが壊れます。
* Arch Linux のインストールイメージのブートローダは {{ic|ARCH_''YYYYXX''}} というラベルのボリュームに ISO の内容が存在することを期待します。UNetbootin はファイルシステムのラベルをアップデートせず、ブートローダの設定も修正しません。

== トラブルシューティング ==

=== デバイスが表示されない ===

{{ic|/dev/disk/by-label/ARCH_XXXXXX}} がマウントされず "device did not show up after 30 seconds" エラーが表示される場合は、USB メディアの名前を {{ic|ARCH_XXXXXX}} に変えてみて下さい (例: {{ic|archlinux-2021.02.01-x86_64.iso}} の場合は {{ic|ARCH_202102}})。

=== ループバックデバイスのセットアップに失敗する: No such file or directory ===

{{ic|losetup: /run/archiso/bootmnt/arch/x86_64/airootfs.sfs: failed to set up loop devices: No such file or directory}} というエラーが発生する場合、USB 2.0 のポートを使ってみてください。例えば、一部の USB 3.0 ポートは USB ハブを介して動作しません。

=== 他のエラー ===

その他のエラーが発生する場合、他の USB デバイスを使用してみてください。そうすることですべての問題が解決したという事例が複数あります。

== 参照 ==

* [[Gentoo:LiveUSB/Guide]]
* [[Fedora:How to create and use Live USB]]
* [https://en.opensuse.org/SDB:Live_USB_stick openSUSE wiki - SDB:ライブ USB メモリ]

{{TranslationStatus|USB flash installation medium|2024-04-04|803451}}

セキュリティ

2025-12-28T16:19:02Z

Oech3: /* SUID ファイルと SGID ファイル */

[[Category:セキュリティ]]
[[Category:ファイルシステム]]
[[Category:ネットワーク]]
[[en:Security]]
[[fa:امنیت]]
[[ru:Security]]
[[zh-hans:Security]]
{{Related articles start}}
{{Related|PAM}}
{{Related|ケイパビリティ}}
{{Related|アプリケーション一覧/セキュリティ}}
{{Related|:カテゴリ:セキュリティ}}
{{Related articles end}}
この記事には、Arch Linux システムを[[Wikipedia:ja:ハードニング|ハードニング]]するための推奨事項とベストプラクティスを並べています。

== 概念 ==

* システムのセキュリティを厳重にしすぎると、使い物にならなくなることもある。セキュリティと利便性のバランスを取ることが重要だ。重要なのは、安全で ''かつ'' 使いやすいシステムを作ること。
* 最大の脅威は常にユーザー自身である。
* [[Wikipedia:ja:最小権限の原則|最小権限の原則]]: システムの各部分は、必要最小限の権限のみを持つべきであり、それ以上のアクセスは許可されるべきではない。
* 多層防御 (Defense in Depth): セキュリティは独立した複数の層で成り立つべきである。一つの層が突破されても、次の層が攻撃を食い止める仕組みが必要です。
* 少しだけ疑い深くなること。常に警戒すること。うますぎる話には注意すべきだ。それが本当である可能性は低いと思うこと。
* システムを100%安全にする方法はただ一つ。それはネットワークから切り離し、電源を切り、金庫に入れ、コンクリートで固め、二度と使用しないこと。
* 失敗を想定せよ。セキュリティが破られたときに備え、あらかじめ対応策を準備しておくこと。

==パスワード==
パスワードは安全な linux システムのかぎです。パスワードは[[ユーザーとグループ|ユーザーアカウント]], [[ディスク暗号化|暗号化されたファイルシステム]], [[SSH 鍵|SSH]]/[[GPG]] 鍵などを守ります。コンピュータを使用する人を信頼するのに使う主要な手段なので、安全なパスワードを選んでそれを保護するというのがセキュリティの大部分と言っても過言ではありません。

=== 安全なパスワードの選び方 ===

パスワードは、個人情報などから簡単に推測されないよう十分に複雑であり、また、ソーシャルエンジニアリングやブルートフォース攻撃などの手法で[[Wikipedia:Password cracking|クラック]]されないようにする必要があります。強力なパスワードの基本原則は、''長さ''と''ランダム性''に基づいています。暗号学では、パスワードの品質はその[[Wikipedia:Password strength#Entropy as a measure of password strength|エントロピー]]によって測られます。

安全でないパスワードには、以下のようなものが含まれます。また、以下のようなものを元に変更や置き換えを行った場合も同様に危険です。

* 個人を特定できる情報(例:ペットの名前、生年月日、市外局番、好きなビデオゲームなど)
* 単純な文字の置き換えを行った単語(例:{{ic|k1araj0hns0n}})最新の辞書攻撃ではこれらも簡単に解析可能
* 既存の "単語" や一般的な文字列の前後に数字・記号・文字を追加したもの(例:{{ic|DG091101%}})
* 一般的なフレーズや辞書にある単語を短く組み合わせたもの(例:{{ic|photocopyhauntbranchexpose}})文字の置き換えを行っても(例:{{ic|Ph0toc0pyh4uN7br@nch3xp*se}})、安全とは限らない(ただし、後述の "Diceware" を利用した場合は例外あり)
* [[Wikipedia:List of the most common passwords|最も一般的なパスワード]]のいずれか

最も安全なパスワードは、十分に長く(長いほど良い)ランダムなソースから生成されたものです。長いパスワードを使用することが重要です。[https://www.theregister.com/2019/02/14/password_length 弱いハッシュアルゴリズムを使用すると、8文字のパスワードハッシュはわずか数時間で解読可能] です。

{{Pkg|pwgen}} や {{AUR|apg}} のようなツールを使用すると、ランダムなパスワードを生成できます。しかし、これらのパスワードは覚えにくいことがあります。覚えやすくするための1つの方法は、長いパスワードを生成し、最初は最低限の安全な文字数だけを暗記し、完全な文字列を一時的に書き留めることです。時間をかけて入力する文字数を増やしていけば、最終的にはパスワードが筋肉の記憶として定着し、完全に覚える必要がなくなります。この方法は難易度が高いものの、辞書攻撃や "知的" ブルートフォース攻撃(単語の組み合わせや文字の置き換えを考慮する攻撃)に対して非常に強力です。

パスワード管理とは別に、{{Pkg|keepassxc}} はパスワード/パスフレーズの生成機能を提供します。GUI でカスタマイズ可能なパスワード生成機能があり、辞書ベースのパスフレーズもサポートされています。

パスワードを覚えるための1つの方法として、**記憶術(ニーモニック)**を利用することが挙げられます。
例えば、"the girl is walking down the rainy street" というフレーズは、以下のようなパスワードに変換できます。簡単な例:{{ic|t6!WdtR5}} より複雑な例:{{ic|t&6!RrlW@dtR,57}}
この方法は、パスワードを覚えやすくすることができますが、英単語の最初の文字には偏りがあることに注意が必要です([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]] を参照)

また、ランダムに生成したパスワードを紙に書いて安全な場所に保管するという方法も有効です。例えば、財布、カバン、金庫などに保管するのがよいでしょう。ほとんどの人は、デジタルセキュリティよりも物理的な貴重品の保護に関しては理解しやすいため、この方法は現実的です。

さらに、記憶術とランダム生成を組み合わせる方法も効果的です。例えば、長くランダムに生成したパスワードを[[パスワードマネージャ]]に保存し、それをマスターパスワードで管理する方法です。マスターパスワードは記憶し、絶対に保存しないようにします。この方法では、パスワードマネージャーがインストールされているシステムでのみパスワードにアクセスできるようになり、状況によっては不便にもなりますが、セキュリティ強化の側面もあります。一部のパスワードマネージャーにはスマートフォンアプリもあり、手入力が必要な場合にパスワードを表示することができます(この場合、完全にランダムなものではなく、タイピングしやすいが安全なパスワードを使うことも検討できます)ただし、マスターパスワードを忘れるとすべてのパスワードにアクセスできなくなるため、単一障害点になり得ることに注意が必要です。
また、一部のパスワードマネージャーは、保存するパスワードを暗号化するのではなく、マスターパスワードとサービス名から計算する方式を採用しており、新しいシステムでもデータ同期なしで使用できます。

覚えやすく、それでいて強力なパスワードの作成方法として、無関係な単語を複数組み合わせたパスフレーズを使うという方法もあります。この方法では、十分に長いフレーズを使用することで、辞書単語を使うことによるエントロピーの損失を補うことができます。この手法のエントロピーのトレードオフについては、[https://xkcd.com/936/ xkcdのコミック] に示されています。この方法の安全性は、選択可能な単語の集合が大きい(数千語以上)ことと、5〜7語以上のランダムな単語を選択することによって保証されます。攻撃者が選択可能な単語の集合と、使用する単語数を知っていたとしても、(選択可能な単語数) の (選択する単語数) 乗の通りのパスフレーズが生成可能であり、安全性が確保されます。詳細については [https://www.rempe.us/diceware/ Diceware] を参照してください。

さらに詳しい情報については、[https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] や [[Wikipedia:Password strength]] も参考になります。

=== パスワードの管理 ===

強力なパスワードを選んだら、それを安全に保管することが重要です。[[Wikipedia:Keylogger|キーロガー]] (ソフトウェアおよびハードウェア)、スクリーンロガー、[[Wikipedia:Social engineering (security)|ソーシャルエンジニアリング]]、[[Wikipedia:Shoulder surfing (computer security)|ショルダースーフィング]]に注意し、パスワードの使い回しを避けて、セキュリティの低いサーバーから不要な情報が漏れないようにしましょう。[[アプリケーション一覧/セキュリティ#パスワードマネージャ|パスワードマネージャ]]を使用すると、大量の複雑なパスワードを管理できます。パスワードマネージャーからアプリケーションに保存されたパスワードをコピー&ペーストして使用する場合は、毎回コピーした内容をクリアし、ログに保存されないようにしてください(例:プレーンテキストのターミナルコマンドにペーストしないようにし、{{ic|.bash_history}} などのファイルに保存されないようにします)ブラウザ拡張として実装されたパスワードマネージャは、[https://www.spookjs.com サイドチャネル攻撃]に脆弱である可能性があります。これを回避するためには、別のアプリケーションとして実行されるパスワードマネージャーを使用することが推奨されます。

原則として、強力なパスワードを覚えにくいからといって、セキュリティが低いパスワードを選んではいけません。パスワードはバランスを取る必要があります。強力なマスターパスワードと鍵で守られた暗号化された安全なパスワードデータベースを持つ方が、多くの似たような弱いパスワードを使うよりも優れています。パスワードを紙に書いて保管することも、[https://www.schneier.com/blog/archives/2005/06/write_down_your.html] で示されているように、ソフトウェアの脆弱性を避けつつ物理的なセキュリティを確保できるため、非常に効果的です。

パスフレーズの強度のもう一つの側面は、それが他の場所から簡単に回復できないことです。

ディスク暗号化のパスフレーズをログインパスワードと同じに使用する場合(例えば、ログイン時に暗号化されたパーティションやフォルダを自動マウントする場合)、{{ic|/etc/shadow}} が暗号化されたパーティションに保存されるか、または強力な鍵導出関数 (i.e. yescrypt/argon2 や sha512 を PBKDF2 で使用、md5 や低回数の PBKDF2 は避ける) を使用して保存されたパスワードハッシュを使うようにしてください (詳細については [[SHA hashes#SHA パスワードハッシュ|SHA パスワードハッシュ]] を参照してください)

{{Tip|Arch Linux は [https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのハッシュアルゴリズム]を yescrypt に変更しました。もしデフォルトをカスタマイズしていない場合は、{{ic|passwd}} を実行してパスワード変更を行うなどして下さい。}}

パスワードデータベースをバックアップする場合、そのコピーが他のパスフレーズで保護されていないことを確認してください。例えば、暗号化されたドライブや認証されたリモートストレージサービスなどです。もしそのような保護が施されている場合、必要なときにアクセスできなくなります。役立つ方法としては、データベースがバックアップされているドライブやアカウントをマスターパスワードの簡単な暗号学的ハッシュで保護することです。バックアップ場所のリストを保持してください。もしもマスターパスワードが漏洩したと疑われる場合、その場所すべてでパスワードを即座に変更し、マスターパスワードから導出された鍵で保護されたすべてのバックアップと場所も変更する必要があります。

データベースをセキュアにバージョン管理するのは非常に複雑な場合があります。もしその方法を選択するなら、すべてのデータベースバージョンでマスターパスワードを更新する手段を持っている必要があります。マスターパスワードが漏洩したときにそれを即座に知るのは難しいことがあります。他の人がパスワードを発見するリスクを減らすために、定期的にパスワードを変更することを選ぶかもしれません。もしデータベースのコピーの管理が失われたと感じた場合、そのコピーがブルートフォース攻撃によってマスターパスワードを解読される前に、そのデータベース内のすべてのパスワードを変更する必要があります。

=== パスワードのハッシュ ===

ハッシュは一方向の関数です。つまり、入力を計算せずにそのハッシュを解読することは不可能になるように設計されています (例:MD5、SHA)

パスワードハッシュ関数は、ユーザー入力 (パスワード) を計算せずに解読することが不可能になるように設計されています(例:bcrypt)[[Wikipedia:Key derivation function|鍵導出関数]] (KDF; 例:yescrypt、scrypt、PBKDF2) は、入力 (マスターキーやパスワード) から秘密鍵 (例:AESキー、パスワードハッシュ) を導出するために設計された暗号アルゴリズムです。したがって、KDF はパスワードハッシュ関数としても使用できる複数の用途に対応します。

デフォルトでは、Arch Linux はユーザーパスワードをルート専用の読み取り可能な {{ic|/etc/shadow}} ファイルにハッシュ化して保存します。これは、他のユーザーのパラメータが保存される世界に読み取り可能な {{ic|/etc/passwd}} ファイルから分離されています。詳細は [[ユーザーとグループ#ユーザーデータベース]] を参照してください。また、[[#root の制限]] も参照してください。

パスワードは '''passwd''' コマンドを使用して設定され、このコマンドはシステムの暗号化関数でパスワードを[[Wikipedia:Key stretching|ストレッチ]]し、その後 {{ic|/etc/shadow}} に保存されます。パスワードは[[Wikipedia:Salt (cryptography)|ソルト]]も施され、[[Wikipedia:Rainbow table|レインボーテーブル]]攻撃に対して防御されます。詳細は[https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils Linux でパスワードがどのように保存されているか(Shadow ユーティリティを使ったハッシュの理解)]を参照してください。

パスワードハッシュは定義されたフォーマットに従って保存されるため、新たな ''passwd'' コマンドの実行に対してメソッドとパラメータを設定することができます。したがって、{{ic|/etc/shadow}} ファイルに保存された個々のハッシュは、システムでサポートされているハッシュ関数の異種混合になる可能性があります。

フォーマット、ハッシュメソッド、およびパラメータに関する詳細は、{{man|5|crypt}} を参照してください。

{{ic|/etc/login.defs}} ファイルでは、[https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのパスワードハッシュメソッド]{{ic|ENCRYPT_METHOD YESCRYPT}} とそのパラメータ {{ic|YESCRYPT_COST_FACTOR}} が設定されます。

例えば、デフォルトの {{ic|YESCRYPT_COST_FACTOR}} パラメータを増加させると、パスワードからハッシュを導き出すために必要な計算時間が対数的に増加します。これは、システムがユーザーのログインを認証する際や、第三者がパスワードの秘密を取得しようとする場合にも適用されます。

これに対して、SHA-512 ハッシュ関数の計算時間は、パラメータにより線形的に影響されます。以前の Arch のデフォルトについては [[SHA パスワードハッシュ]] を参照してください。yescrypt アルゴリズムは内部で SHA-256、HMAC、およびPBKDF2 を使用してパスワードハッシュを計算することに注意してください。主な理由は、これらの広く使用され、テストされた関数の良い特性を組み合わせ、攻撃への耐性を強化することです。例えば、SHA の多用途性が原因で、この関数のハードウェアサポートが提供され、SHA ハッシュの計算性能が著しく向上したため、パスワードハッシュ関数としての使用が次第に時代遅れになりつつあります。

=== pam_cracklib を用いた強力なパスワードの強制 ===

''pam_pwquality'' は、[[Wikipedia:Dictionary attack|辞書攻撃]]に対する保護を提供し、システム全体で強制できるパスワードポリシーを設定するのに役立ちます。これは ''pam_cracklib'' をベースにしており、そのオプションとの後方互換性があります。

{{Pkg|libpwquality}} パッケージを[[インストール]]してください。

{{Warning|デフォルトでは、''root'' アカウントはこのポリシーの影響を受けません。}}

{{Note|
* ''root'' アカウントを使用すると、設定したパスワードポリシーをバイパスするユーザーパスワードを設定できます。これは一時的なパスワードを設定する際に便利です。
* 現在のパスワードに関するセキュリティガイドライン(例:NISTなど)では、特別な文字を強制することは推奨されていません。なぜなら、それらはしばしば予測可能な変更を引き起こすだけだからです。
}}

例えば、以下のポリシーを強制したい場合:

* エラーが発生した場合にパスワードを2回入力する (retry オプション)
* 最小長10文字 (minlen オプション)
* 新しいパスワードを入力する際、古いパスワードとは少なくとも6文字異なること (difok オプション)
* 最低1桁の数字 (dcredit オプション)
* 最低1つの大文字 (ucredit オプション)
* 最低1つの小文字 (lcredit オプション)
* 最低1つのその他の文字 (ocredit オプション)
* "myservice" および "mydomain" という単語を含めない
* root にもこのポリシーを強制する

{{ic|/etc/pam.d/passwd}}ファイルを以下のように編集します:

{{bc|1=
#%PAM-1.0
password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root
password required pam_unix.so use_authtok sha512 shadow
}}

{{ic|password required pam_unix.so use_authtok}} は、''pam_unix'' モジュールに対してパスワードの入力を促さず、代わりに ''pam_pwquality'' で提供されたものを使用するように指示します。

詳細については、{{man|8|pam_pwquality}} および {{man|8|pam_unix}} のマニュアルページを参照してください。

== CPU ==

=== マイクロコード ===

CPU のマイクロコードに対する重要なセキュリティ更新プログラムをインストールする方法については、[[マイクロコード]] を参照してください。

=== ハードウェアの脆弱性 ===

CPU の中には、ハードウェアの脆弱性を含んでいるものがあります。これらの脆弱性の一覧と、特定の使用シナリオに合わせてこれらの脆弱性を緩和するためにカーネルをカスタマイズするのに役立つ緩和策の選択ガイドについては、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/ kernel documentation on hardware vulnerabilities] を参照してください。

既知の脆弱性の影響を受けているかどうかを確認するには、以下を実行してください。

$ grep -r . /sys/devices/system/cpu/vulnerabilities/

ほとんどの場合、カーネルとマイクロコードを更新することで、脆弱性を軽減することができます。

==== 同時マルチスレッディング (ハイパースレッディング) ====

[https://ja.wikipedia.org/wiki/%E5%90%8C%E6%99%82%E3%83%9E%E3%83%AB%E3%83%81%E3%82%B9%E3%83%AC%E3%83%83%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0 同時マルチスレッディング]] (SMT) は、インテル CPU のハイパースレッディングとも呼ばれ、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html L1 Terminal Fault] および [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html Microarchitectural Data Sampling] 脆弱性の原因となる可能性のあるハードウェア機能です。Linux カーネルとマイクロコードのアップデートには、既知の脆弱性に対する緩和策が含まれていますが、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html#virtualization-with-untrusted-guests 信頼できない仮想化ゲストが存在する場合、特定の CPU で SMT を無効にしたほうが良い場合があります。]

SMT は、システムのファームウェアで無効にできることがよくあります。詳細については、マザーボードまたはシステムのドキュメントを参照してください。また、以下の [[カーネルパラメータ]] を追加することで、カーネルで SMT を無効にすることができます。

l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force

== メモリ ==

===ハード化された malloc ===

[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened_malloc}}, {{AUR|hardened-malloc-git}}) は [https://ja.wikipedia.org/wiki/GNU_C%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA glibc] の malloc() をハード化した代替品です。元々は Android の [[Wikipedia:Bionic (software)|Bionic]] と [https://ja.wikipedia.org/wiki/Musl musl] に組み込むために開発されましたが、 x86_64 アーキテクチャの標準 Linux ディストリビューションのサポートにも組み込みました。

hardened_malloc はまだ glibc に統合されていませんが(支援とプルリクエストは歓迎します)、LD_PRELOAD と一緒に簡単に使用することができます。これまでのテストでは、 {{ic|/etc/ld.so.preload}} でグローバルに有効にすると、一握りのアプリケーションにしか問題を起こしません。例えば、{{ic|getrandom}} が標準のホワイトリストにないため、{{ic|seccomp}} 環境フラグが無効でないと {{ic|man}} は正常に動作しませんが、これはシステムコールを追加して再構築すれば簡単に修正可能です。hardened_malloc は性能上のコストがあるので、どの実装を使うかは攻撃対象領域と性能上の必要性に基づいてケースバイケースで決めるとよいでしょう。

スタンドアロンで試すには、hardened-malloc-preload ラッパースクリプトを使用するか、適切なプリロード値でアプリケーションを手動で開始します。

LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox

[[Firejail]] の正しい使い方は、その wiki ページにあります。また、hardened_malloc の設定可能なビルドオプションは、githubレポで見つけることができます。

== ストレージ ==

===ディスク暗号化===

[[ディスク暗号化]]、特に [[#パスワード|強力なパスフレーズ]] を使用したフルディスク暗号化は、物理的な回復からデータを守る唯一の方法です。これにより、コンピュータの電源がオフになっている場合や、対象のディスクがアンマウントされている場合にデータの機密性が保たれます。

ただし、コンピュータの電源が入っており、ドライブがマウントされている場合、そのデータは暗号化されていないドライブと同様に脆弱です。そのため、データパーティションがもう必要なくなったら、できるだけ早くアンマウントすることが最良の実践です。

また、[[Trusted Platform Module#LUKS による保存データの暗号化|TPMにキーを保存してドライブを暗号化]] することもできますが、過去に [https://tpm.fail 脆弱性] があり、キーは [https://pulsesecurity.co.nz/articles/TPM-sniffing TPMバススニッフィング攻撃] によって抽出される可能性があります。

[[dm-crypt]] のような特定のプログラムは、ユーザーが仮想ボリュームとしてループファイルを暗号化できるようにします。これは、システムの特定の部分だけを安全に保護する必要がある場合、フルディスク暗号化の合理的な代替手段です。

[[ディスク暗号化]] の記事で比較されているブロックデバイスやファイルシステムベースの暗号化方法は、物理メディア上のデータ保護には有効ですが、リモートシステム(例えば [[保存データ暗号化#クラウドストレージの最適化|クラウドストレージ]])に保存されたデータを保護するためには使用できません。そのため、個々のファイル暗号化が役立つ場合もあります。

ファイルを暗号化するためのいくつかの方法は次の通りです:

* 一部の [[アーカイブと圧縮|アーカイブおよび圧縮]] ツールは基本的な暗号化も提供します。例としては、[[7-Zip]] ({{ic|-p}} フラグ)、{{Pkg|zip}} ({{ic|-e}}フラグ) があります。これらのツールはクロスプラットフォームの互換性のためにカスタムアルゴリズムを使用している場合があるため、特別な注意を払って使用するべきです。[https://math.ucr.edu/~mike/zipattacks.pdf]
* [[GnuPG]] を使用してファイルを [[GnuPG#Encrypt and decrypt|暗号化]] できます。
* {{Pkg|age}} は、シンプルで使いやすいファイル暗号化ツールです。複数の受信者をサポートしており、SSH キーを使用した暗号化もサポートしているため、安全なファイル共有に役立ちます。

=== ファイルシステム ===

現在カーネルは {{ic|fs.protected_hardlinks}} や {{ic|fs.protected_symlinks}} sysctl スイッチが有効になっていればハードリンクやシンボリックリンクに関するセキュリティの問題を解決するので、world-writable なディレクトリを分離させるセキュリティ的な利点はもはや存在しません。

それでもディスク容量が消耗したときのダメージを低減させる荒っぽい方法として world-writable なディレクトリを含むパーティションが分割されることがあります。しかしながら、サービスを落とすには {{ic|/var}} や {{ic|/tmp}} などのパーティションを一杯にするだけで十分です。この問題の対処についてはもっと柔軟性のある方法が存在します (クォータなど)、またファイルシステムによっては関連する機能を持っていることがあります (btrfs はサブボリュームにクォータを設定できます)。

====マウントオプション====

最小特権の原則に従い、ファイルシステムは可能な限り制限の厳しいマウントオプションを使用してマウントするべきです(機能を失わない範囲で)

関連するマウントオプションは以下の通りです:

* {{ic|nodev}}: ファイルシステム上のキャラクタデバイスやブロックデバイスを解釈しない。
* {{ic|nosuid}}: set-user-identifier や set-group-identifier ビットを無効にする。
* {{ic|noexec}}: マウントされたファイルシステム上のバイナリを直接実行できないようにする。
** {{ic|/home}} に {{ic|noexec}} を設定すると、実行可能なスクリプトが禁止され、[[Wine]]、[[Steam]]、PyCharm、[[.NET]] などが動作しなくなります。
*** Wine は Windows バイナリの実行に {{ic|exec}} フラグを必要としません。ただし、Wine 自体を {{ic|/home}} にインストールする場合は必要です。
*** [[Steam]] を動作させるには、{{ic|/home/user/.local/share/Steam}} を [[fstab]] で {{ic|exec}} としてマウントできます。以下の設定を追加してください: {{bc|/home/user/.local/share/Steam /home/user/.local/share/Steam none defaults,bind,user,exec,nofail 0 0}}
** 一部のパッケージ(例:{{Pkg|nvidia-dkms}} のビルド)では、{{ic|/var}} に {{ic|exec}} が必要な場合があります。

データ用のファイルシステムは、常に {{ic|nodev}}、{{ic|nosuid}}、{{ic|noexec}} を指定してマウントするべきです。

マウントを検討すべきファイルシステム:

* {{ic|/var}}
* {{ic|/home}}
* {{ic|/dev/shm}}
* {{ic|/tmp}}
* {{ic|/boot}}

{{Tip|[[systemd#GPT パーティションの自動マウント|GPT パーティションの自動マウント]] を使用する場合、ESP および XBOOTLDR パーティションは [https://github.com/systemd/systemd-stable/commit/49804cfb71d3a79f433096e4cfb5616980171336 常に {{ic|noexec,nosuid,nodev}} で強化] されます。}}

==== スナップショット ====

ファイルシステムのスナップショットを利用する場合(例えば [[Btrfs]]、[[LVM]]、[[ZFS]] など)、スナップショットがユーザーが削除したと期待している機密情報を保持する可能性があることを理解することが重要です。特に、[[Snapper]] のような自動スナップショットツールを設定している場合、定期的またはシステムイベントに応じてスナップショットが作成されるため、この問題が発生しやすくなります。

以下は、{{ic|/home/}} 内の機密情報がスナップショットに残存する例です:

* 削除されたファイルやディレクトリ: ファイルシステム上から削除されたとしても、古いスナップショット内には残存している可能性があります。これは通常想定される動作ですが、{{ic|.local/share/Trash/}}、{{ic|.history}} などのファイルやディレクトリを保持する必要があるかどうかを検討すべきです。
* 一時ファイルやキャッシュ: アプリケーションによって生成された一時ファイルやキャッシュデータもスナップショットに含まれる可能性があります。例えば、暗号化されたディレクトリ内のファイルを開くと、サムネイル({{ic|.cache/thumbnails}})や作業用のコピーが作成され、それらがスナップショットに含まれる可能性があります。同様に、ブラウザの履歴({{ic|.mozilla/}}、{{ic|.config/chromium/}} など)も、削除される前にスナップショットに記録されている場合があります。

対応可能であれば、これらのディレクトリをスナップショットの対象から完全に除外することを検討してください。例えば、[[Btrfs]] を使用している場合、{{ic|.cache/}}、{{ic|.config/}}、{{ic|.local/}}、{{ic|.var/}} など、用途に応じたディレクトリをサブボリュームとして作成することで、スナップショットの影響を受けにくくできます。

{{Note|{{ic|.local/share/Trash}} を別のサブボリュームに移動すると、場合によっては [[GNOME/Files]] などでゴミ箱の機能が正常に動作しなくなる可能性があります。}}

===ファイルシステムのパーミッション===

デフォルトの [[パーミッション]] では、ほとんどのファイルが読み取り可能になっていますが、これを変更することで、{{ic|http}} ユーザーや {{ic|nobody}} ユーザーなどの非 root アカウントに侵入した攻撃者から貴重な情報を隠すことができます。[[chmod]] を使用して、グループやその他のユーザーからすべてのアクセス権を削除できます。

# chmod go-r ''path_to_hide''

{{Warning|この設定を広範囲に適用しないでください。1つの設定ファイルごとに適用し、非表示にする価値があるか、プログラムの動作に影響しないかを確認してください。グループが必要な場合は、{{ic|g}} をコマンドから削除するか、既に実行してしまった場合は {{ic|chmod g+r path}} で再度許可を追加する必要があるかもしれません。}}

考慮すべきパスの例:

* {{ic|/boot}}: [[パーティショニング#/boot|ブートディレクトリ]]、[[vmlinuz]] や [[initramfs]] image、または [[ユニファイドカーネルイメージ]] が含まれる場合があります。なお、[[systemd# GPT パーティションの自動マウント]] を使用する場合、デフォルトで安全なパーミッションが適用されます。
* {{ic|/etc/nftables.conf}}: [[nftables]] の設定ファイル({{Pkg|nftables}} および {{Pkg|iptables-nft}} に適用)
* {{ic|/etc/iptables}}: レガシーな [[iptables]] の設定ファイル({{Pkg|iptables}} に適用)

また、新しく作成されるファイルのセキュリティを向上させるために、デフォルトの [[umask]] 値 {{ic|0022}} を変更することも可能です。[https://apps.nsa.gov/iaarchive/library/ia-guidance/security-configuration/operating-systems/guide-to-the-secure-configuration-of-red-hat-enterprise.cfm NSA RHEL5 Security Guide] では最大限のセキュリティを確保するために、{{ic|0077}} を推奨しており、これにより所有者以外のユーザーが新しいファイルを読み取れなくなります。変更方法については [[Umask#マスクの値を設定]] を参照してください。

さらに、[[sudo]] を使用する場合、[[Sudo#Permissive umask|デフォルトの root umask]] を適用するよう設定することを検討してください。

=== SUID ファイルと SGID ファイル ===

[[Wikipedia:ja:Setuid|Setuid]] ビットや Setgid ビットが設定されたファイルには注意しましょう。このようなファイルの例としては、以下があります。

* [[PAM|unix_chkpwd]]
* chage, expiry, gpasswd, groupmems, [[passwd]], sg, ({{Pkg|shadow}})
* [[FUSE|fusermount3]], fusermount
* pkexec
* [[OpenSSH|ssh-keysign]]
* chfn, chsh, mount, newgrp, umount, wall, write ({{Pkg|util-linux}})
* [[sudo]], {{Pkg|sudo-rs}}, [[doas]], [[su]], su-rs, [[Kerberos|ksu]]
* [[firejail]]
* [[Dbus|dbus-daemon-launch-helper]]
* [[Chromium|chromium-sandbox]]
* [[Xorg|Xorg.wrap]]

このような実行ファイルの主なリスクとして、特権昇格の脆弱性があります。例えば [[Wikipedia:Setuid#Security impact]] を参照してください。[https://www.cvedetails.com/vulnerability-list/vendor_id-16224/product_id-36412/Calibre-ebook-Calibre.html][https://www.cvedetails.com/product/32625/Sudo-Project-Sudo.html?vendor_id=15714][https://www.cvedetails.com/vulnerability-list/vendor_id-16191/Firejail-Project.html]

SUID ビットが設定されているが root によって所有されていないファイル、または SGID ビットが設定されているファイルは、''典型的には''潜在的なリスクがより小さいですが、理論上、そのようなファイルに脆弱性が存在している場合は、依然として損害を与える可能性があります。通常、代わりに[[ケイパビリティ]]を割り当てることによって、Setuid や Setgid の使用を回避することが可能です。

{{Tip|SUID/SGID 実行ファイルを含むパッケージを最新に保って、脆弱性からシステムを守ることが肝心です。}}

SUID ビットか SGID ビットを持つファイルを {{ic|/usr/bin}} から探すには:

$ find /usr/bin -perm "/u=s,g=s"

== ユーザー設定 ==

=== root アカウントを日常的に使用しない ===

最小特権の原則に従い、root ユーザーを日常的に使用しないようにしてください。システムを使用する各人に非特権ユーザーアカウントを作成するか。一時的な特権アクセスには、必要に応じて [[sudo]] を使用する。

=== ログイン失敗後の遅延時間の設定 ===

以下の行を {{ic|/etc/pam.d/system-login}} に追加し、ログインに失敗した際に最低4秒の遅延を追加します。

{{hc|/etc/pam.d/system-login|2=
auth optional pam_faildelay.so delay=4000000
}}

{{ic|4000000}} は遅延させる時間をマイクロ秒単位で指定します。

===3回ログインを失敗したユーザーをロックアウトする===

{{Pkg|pambase}} 20200721.1-2 の時点では、デフォルトで {{ic|pam_faillock.so}} が有効になっており、15分間に3回ログインに失敗すると10分間ユーザをロックアウトします ({{Bug|67644}} を参照してください) このロックアウトはパスワード認証 (例:ログインと ''sudo'') にのみ適用され、SSH 経由の公開鍵認証はそのまま利用可能です。完全なサービス拒否を防ぐために、このロックアウトは root では無効になっています。

ユーザーをロック解除するには、次のようにします。

$ faillock --reset --user ''username''

デフォルトでは、ロック機構は {{ic|/run/faillock/}} にあるユーザーごとのファイルです。ディレクトリの所有者は root ですが、ファイルの所有者はユーザーなので、 {{ic|faillock}} コマンドはファイルを空にするだけで、root は必要ありません。

モジュール {{ic|pam_faillock.so}} は、ファイル {{ic|1=/etc/security/faillock.conf}} で設定することが可能です。ロックアウトのパラメータです。

* {{ic|unlock_time}} - ロックアウト時間 (秒単位、デフォルトは10分)
* {{ic|fail_interval}} - ロックアウトに失敗するとロックアウトされる時間 (秒単位、デフォルトは15分)
* {{ic|deny}} - ロックアウトするまでに何回ログインに失敗するか (デフォルトは 3)

{{Note|{{ic|1=deny = 0}} はロックアウトを無効化します}}

デフォルトでは、すべてのユーザーロックは再起動後に失われます。攻撃者がマシンをリブートできるのであれば、ロックは持続させた方が安全です。ロックを持続させるには、{{ic|1=/etc/security/faillock.conf}} の {{ic|dir}} パラメータを {{ic|/var/lib/faillock}} に変更する必要があります。

変更を反映させるために再起動する必要はありません。root アカウントのロックアウトを有効にする、集中ログイン (LDAP など) を無効にするなど、さらなる設定オプションについては {{man|5|faillock.conf}} を参照してください。

=== プロセスの数を制限する ===

信頼できないユーザーが大量に存在するシステムでは、一度に実行できるプロセスの数を制限して、[[Wikipedia:ja:Fork爆弾|フォーク爆弾]]などのサービス拒否攻撃を予防することが重要です。ユーザーやグループごとに実行できるプロセスの数は {{ic|/etc/security/limits.conf}} で定義することができ、デフォルトでは空になっています。以下の値をファイルに追加すると、実行できるプロセスが100個までに制限されます。{{ic|prlimit}} コマンドを使って一時的に上げられる最大数も200個までに制限します。ユーザーが普段実行するプロセスの数や、管理するハードウェアにあわせて適切な値に変更してください。

* soft nproc 100
* hard nproc 200

=== Wayland を使用する ===

[[Xorg]] よりも [[Wayland]] を使用することをお勧めします。Xorg の設計は現代のセキュリティ慣行より古く、多くの人が [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 は安全でないと考えています] 例えば、Xorg のアプリケーションは非アクティブな状態でもキーストロークを記録することがあります。

もし Xorg を実行しなければならないなら、[[Xorg#Rootless_Xorg|root での実行を避ける]]ことが推奨されます。Wayland 内では、XWayland 互換レイヤーは自動的に root レス Xorg を使用します。

== root の制限 ==
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。

=== su の代わりに sudo を使う ===
[[Su#セキュリティ|色々な理由]]から特権アクセスには [[su]] よりも [[sudo]] を使うほうが好ましいとされます。

* 通常の権限しか持たないユーザーが実行した特権コマンドのログを保持します。
* root アクセスを必要とする各ユーザーに root ユーザーのパスワードを与える必要がありません。
* 完全な root ターミナルは作成されないため、{{ic|sudo}} は root アクセスが必要ないコマンドを偶発的に ''root'' で実行してしまうことを防止します。これは[[Wikipedia:ja:最小権限の原則|最小権限の原則]]と合っています。
* 一つのコマンドを実行するためだけに完全な root アクセスを与える代わりに、ユーザーごとに個々のプログラムを有効にすることができます。例えば、ユーザー ''alice'' に特定のプログラムへのアクセス権限を与えるには:

# visudo

{{hc|/etc/sudoers|
alice ALL = NOPASSWD: /path/to/program}}

また、全てのユーザーに個別のコマンドを許可することも可能です。通常ユーザーでサーバーから Samba 共有をマウントするには:

%users ALL=/sbin/mount.cifs,/sbin/umount.cifs

これによって users グループのメンバーである全てのユーザーが全てのマシン (ALL) から {{ic|/sbin/mount.cifs}} や {{ic|/sbin/umount.cifs}} コマンドを実行できるようになります。

{{Tip|{{ic|visudo}} で {{ic|vi}} の代わりに {{ic|nano}} を使うには:

{{hc|/etc/sudoers|
2=Defaults editor=/usr/bin/rnano
}}
{{ic|1=# EDITOR=nano visudo}} のエクスポートは何にでも {{ic|EDITOR}} として使うことができるためにセキュリティリスクとされています。
}}

==== sudo を使ってファイルを編集する ====
root で {{ic|vim}} などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:

export SUDO_EDITOR=rvim

ファイルの編集には {{ic|sudoedit filename}} または {{ic|sudo -e filename}} を使って下さい。自動的に {{ic|rvim}} によって {{ic|filename}} が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。

=== root ログインの制限 ===
[[sudo]] を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。[[sudo]] を使える状態のまま root を無効化したい場合、{{ic|passwd -l root}} を使用します。

==== 特定のユーザーだけに許可を与える ====
[[Wikipedia:Pluggable authentication module|PAM]] の {{ic|pam_wheel.so}} は {{ic|wheel}} グループに入っているユーザーだけに {{ic|su}} を使用したログインを許可します。{{ic|/etc/pam.d/su}} と {{ic|/etc/pam.d/su-l}} の両方を編集して次の行をアンコメントしてください:
{{bc|<nowiki>
# Uncomment the following line to require a user to be in the "wheel" group.
auth required pam_wheel.so use_uid
</nowiki>}}
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。

==== ssh ログインを拒否する ====
ローカルユーザーの root ログインを拒否したくない場合でも、[[SSH#root ログインを拒否する|SSH による root ログインを拒否]]するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。

==== access.conf で許容されるログインの組み合わせを指定する ====

誰かが [[PAM]] でログインしようとすると、 {{ic|/etc/security/access.conf}} がそのログインプロパティに一致する最初の組み合わせをチェックします。そして、その組み合わせのルールに基づいて、試行が失敗するか成功するかが決まります。

+:root:LOCAL
-:root:ALL

特定のグループやユーザーに対してルールを設定することができます。この例では、ユーザー archie は、wheel および adm グループに属するすべてのユーザーと同様に、ローカルでのログインを許可されています。それ以外のログインは拒否されます。

+:archie:LOCAL
+:(wheel):LOCAL
+:(adm):LOCAL
-:ALL:ALL

詳しくは {{man|5|access.conf}} で確認してください。

==強制アクセス制御==

[[Wikipedia:ja:強制アクセス制御|強制アクセス制御]] (Mandatory Access Control, MAC) は Arch やほとんどの Linux ディストリビューションで使われている[[Wikipedia:ja:任意アクセス制御|任意アクセス制御]] (Discretionary Access Control, DAC) とは大きく異なるタイプのセキュリティポリシーです。原則的に MAC ではシステムに影響を与えるプログラムの行動は全てセキュリティルールセットによってチェックを受けます。このルールセットは、DAC とは対照的に、ユーザーが変更することは不可能です。実装方法は色々と異なるタイプが存在しますが、強制アクセス制御を使うことで実質的にコンピュータのセキュリティを著しく向上させることになります。

===パス名 MAC===
パス名ベースのアクセス制御は指定されたファイルのパスに基づいてパーミッションを与えるというシンプルな形式のアクセス制御です。この形式のアクセス制御の欠点としてはファイルが移動されてもパーミッションはファイルと一緒に付いていかないということが挙げられます。プラス面となるのは、パス名ベースの MAC はラベルベースの MAC と異なり、幅広いファイルシステムに実装できることです。

*[[AppArmor]] は [[Wikipedia:ja:カノニカル|Canonical]] によって開発されている MAC 実装で SELinux に比べて"簡単"になっています。
*[[TOMOYO Linux|Tomoyo]] はもうひとつのシンプルで、使いやすい強制アクセス制御を提供するシステムです。利用と実装の両面でシンプルになるように設計されており、依存するライブラリがとても少なくなっています。

===ラベル MAC===
ラベルベースのアクセス制御ではファイルの拡張属性を使ってセキュリティパーミッションを管理します。このシステムはセキュリティの機能においてパス名ベースの MAC よりも間違いなく柔軟性が高い一方、拡張属性をサポートしているファイルシステムでしか動作しません。

*[[SELinux]] は、Linux セキュリティを向上させる [[Wikipedia:ja:アメリカ国家安全保障局|NSA]] プロジェクトに基づいており、システムユーザーやロールとは完全に独立して MAC を実装しています。成長してオリジナルの設定が変わっていくシステムのコントロールを簡単に維持できる、極めて強固なマルチレベル MAC ポリシー実装を提供します。

=== アクセス制御リスト ===
[[アクセス制御リスト]] (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。

== カーネルの堅牢化 ==

=== カーネルの自己防衛機能/脆弱性攻撃対策 ===

{{pkg|linux-hardened}} パッケージは、[https://github.com/anthraxx/linux-hardened 基本的なカーネル堅牢化パッチセット]と、{{pkg|linux}} パッケージよりもセキュリティに重点を置いたコンパイル時設定オプションを使用します。カスタムビルドでは、セキュリティ寄りのデフォルトとは異なる、セキュリティと性能の妥協点を選択することができます。

しかし、このカーネルを使うといくつかのパッケージが動かなくなることに注意する必要があります。例えば

* {{AUR|skypeforlinux-preview-bin}}
* {{AUR|skypeforlinux-stable-bin}}
* {{pkg|throttled}}

[[NVIDIA]] などのアウトオブツリードライバを使用している場合、その [[DKMS]] パッケージに切り替える必要があるかもしれません。

==== ユーザー空間 ASLR の比較 ====

{{pkg|linux-hardened}} パッケージは、アドレス空間配置ランダム化の改善された実装をユーザ空間のプロセスに対して提供します。{{pkg|paxtest}} コマンドを使うことで、提供されるエントロピーの推定値を得ることができます:

===== 64 ビットプロセス =====

{{hc|linux-hardened 5.4.21.a-1-hardened|
Anonymous mapping randomization test : 32 quality bits (guessed)
Heap randomization test (ET_EXEC) : 40 quality bits (guessed)
Heap randomization test (PIE) : 40 quality bits (guessed)
Main executable randomization (ET_EXEC) : 32 quality bits (guessed)
Main executable randomization (PIE) : 32 quality bits (guessed)
Shared library randomization test : 32 quality bits (guessed)
VDSO randomization test : 32 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)
Randomization under memory exhaustion @~0: 32 bits (guessed)
Randomization under memory exhaustion @0 : 32 bits (guessed)
}}

{{hc|linux 5.5.5-arch1-1|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 20 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 29 bits (guessed)
Randomization under memory exhaustion @0 : 29 bits (guessed)
}}

{{hc|linux-lts 4.19.101-1-lts|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 19 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 28 bits (guessed)
Randomization under memory exhaustion @0 : 28 bits (guessed)
}}

===== 32 ビットプロセス (x86_64 カーネル上) =====

{{hc|linux-hardened|
Anonymous mapping randomization test : 16 quality bits (guessed)
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)
Heap randomization test (PIE) : 27 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 18 quality bits (guessed)
Shared library randomization test : 16 quality bits (guessed)
VDSO randomization test : 16 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)
Randomization under memory exhaustion @~0: 18 bits (guessed)
Randomization under memory exhaustion @0 : 18 bits (guessed)
}}

{{hc|linux|
Anonymous mapping randomization test : 8 quality bits (guessed)
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)
Heap randomization test (PIE) : 13 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 8 quality bits (guessed)
Shared library randomization test : 8 quality bits (guessed)
VDSO randomization test : 8 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)
Randomization under memory exhaustion @~0: No randomization
Randomization under memory exhaustion @0 : No randomization
}}

=== proc ファイルシステム内のカーネルポインタへのアクセスを制限する ===

{{ic|kernel.kptr_restrict}} を 1 に設定すると、{{ic|CAP_SYSLOG}} を持たない通常ユーザから {{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが秘匿され、カーネルのエクスプロイトで動的にアドレス/シンボルを解決することが困難になります。これは、事前にコンパイルされた Arch Linux カーネルではあまり意味がありません。周到な攻撃者はカーネルパッケージをダウンロードして、そこから手動でシンボルを取得することができるからです。しかしながら、自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし、一部の {{Pkg|perf}} コマンドの機能が、root 以外のユーザによって使用されば場合に破壊されます (しかし、いずれにせよ多くの {{Pkg|perf}} コマンドは root アクセスを必要とします)。詳細は {{Bug|34323}} を参照してください。

{{ic|kernel.kptr_restrict}} を 2 に設定すると、{{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが権限に依らず隠されます。

{{hc|/etc/sysctl.d/51-kptr-restrict.conf|2=
kernel.kptr_restrict = 1
}}

{{Note|{{pkg|linux-hardened}} はデフォルトで {{ic|0}} ではなく {{ic|1=kptr_restrict=2}} を設定します。}}

=== BPF の堅牢化 ===

BPF は、実行時にカーネル内のバイトコードを動的にロードして実行するために使用されるシステムです。ネットワーク (XDP, tc など)、トレース (kprobes, uprobes, tracepoints など)、セキュリティ (seccomp など) など、多くの Linux カーネルサブシステムで使用されています。また、高度なネットワークセキュリティ、パフォーマンスプロファイリング、ダイナミックトレースにも有効です。

BPF はもともと [[Wikipedia:ja:Berkeley Packet Filter|Berkeley Packet Filter]] の頭文字をとったもので、オリジナルの古典的な BPF は BSD 用のパケットキャプチャツールに使われていたためです。これは最終的に拡張 BPF (eBPF) に発展し、その後まもなくただの BPF (頭字語ではありません) に改名されました。BPFはパケットフィルタリングツールの実装に使われることがありますが、 iptables や netfilter のようなパケットフィルタリングツールと混同しないでください。

BPF のコードは解釈されるか、[[Wikipedia:ja:実行時コンパイラ|Just-In-Time (JIT) コンパイラ]]を使ってコンパイルされるかのどちらかです。Arch のカーネルは {{ic|CONFIG_BPF_JIT_ALWAYS_ON}} でビルドされており、BPF インタープリタを無効にして全ての BPF を JIT コンパイラでコンパイルするよう強制しています。これにより、攻撃者が BPF を使って SPECTRE 型の脆弱性を悪用した特権昇格攻撃をすることが難しくなります。詳しくは、[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290af86629b25ffd1ed6232c4e9107da031705cb CONFIG_BPF_JIT_ALWAYS_ON を導入したカーネルパッチ]を参照してください。

カーネルは JIT コンパイルされた BPF に対して、パフォーマンスと多くの BPF プログラムをトレース・デバッグする能力を犠牲にして、ある種の JIT スプレー攻撃を軽減するための堅牢化機能を備えています。この機能は、{{ic|net.core.bpf_jit_harden}} を {{ic|1}} (非特権コードの堅牢化を有効化する) か {{ic|2}} (全てのコードの堅牢化を有効化する) に設定することで有効化できます。

詳しくは、[https://docs.kernel.org/admin-guide/sysctl/net.html カーネルドキュメント] の {{ic|net.core.bpf_*}} 設定を参照してください。

{{Tip|
* {{Pkg|linux-hardened}} では、デフォルトで {{ic|1=net.core.bpf_jit_harden=2}} が設定されており、{{ic|0}} ではありません。
* デフォルトでは、BPF プログラムは非特権ユーザでも実行可能です。この挙動を変更するには {{ic|1=kernel.unprivileged_bpf_disabled=1}} を設定してください [https://access.redhat.com/security/cve/cve-2021-33624]。
}}

=== ptrace スコープ ===

{{man|2|ptrace}} システムコールは、あるプロセス ("tracer") が他のプロセス ("tracee") の実行を監視、制御し、tracee のメモリとレジスタを検査、変更するための手段を提供します。通常、{{ic|ptrace}} は ''gdb'' や ''strace''、''perf''、''reptyr'' などのデバッグツールによって使用されます。しかし、他のプロセスからデータを読んだり、他のプロセスの制御を奪ったりする手段を悪意のあるプロセスにも提供してしまいます。

Arch では、{{ic|kernel.yama.ptrace_scope}} [[カーネルパラメータ]]を提供する [https://docs.kernel.org/admin-guide/LSM/Yama.html Yama LSM] がデフォルトで有効化されています。このパラメータはデフォルトで {{ic|1}} (制限) に設定されており、{{ic|CAP_SYS_PTRACE}} [[ケイパビリティ]]も特権も持たない tracer が制限されたスコープ外で {{ic|ptrace}} コールを実行できないようにしています。これは、古典的なパーミッションと比べてセキュリティ上大きな改善です。このモジュールが無いと、同じユーザとして実行されているプロセスを隔てるものがなくなってしまいます ({{man|7|pid_namespaces}} などの他のセキュリティレイヤーがない場合)。

{{Note|デフォルトでは、[[sudo]] を使うなどして、{{ic|ptrace}} を必要とするツールを特権プロセスとして実行することができます。}}

デバッグツールを使う必要がない場合は、システムを堅牢化するために {{ic|kernel.yama.ptrace_scope}} を {{ic|2}} (管理者限定) や {{ic|3}} ({{ic|ptrace}} を禁止) に設定することを検討してください。

=== hidepid ===

{{Warning|
* これは、サンドボックスと [[Xorg]] 内で実行するアプリケーションなど、特定のアプリケーションで問題を発生させる場合があります (回避策を見てください)。
* {{Pkg|systemd}} > 237.64-1 を使用している場合、これは [[D-Bus]]、[[Polkit]]、[[PulseAudio]]、そして [[bluetooth]] で問題を発生させます。
}}

カーネルには、{{ic|proc}} ファイルシステムを {{ic|1=hidepid=}} オプションと {{ic|1=gid=}} オプションを使ってマウントすることで、他のユーザのプロセス (通常、{{ic|/proc}} でアクセス可能) を非特権ユーザから秘匿する機能があります。これらのマウントオプションは https://docs.kernel.org/filesystems/proc.html でドキュメント化されています。

これにより、侵入者が動作中のプロセスの情報 (特権で動作しているデーモンがあるか、他のユーザが機密情報を扱うプログラムを実行しているか、他のユーザがプログラムを実行しているか) を得る作業を複雑化し、ユーザが特定のプログラムを実行しているかどうかを知るのを不可能にし (ただし、そのプログラムがそれ自体の挙動で存在を他者に知られることがないとする)、さらに、貧弱に書かれたプログラムが機密情報をプログラム引数を介して渡したとしてもローカルの盗聴者から守られます。

{{ic|proc}} [[ユーザーとグループ#システムグループ#グループ]] ({{Pkg|filesystem}} パッケージによって提供されています) は、他のユーザのプロセス情報を得ることのできるユーザのホワイトリストとして機能します。ユーザやサービスが自身以外の {{ic|/proc/<pid>}} ディレクトリにアクセスする必要がある場合、そのユーザまたはサービスを[[ユーザーとグループ#グループ管理|proc グループに追加してください]]。

例えば、プロセスの情報を {{ic|proc}} グループに属さない他のユーザから隠すには:

{{hc|/etc/fstab|2=
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
}}

ユーザのセッションを正しく動作させるために、''systemd-logind'' を例外として追加する必要があります:

{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=
[Service]
SupplementaryGroups=proc
}}

=== モジュールのロードを制限する ===

デフォルトの Arch カーネルは {{ic|CONFIG_MODULE_SIG_ALL}} が有効で、{{Pkg|linux}} パッケージの一部としてビルドされた全てのカーネルモジュールに署名します。これにより、カーネルは有効なキーで署名されたモジュールだけをロードするように制限できます。実際、これはローカルでコンパイルされた、もしくは {{Pkg|virtualbox-host-modules-arch}} などのパッケージによって提供された、ツリー外のモジュールは全てロードできないことを意味します。

カーネルモジュールの読み込みは {{ic|1=module.sig_enforce=1}} [[カーネルパラメータ]]を設定することで制限することができます。詳細は[https://docs.kernel.org/admin-guide/module-signing.html カーネルドキュメント]で見られます。

=== kexec を無効にする ===

Kexec は、現在実行中のカーネルを置き換えることを可能にします。

{{hc|/etc/sysctl.d/51-kexec-restrict.conf|2=
kernel.kexec_load_disabled = 1
}}

{{Tip|kexec は {{pkg|linux-hardened}} でデフォルトで無効になっています。}}

=== カーネルロックダウンモード ===

Linux 5.4 から、オプションの[https://mjg59.dreamwidth.org/55105.html ロックダウン機能]がカーネルに[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d 追加されました]。これは、UID 0 (root) とカーネルの間の境界を強化することを目的としています。この機能を有効にすると、ハードウェアやカーネルへの低レベルなアクセスに依存している一部のアプリケーションは動作しなくなる可能性があります。

ロックダウンを使用するには、LSM が初期化され、ロックダウンモードが設定されている必要があります。

[[カーネル#公式サポートカーネル|公式にサポートされているカーネル]]は全て LSM を初期化しますが、ロックダウンモードを強制しません。

{{Tip|有効化されている LSM は {{ic|cat /sys/kernel/security/lsm}} を実行することで確認することができます。}}

ロックダウンには2つの動作モードがあります:

* {{ic|integrity}}: ユーザーランドが実行中のカーネルを変更できるカーネル機能 (kexec、bpf) は無効化されます。
* {{ic|confidentiality}}: ユーザーランドがカーネルから機密情報を抽出するためのカーネルの機能も無効化されます。

特定の脅威モデルで指示がない限り、{{ic|integrity}} を使用することが推奨されます。

実行時にカーネルのロックダウンを有効にするには、以下を実行してください:

# echo ''mode'' > /sys/kernel/security/lockdown

起動時にカーネルのロックダウンを有効にするには、{{ic|1=lockdown=''mode''}} [[カーネルパラメータ]]を使用してください:

{{Note|
* カーネルロックダウンを実行時に無効化することはできません。
* カーネルロックダウンは、[[ハイバネート]]を無効化します。
}}

{{man|7|kernel_lockdown}} も参照してください。

=== Linux Kernel Runtime Guard (LKRG) ===

[https://www.openwall.com/lkrg/ LKRG] ({{AUR|lkrg-dkms}}) は、カーネルの整合性チェックとエクスプロイト行為の検出を行うカーネルモジュールです。

== アプリケーションのサンドボックス化 ==

こちらも参照 [[Wikipedia:ja:サンドボックス (セキュリティ)]]

{{Note|ユーザー名前空間の設定項目 {{ic|CONFIG_USER_NS}} は、現在 {{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}}、および {{Pkg|linux-hardened}} で有効になっています。これが無効だと、一部のアプリケーションで特定のサンドボックス機能が利用できなくなる可能性があります。}}

{{Warning|非特権ユーザー名前空間の使用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) は、{{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}} でデフォルトで有効になっています。これにより、ローカル特権昇格の攻撃対象が大幅に拡大します([https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction AppArmorのWiki] および {{Bug|36969}} を参照。}}

これを軽減するためには、次のいずれかを行ってください:

* 安全なデフォルトを持つ {{Pkg|linux-hardened}} カーネルを使用する、または
* {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] を {{ic|0}} に設定する。

これにより、[[Zoom Meetings|Zoom]] や {{pkg|nsjail}} などのアプリケーションが動作しなくなる場合があることに注意してください。また、システムに {{pkg|bubblewrap}} がインストールされている場合は、{{pkg|bubblewrap-suid}} に置き換える必要があります。詳細は [[Bubblewrap#インストール]] を参照してください。

=== Firejail ===

[[Firejail]] は、アプリケーションやサーバーをサンドボックス化するための使いやすいツールです。元々はブラウザやインターネット向けアプリケーションのために作成されましたが、現在では多くのアプリケーションに対応しています。さまざまな機能を備えたサンドボックス環境を構築するために、suid バイナリとしてインストールされ、ブラックリストとホワイトリストに基づいてターゲットアプリケーションのサンドボックス化された実行環境を構築します。

=== bubblewrap ===

[[bubblewrap]] は、[[Flatpak]] などの非特権コンテナツール向けに開発されたサンドボックスアプリケーションで、Firejail よりもリソース消費と複雑さが大幅に小さいです。ファイルパスのホワイトリスト機能は欠けていますが、bubblewrap はバインドマウントのほか、ユーザー/IPC/PID/ ネットワーク /cgroup 名前空間の作成をサポートしており、シンプルなものから複雑なサンドボックスまで対応可能です。

[[Bubblejail]] サンドボックスは [[bubblewrap]] を基にしており、リソース指向の権限モデルと、権限を調整するためのグラフィカルインターフェースを提供します。

=== chroot ===

手動で [[chroot]] してサンドボックス化されたプロセス環境を作成できます。しかし、これは他のサンドボックス技術に比べて非常に制限されています。そのサンドボックス化の範囲はファイルパスの隔離に限られています。

=== Linux Containers ===

[[Linux Containers]] は、他のオプション([[#完全な仮想化オプション|完全な仮想化オプション]] を除く) よりも多くの隔離が必要な場合に適した選択肢です。LXC は、既存のカーネルの上で擬似 chroot 内で実行され、独自の仮想ハードウェアを持っています。

=== 完全な仮想化オプション ===

[[VirtualBox]]、[[KVM]]、[[Xen]]、または [https://www.qubes-os.org/ Qubes OS](Xen ベース)などの完全仮想化オプションを使用することで、リスクの高いアプリケーションを実行したり、危険なウェブサイトを閲覧したりする場合に、隔離とセキュリティを強化することができます。

==ネットワークとファイアウォール==

===ファイアウォール===

標準の Arch カーネルは [[Wikipedia:Netfilter|Netfilter]] の [[iptables]] および [[nftables]] を使用できますが、これらのサービスはデフォルトで [[有効化]] されていません。システム上で実行されているサービスを保護するために、何らかの形のファイアウォールを設定することを強く推奨します。多くのリソース(ArchWiki など)では、どのサービスを保護するべきかが明示的に記載されていないため、ファイアウォールを有効にすることは良い予防措置となります。

* 一般的な情報については [[iptables]] および [[nftables]] を参照してください。
* iptables ファイアウォールの設定方法については [[シンプルなステートフルファイアウォール]] を参照してください。
* netfilter の設定方法については [[ファイアウォール]] を参照してください。
* Bluetack などの IP アドレスリストをブロックするには [[Ipset]] を参照してください。
* {{Pkg|opensnitch}} は、アプリケーション、ポート、ホストなどによる設定可能なルールをサポートする、構成可能なインバウンドおよびアウトバウンドファイアウォールです。

==== ポートを開く ====

一部のサービスは、開かれたネットワークポートでインバウンドトラフィックを待ち受けます。これらのサービスは、必要最低限のアドレスとインターフェースにのみバインドすることが重要です。リモート攻撃者が [https://samy.pl/slipstream/ ネットワークプロトコルの欠陥を悪用して公開されたサービスにアクセスする] 可能性があります。これは、[https://nvd.nist.gov/vuln/detail/CVE-2019-13450 localhost にバインドされたプロセス] にも発生することがあります。

一般的に、サービスがローカルシステムのみでアクセス可能であれば、非ループバックアドレス(例えば {{ic|0.0.0.0/0}})ではなく、Unix ドメインソケット({{man|7|unix}})や {{ic|localhost}} のようなループバックアドレスにバインドするべきです。

サービスがネットワーク越しに他のシステムからアクセス可能である必要がある場合、厳格な [[ファイアウォール]] ルールでアクセスを制御し、可能な限り認証、認可、暗号化を構成することが重要です。

現在のすべてのオープンポートをリストするには、{{ic|ss -l}} を使用できます。すべてのリスニング中のプロセスとその数値的な TCP および UDP ポート番号を表示するには:

# ss -lpntu

その他のオプションについては、{{man|8|ss}}を参照してください。

===カーネルパラメータ===
ネットワークに影響を与えるカーネルパラメータは [[sysctl]] を使って設定できます。設定方法は [[sysctl#TCP/IP スタックの防御]] を見て下さい。

===SSH===
[[SSH 鍵#パスワードログインの無効化|SSH 鍵を必要]]としない [[Secure Shell]] を使うのは避けましょう。これは[[Wikipedia:ja:総当たり攻撃|総当たり攻撃]]を防ぎます。また、[[Fail2ban]] や [[Sshguard]] はログを監視して [[iptables|iptables ルール]]を書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。

二段階認証によって認証を強化することができます。[[Google Authenticator]] はワンタイムパスコード (OTP) を使用する二段階認証方式を提供します。

[[Secure Shell#root ログインを拒否する|root ログインを拒否する]]のは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。

===DNS===

[[DNSSEC]] や [[DNSCrypt]] を見て下さい。

=== プロキシ ===

プロキシはアプリケーションとネットワークの間に挟まる追加レイヤーとして使われ、信頼できないソースからのデータをサニタイズします。少ない権限でプロキシを動作させることで、エンドユーザー権限で複雑なアプリケーションを実行するよりも攻撃対象を小さくすることができます。

例えば {{Pkg|glibc}} の中に実装されている DNS リゾルバを考えてみてください。(root で実行することもある) アプリケーションにリンクされている DNS リゾルバにバグが存在した場合、リモートコード実行につながる危険があります。[[dnsmasq]] などの DNS キャッシュサーバーをインストールしてプロキシとして使うことで問題を防ぐことが可能です [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]。

=== SSL 証明書の管理 ===

サーバーサイドの SSL 証明書の管理については [[OpenSSL]] や [[Network Security Services]] (NSS) を参照してください。また、関連する [[Let’s Encrypt]] プロジェクトも見てください。

デフォルトのインターネット SSL 証明書のトラストチェーンは {{Pkg|ca-certificates}} パッケージによって提供されています。Arch はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: {{AUR|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) に依存しています。

デフォルトの証明書を変えたいと思うことがあるかもしれません。例えば、[http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ ニュース] を読んで証明書を信頼しないようにしたい場合 (ソースのプロバイダーによって無効になるのを待てない場合)、Arch のインフラを使うことで簡単に設定できます:
# {{ic|.crt}} 形式の証明書を入手してください (例: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; 既存のルート認証局の場合、システム内にあるはずです)。
# {{ic|/etc/ca-certificates/trust-source/blacklist/}} にコピーしてください。
# root で ''update-ca-trust'' を実行してください。

お好きなブラウザを開いて'''信頼できない'''サイトとして表示されれば、ブラックリストが上手く機能しています。

== 物理セキュリティ ==

{{Note|リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。}}

十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで''実用的で''高いレベルのセキュリティを得ることができます。

攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [http://www.breaknenter.org/projects/inception/]。これを防ぐためにできることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識やそこまでの意図はなく、現実に実行されることはほとんどありません。

[[#ディスク暗号化|ディスク暗号化]]はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。

===BIOS をロックダウンする===

BIOS にパスワードを追加することによってリムーバブルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。

=== ブートローダー ===

[[Arch ブートプロセス#ブートローダー|ブートローダー]] を保護することは非常に重要です。保護されていないブートローダは、[[カーネルパラメータ]]に{{ic|1=init=/bin/sh}} を設定することでシェルに直接ブートしてログインの制限を回避することができます。

==== Syslinux ====

Syslinux は[[Syslinux#セキュリティ|ブートローダーのパスワード保護]]をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。

==== GRUB ====

[[GRUB]] はブートローダのパスワードもサポートしています。詳しくは [[GRUB/ヒントとテクニック#GRUB メニューのパスワード保護|GRUB メニューのパスワード保護]] を参照してください。[[GRUB/ヒントとテクニック# GRUB メニューのパスワード保護|暗号化 /boot]] もサポートしていますが、これはブートローダコードの一部だけを暗号化しないままにしています。GRUB の設定、[[カーネル]]、[[initramfs]] は暗号化されています。

==== systemd-boot ====

[[systemd-boot]] は [[#セキュアブート]] が有効な場合、カーネルパラメータの編集を無効にします。代わりの方法として、[[systemd-boot#パスワードで保護されたカーネルパラメータエディタ]] を参照して下さい、より伝統的なパスワードベースのオプションを使用できます。

=== セキュアブート ===

[[セキュアブート]] は [[UEFI]] の機能で、コンピュータが起動するファイルの認証を可能にするものです。これは、起動パーティション内のファイルを置き換えるような、いくつかの [https://ja.wikipedia.org/wiki/%E6%82%AA%E6%84%8F%E3%81%82%E3%82%8B%E3%83%A1%E3%82%A4%E3%83%89%E6%94%BB%E6%92%83 悪意あるメイド攻撃] を防止するのに役立ちます。通常、コンピュータにはベンダー (OEM) によって登録されたキーが付属しています。しかし、これを取り外して、コンピュータを「セットアップモード」にし、ユーザーが自分のキーを登録・管理できるようにすることができます。

セキュアブートのページでは、[https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Implementing_Secure_Boot using your own keys] によってセキュアブートを設定する方法を案内しています。

=== トラステッドプラットフォームモジュール(TPM) ===

[[Trusted Platform Module|TPM]] は、暗号鍵が埋め込まれたハードウェア・マイクロプロセッサです。これは、最近のほとんどのコンピュータの基本的な信頼の根源を形成し、ブートチェーンのエンドツーエンドの検証を可能にします。内部スマートカードとして使用したり、コンピュータ上で動作するファームウェアを証明したり、改ざん防止とブルートフォース耐性のあるストアにユーザーが秘密情報を保管することができます。

=== リムーバブルフラッシュドライブ上のブートパーティション ===

ブートパーティションをフラッシュドライブに置き、それがないとシステムが起動しないようにする、というのはよくあるアイデアです。このアイデアの支持者はしばしば [[セキュリティ#ディスク暗号化|ディスク暗号化]] を併用し、ブートパーティションに置かれた [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USBdetached encryption headers] を使っている人もいます。

この方法は [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USB encrypting /boot] と統合することも可能です。

=== 自動ログアウト ===
[[Bash]] または [[Zsh]] を使っている場合、{{ic|TMOUT}} によってタイムアウトによるシェルからの自動ログアウトを設定できます。

例えば、以下は仮想コンソールから自動でログアウトします (X11 のターミナルエミュレータからはログアウトしません):

{{hc|/etc/profile.d/shell-timeout.sh|<nowiki>
TMOUT="$(( 60*10 ))";
[ -z "$DISPLAY" ] && export TMOUT;
case $( /usr/bin/tty ) in
/dev/tty[0-9]*) export TMOUT;;
esac
</nowiki>}}

(X のコンソールも含めて) 全ての Bash/Zsh プロンプトでタイムアウトさせたい場合は、次を使って下さい:

$ export TMOUT="$(( 60*10 ))";

シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや {{ic|TMOUT}} をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。

=== 不正なUSBデバイスから保護する ===

[[Usbguard]] は、デバイスの属性に基づく基本的なホワイトリストおよびブラックリスト機能を実装することで、不正な USB デバイス (別名 [https://ja.wikipedia.org/wiki/BadUSB BadUSB], [https://github.com/samyk/poisontap PoisonTap] または [https://lanturtle.com/ LanTurtle]) からコンピューターを保護できるソフトウェアフレームワークです。

=== 揮発性データの収集 ===

電源が入っているコンピュータは、[https://fedvte.usalearning.gov/courses/CSI/course/videos/pdf/CSI_D01_S05_T01_STEP.pdf volatile data collection] に対して脆弱である可能性があります。コンピュータの電源を入れる必要がない時や、コンピュータの物理的な安全性が一時的に損なわれる場合(例:セキュリティチェックポイントを通過する時)には、コンピュータの電源を完全に切ることがベストプラクティスです。

== パッケージ ==

=== パッケージの認証 ===
パッケージの署名が適正に使われていないと [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview パッケージマネージャへの攻撃] が考えられ、さらに [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html 適切な署名システム] を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは [[Pacman-key]] を見て下さい。

=== アップグレード ===

定期的に [[システムメンテナンス#システムのアップグレード|システムのアップグレード]] を行うことが重要です。

=== 脆弱性アラートの確認 ===

National Vulnerability Database が提供する Common Vulnerabilities and Exposure (CVE) Security Alert の更新を購読し、[https://nvd.nist.gov/download.cfm NVD Download webpage] で見つけてください。[https://security.archlinux.org/ Arch Linux Security Tracker] は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットを表形式でまとめた、特に有用なリソースです。ツール {{Pkg|arch-audit}} は実行中のシステムに影響を与える脆弱性をチェックするために使われます。グラフィカルなシステムトレイである {{Pkg|arch-audit-gtk}} も使うことができます。[https://wiki.archlinux.org/title/Arch_Security_Team Arch Security Team]も参照してください。

特にメインレポジトリや AUR 以外の手段でソフトウェアをインストールしている場合は、あなたが使っているソフトウェアのリリース通知を購読することも検討すべきです。いくつかのソフトウェアには、セキュリティに関する通知を受け取るために購読できるメーリングリストがあります。ソースコードホスティングサイトはしばしば新しいリリースの RSS フィードを提供しています。

=== パッケージの再ビルド ===

攻撃対象領域を減らす手段として、パッケージをリビルドし、不要な関数や機能を削除することができます。例えば、{{Pkg|bzip2}} は [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189] を回避するために {{ic|bzip2recover}} を使わずにリビルドすることが可能です。カスタムハードニングフラグは、手動またはラッパーを介して適用することもできます。

{| class="wikitable"
! フラグ !! 目的
|-
| -D_FORTIFY_SOURCE=2 || ランタイムバッファオーバーフローの検出
|-
| -D_GLIBCXX_ASSERTIONS || C++ の文字列とコンテナのランタイム境界チェック
|-
| -fasynchronous-unwind-tables || バックトレースの信頼性向上
|-
| -fexceptions || テーブルベースのスレッドキャンセルを有効にする
|-
| -fpie -Wl,-pie || 実行可能ファイルに対する完全な ASLR
|-
| -fpic -shared || 共有ライブラリのテキスト再配置を行わない
|-
| -fplugin=annobin || ハードニング品質管理用データの作成
|-
| -fstack-clash-protection || スタックオーバーフロー検出の信頼性向上
|-
| -fstack-protector or -fstack-protector-all || スタックスマッシュプロテクター
|-
| -fstack-protector-strong || 同様に
|-
| -g || デバッグ情報を生成する
|-
| -grecord-gcc-switches || デバッグ情報にコンパイラのフラグを格納する
|-
| -mcet -fcf-protection || 制御フローの完全性保護
|-
| -O2 || 推奨される最適化
|-
| -pipe || 一時ファイルを回避し、ビルドを高速化します。
|-
| -Wall || 推奨されるコンパイラの警告
|-
| -Werror=format-security || 安全でない可能性のあるフォーマット文字列の引数を拒否する
|-
| -Werror=implicit-function-declaration || 関数プロトタイプの欠落を却下する
|-
| -Wl,-z,defs || アンダーリンクの検出と拒否
|-
| -Wl,-z,now || 遅延バインディングを無効にする
|-
| -Wl,-z,relro || 移設後の読み出し専用セグメント
|}

* [https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/ Flags and info ソース]

== 参照 ==

* [https://security.archlinux.org/ Arch Linux セキュリティトラッカー]
* ArchWiki のセキュリティアプリケーションのリスト: [[アプリケーション一覧/セキュリティ]]
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux ワークステーションのセキュリティチェックリスト]
* [https://www.privacytools.io/ privacytools.io Privacy Resources]
* [https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/index.html Red Hat Enterprise Linux 7 セキュリティガイド]
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Debian 安全化マニュアル (PDF)]
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]

Polkit

2025-12-19T06:03:56Z

Oech3: 同期/* グローバル */

{{Lowercase title}}
[[Category:セキュリティ]]
[[de:PolicyKit]]
[[en:Polkit]]
[[fr:Polkit]]
[[ru:Polkit]]
[[zh-hans:Polkit]]
{{Related articles start}}
{{Related|セッション}}
{{Related|Sudo}}
{{Related|ユーザーとグループ}}
{{Related articles end}}
[https://polkit.pages.freedesktop.org/polkit/ polkit のホームページ]より:

:''polkit は、非特権プロセスが特権プロセスと通信できるようにするポリシーを定義および操作するためのアプリケーションレベルのツールキットです: 特権操作へのアクセス許可を非特権アプリケーションに与えるかの判断を集中的に行うフレームワークになります。''

Polkit はシステム全体の権限を制御するために使われます。非特権プロセスが特権プロセスと通信するための体系化された手段を提供します。sudo などのシステムと対照的に、Polkit は1つのプロセス全体に root 権限を与えるようなことはせず、一元化されたシステムポリシーをより細かいレベルで制御することができます。

Polkit は、個々のアクション (例: GParted の実行) で区切ったり、ユーザをグループ (例: wheel グループのメンバー) や名前で区切ったりすることで機能します。そして、パスワードの入力でグループのメンバーか確認するなど、ユーザーにアクションを許可する方法を定義します。

== インストール ==

{{Pkg|polkit}} パッケージを[[インストール]]してください。

=== 認証エージェント ===

認証エージェントは、本当に本人であること、或いは管理ユーザであることをセッションのユーザに証明させるために使用されます (本人であることはユーザとして認証することによって、管理ユーザであることは管理者として認証することによって証明されます)。{{Pkg|polkit}} パッケージには 'pkttyagent' という名前のテキスト形式の認証エージェントが含まれており、一般的なフォールバックとして使われます。

グラフィカル環境を使っている場合、グラフィカルな認証エージェントをインストールし、([[xinitrc]] を使うなどして) ログイン時に[[自動起動|自動で実行]]されるようにしてください。

[[Cinnamon]]、[[Deepin]]、[[Hyprland]]、[[GNOME]]、[[GNOME Flashback]]、[[KDE]]、[[LXDE]]、[[LXQt]]、[[MATE]]、[[Xfce]] には初めから認証エージェントが入っています。
他の[[デスクトップ環境]]を使っているときは、以下の実装からどれか一つを選ぶ必要があります:
* {{AUR|hyprpolkitagent-git}}: {{ic|/usr/lib/hyprpolkitagent}} を提供
* {{Pkg|lxqt-policykit}}: {{ic|/usr/bin/lxqt-policykit-agent}} を提供
* {{Pkg|lxsession}} または {{Pkg|lxsession-gtk3}}: {{ic|/usr/bin/lxpolkit}} を提供
* {{Pkg|mate-polkit}}: {{ic|/usr/lib/mate-polkit/polkit-mate-authentication-agent-1}} を提供
* {{AUR|polkit-efl-git}}: {{ic|/usr/bin/polkit-efl-authentication-agent-1}} を提供
* {{Pkg|polkit-gnome}}: {{ic|/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1}} を提供
* {{Pkg|polkit-kde-agent}}: {{ic|/usr/lib/polkit-kde-authentication-agent-1}} を提供
* {{AUR|ts-polkitagent}}: {{ic|/usr/lib/ts-polkitagent}} を提供
* {{AUR|xfce-polkit}} または {{AUR|xfce-polkit-git}}: {{ic|/usr/lib/xfce-polkit/xfce-polkit}} を提供
* {{Pkg|pantheon-polkit-agent}}: {{ic|/usr/lib/policykit-1-pantheon/io.elementary.desktop.agent-polkit}} を提供

{{Tip|続ける前に、プロセス一覧を見て自動起動の設定をチェックしてください。例えば、{{ic|pgrep -af polkit-gnome}}。}}

== 設定 ==

{{Warning|パッケージのデフォルトのパーミッションファイルは、パッケージアップデートの際に上書きされうるので、変更しないでください。}}

Polkit の定義は2種類に分けることができます:
* '''アクション''' (Action) は {{ic|/usr/share/polkit-1/actions}} 内に XML の {{ic|.policy}} ファイルで定義されます。各アクションにはデフォルトのパーミッションがあります (例: GParted のアクションを使うには管理者として認証する必要があります)。デフォルトは上書きできますが、デフォルトのアクションファイルを編集するのは正しい方法ではありません。
* '''認可ルール''' (Authorization rule) は JavaScript の {{ic|.rules}} ファイルで定義されます。このルールは2つの場所に置かれます:
** サードパーティのパッケージは {{ic|/usr/share/polkit-1/rules.d}} を使用できます。
** {{ic|/etc/polkit-1/rules.d}} はローカル設定用です。

Polkit は Linux にある既存のパーミッションシステム (グループメンバーシップ、アドミニストレータステータス) の上で動作し、それらを置き換えるものではありません。.rules ファイルはユーザーのサブセットを指定して、アクションファイルで指定されているアクションのどれか一つ (または複数) を参照して、そのユーザーによるアクションにどのような制限をかけるか決定します。例を上げると、rules ファイルを使うことにより、GParted を使用する際に全ユーザが管理者として認証するというデフォルトの要件を上書きし、一部の特定のユーザに対しては認証を不要にできます。また別の例として、特定のユーザの GParted の使用を一切禁止することができます。

{{Note|ユーザに GParted のアクションを使えないようにする例では、polkit に判断を求めない、コマンドラインなどの方法を使って GParted を動かすことが可能です。したがって、(準)特権ユーザの権限を減らすのに使うのよりも、特権がないユーザが特権サービスにアクセスできるように権限を拡張するのに polkit を使ったほうが良いでしょう。セキュリティ目的で使うなら、[[Sudo|sudoers ファイル]]の方が適しています。}}

=== アクション ===

{{Tip|グラフィカルインターフェイスで Policykit のアクションを表示するには、{{AUR|polkit-explorer-git}} パッケージをインストールしてください。}}

polkit によって利用できるアクションはインストールしたパッケージ次第です。複数のデスクトップ環境によって使われるアクションもあれば ''(org.freedesktop.*)''、 DE 固有アクションもあり ''(org.gnome.*)''、ある一つのプログラム固有だったりもします ''(org.gnome.gparted.policy)''。{{ic|pkaction}} コマンドはクイックリファレンスとして {{ic|/usr/share/polkit-1/actions}} で定義されているアクションを全て表示します。

polkit で何ができるのかということを理解するために、一般的に使われているアクションのグループを以下に示します:
* '''[[Systemd|systemd-logind]]''' ''(org.freedesktop.login1.policy)'' のアクションには、(他のユーザーがログインしている時を含む) システムの電源オフ・再起動・サスペンド・ハイバネートが含まれています。
* '''[[udisks]]''' ''(org.freedesktop.udisks2.policy)'' のアクションには、ファイルシステムのマウントや暗号化デバイスのアンロックが含まれます。
* '''[[NetworkManager]]''' ''(org.freedesktop.NetworkManager.policy)'' のアクションには、ネットワーク、wifi、モバイルブロードバンドのオン/オフが含まれています。

それぞれのアクションは .policy ファイルの {{ic|<action>}} タグで定義されます。{{ic|org.gnome.gparted.policy}} には単一のアクションが含まれており、以下のような見た目をしています:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
<nowiki>"http://www.freedesktop.org/software/polkit/policyconfig-1.dtd"></nowiki>
<policyconfig>

<action id="org.gnome.gparted">
<message>Authentication is required to run the GParted Partition Editor</message>
<icon_name>gparted</icon_name>
<defaults>
<allow_any>auth_admin</allow_any>
<allow_inactive>auth_admin</allow_inactive>
<allow_active>auth_admin</allow_active>
</defaults>
<annotate key="org.freedesktop.policykit.exec.path">/usr/bin/gparted</annotate>
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
</action>

</policyconfig>

'''id''' 属性は実際に [[D-Bus]] に送信されるコマンド、'''message''' タグは認証が必要なときにユーザーに表示する説明、'''icon_name''' はその名の通りアイコンです。

'''defaults''' タグにはパーミッションのあるなしを記述します。次の3つの設定が含まれます: '''allow_any''', '''allow_inactive''', '''allow_active'''。inactive も active もここではローカルコンソールまたはローカルディスプレイのローカルセッションを指します。'''allow_any''' は、リモートセッション (SSH、VNV など) を含むその他全てに対して使用します。

それぞれの設定には以下のオプションを使うことができます:
* ''no'': ユーザはアクションを実行する権限を与えられません。したがって認証の必要もありません。
* ''yes'': ユーザは認証をすることなくアクションを実行することができます。
* ''auth_self'': 認証が必要ですが管理者ユーザである必要はありません。
* ''auth_admin'': 管理者ユーザーとしての認証が必須です。
* ''auth_self_keep'': auth_self と同じですが、sudo と同じように、認可の効力は数分間しか続きません。
* ''auth_admin_keep'': auth_admin と同じですが、sudo と同じように、認可の効力は数分間しか続きません。
以上がデフォルト設定であり、後の設定で覆されないかぎり、全てのユーザに対して有効です。

より詳しい説明は {{man|8|polkit}} man ページを参照してください。

GParted のアクションからわかるように、GParted を使用するには管理者としての認証を求められ、それはセッションがアクティブかそうでないかによりません。

=== 認可ルール ===

デフォルトの設定をオーバーライドする認可ルールは、(「設定」セクションの冒頭に書かれた) 上記のディレクトリ内に置かれます。単一システムの個人設定に関連する用途の場合は、{{ic|/etc/polkit-1/rules.d}} のみを使用するべきです。

{{ic|addRule()}} メソッドは、アクションと動作主体の認可チェックが行われる時に呼ばれる関数を追加するために使用されます。関数は、追加された順番で呼ばれ、それらの関数のうち1つが値を返すまでその順に呼ばれ続けます。したがって、他のルールより先に処理される認可ルールを追加するには、そのルールを {{ic|/etc/polkit-1/rules.d}} 内のファイルに置き、名前順で他のルールよりも前に来る名前を付けてください (例: {{ic|00-early-checks.rules}})。

.rules ファイルの構造は一目瞭然です:
/* admin グループ内のユーザが認証無しで GParted を実行できるようにする */
polkit.addRule(function(action, subject) {
if (action.id == "org.gnome.gparted" &&
subject.isInGroup("admin")) {
return polkit.Result.YES;
}
});

この関数内では、指定されたアクション ID ''(org.gnome.gparted)'' とユーザのグループ ''(admin)'' に対してチェックを行い、その後 "yes" の値を返します。

=== 管理者の識別 ===

{{ic|addAdminRule()}} メソッドは、管理者認証が要求された時に呼ばれる関数を追加するために使用されます。(追加する) 関数は、アクションや動作主体によって識別される認可チェックの管理者認証にどの識別子を使用するかを指定するために使用されます。追加された関数は、追加された順番で呼ばれ、それらの関数のうち1つが値を返すまでその順に呼ばれ続けます。

管理者識別子のデフォルトの設定は、{{ic|/usr/share/polkit-1/rules.d/50-default.rules}} ファイルに含まれています。なので、この設定に対する如何なる変更も、そのファイルを (例えば {{ic|/etc/polkit-1/rules.d}} ディレクトリなどに) コピーし、コピー先のファイルを編集することによって行うべきです:

{{hc|/etc/polkit-1/rules.d/50-default.rules|<nowiki>
polkit.addAdminRule(function(action, subject) {
return ["unix-group:wheel"];
});</nowiki>}}

(コピー後に) 編集すべき部分は関数の return の配列だけです: 管理ユーザとしての認証を要求された時に、ユーザは誰として認証するべきでしょうか? 管理者として指定されたグループのメンバーである場合、ユーザはそのユーザ独自のパスワードを入力するだけで良いです。ある別のユーザ (例えば root) が唯一の管理者である場合、ユーザは root のパスワードを入力する必要があります。ユーザ ID の形式は、権限を指定する時に使用するものと同じです。

Arch のデフォルトでは、'''wheel''' グループの全メンバーを管理者にします。以下のようなルールは、管理者認証の際に対象ユーザのパスワードではなく root のパスワードを polkit に尋ねさせます。

{{hc|/etc/polkit-1/rules.d/49-rootpw_global.rules|
/* 管理者を認証する際は常に root パスワードを要求する。
* sudo における rootpw オプションに似ている。
*/
polkit.addAdminRule(function(action, subject) {
return ["unix-user:root"];
});
}}

== サンプル ==

=== 特定のユーザーに org.freedesktop.timedate1.set-timezone アクションの使用を許可する ===

{{ic|archie}} という名前のユーザーに {{ic|org.freedesktop.timedate1.set-timezone}} アクションの認証なしの使用を許可するには、以下の polkit ルールを root ユーザーを使って作成してください:

{{hc|/etc/polkit-1/rules.d/49-allow-archie-set-timezone.rules|<nowiki>
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.timedate1.set-timezone" &&
subject.user == "archie") {
return polkit.Result.YES;
}
});
</nowiki>}}

このルールファイルを保存したら、ポリシーが即座に有効になるはずです。{{ic|timedatectl}} を使ってタイムゾーンを設定することでテストできます:

[archie]$ timedatectl set-timezone America/New_York

認証を求められずに操作が完了すれば、ルールが意図通りに機能していることを意味します。アクションが許可されていないような場合は、{{ic|/etc/polkit-1/rules.d/}} 内のより高い優先度を持つルール (より小さい番号のプレフィックスを持つファイル) と衝突していないか調べてください。

=== デバッグ・ログ出力 ===

{{ic|polkit.log()}} 関数でのログを有効化するには、{{ic|/usr/lib/systemd/system/polkit.service}} ファイルの {{ic|ExecStart}} コマンドから {{ic|--no-debug}} フラグを消してください。

以下のルールは要求されたアクセスの詳しい情報をログ出力します:

{{hc|/etc/polkit-1/rules.d/00-log-access.rules|<nowiki>
polkit.addRule(function(action, subject) {
polkit.log("action=" + action);
polkit.log("subject=" + subject);
});</nowiki>}}

ルールを手動でテストするには、{{ic|pkcheck}} を使用してください[https://gist.github.com/grawity/3886114]:

$ pkcheck -u -p $$ --enable-internal-agent -a ''action''

=== サスペンドとハイバネートの無効化 ===

{{Accuracy|logind が利用できない場合、{{man|8|systemctl}}{{Dead link|2024|10|13}} は代わりに {{ic|suspend.target}}/{{ic|hibernate.target}} を直接起動します。systemd-sleep を本当に無効化するには、[[電源管理/サスペンドとハイバネート#スリープを完全に無効化する]] に書かれてあるようにする必要があります。}}

以下のルールは全てのユーザーでサスペンドとハイバネートを無効化します。
{{hc|/etc/polkit-1/rules.d/10-disable-suspend.rules|<nowiki>
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.login1.suspend" ||
action.id == "org.freedesktop.login1.suspend-multiple-sessions" ||
action.id == "org.freedesktop.login1.hibernate" ||
action.id == "org.freedesktop.login1.hibernate-multiple-sessions")
{
return polkit.Result.NO;
}
});</nowiki>}}

=== パスワードプロンプトの迂回 ===

[[sudo]] の {{ic|NOPASSWD}} オプションのように[[ユーザーとグループ|ユーザー/グループ]]だけに基づいて認可をしたい場合、{{ic|/etc/polkit-1/rules.d/}} にカスタムルールを作って下さい。[[#特定のアクション|特定のアクション]]または[[#グローバル|グローバル]]でのパスワード認証を上書きすることができます。ルールセットの例は [https://gist.github.com/4013294/ccacedd69d54de7f2fd5881b546d5192d6a2bddb] を見て下さい。

==== グローバル ====

root として以下のファイルを作成:
{{hc|/etc/polkit-1/rules.d/49-nopasswd_global.rules|
/* Allow members of the wheel group to execute any actions
* without password authentication, similar to "sudo NOPASSWD:"
*/
polkit.addRule(function(action, subject) {
if (subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
}}

{{ic|wheel}} は別のグループに置き換えることができます。

上記を設定すると Polkit によって管理者権限を要求するアクションが'''すべて'''自動的に認証されます。そのため、権限を与えるグループは注意して選ぶようにしてください。

また、認可を5分間キープできるようにする {{ic|AUTH_ADMIN_KEEP}} もあります。

特に、{{ic|run0}}はpolkit 127以降で認可をデフォルトで保持します。

==== 特定のアクション ====

root として以下のファイルを作成:
{{hc|/etc/polkit-1/rules.d/49-nopasswd_limited.rules|<nowiki>
/* Allow members of the wheel group to execute the defined actions
* without password authentication, similar to "sudo NOPASSWD:"
*/
polkit.addRule(function(action, subject) {
if ((action.id == "org.gnome.gparted" ||
action.id == "org.libvirt.unix.manage") &&
subject.isInGroup("wheel"))
{
return polkit.Result.YES;
}
});
</nowiki>}}

上記のファイルでは例として {{ic|action.id}} が GParted と [[Libvirt]] の場合を載せていますが、パッケージに含まれているものや自分で作成したルールを自由に設定することができます。また、{{ic|wheel}} 以外のグループを設定することも可能です。

{{ic|<nowiki>||</nowiki>}} 演算子はアクションを区切る (論理 OR) ために使用されており、{{ic|&&}} は論理 AND を意味し、最後の演算子として残して置かなければなりません。

==== Udisks ====

ストレージデバイスをマウントするときに[[ファイルマネージャ]]がパスワードを要求することがあります。入力しないと ''Not authorized'' などのエラーが表示されます。詳しくは [[Udisks#設定]] を見て下さい。

=== 通常ユーザーに個々の systemd ユニットの管理を許可 ===

polkit のポリシーチェックに渡される値をチェックすることで、特定のユニットを管理する権限をユーザーやグループに与えることができます。例えば、標準ユーザーに [[wpa_supplicant]] を起動・停止する権限を与えたい場合:

{{hc|/etc/polkit-1/rules.d/10-wifimanagement.rules|<nowiki>
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.systemd1.manage-units") {
if (action.lookup("unit") == "wpa_supplicant.service") {
var verb = action.lookup("verb");
if (verb == "start" || verb == "stop" || verb == "restart") {
return polkit.Result.YES;
}
}
}
});</nowiki>
}}

== 参照 ==

* [https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html Polkit マニュアルページ]
* [https://doc.opensuse.org/documentation/leap/security/html/book-security/cha-security-polkit.html The Polkit authentication framework] (openSUSE Leap Security guide)

{{TranslationStatus|Polkit|2024-10-23|819084}}

KMSCON

2025-12-01T12:13:58Z

Oech3: マージされたフォークを削除/* インストール */

[[Category:ターミナルエミュレータ]]
[[en:KMSCON]]
[[zh-hans:KMSCON]]
{{Related articles start}}
{{Related|KMS}}
{{Related|systemd}}
{{Related|fbterm}}
{{Related articles end}}
[https://github.com/dvdhrm/kmscon プロジェクトの GitHub ページ]より:

:''Kmscon は linux のカーネルモード設定 (KMS) を使ったシンプルなターミナルエミュレータです。カーネルの VT 実装をユーザスペースのコンソールで置き換えようという試みです。''

== 機能 ==

Kmscon はカーネル内蔵の linux コンソールの互換品として機能します。以下の機能が存在します:

* vt220 から vt510 までの完全な実装。
* 国際化の完全サポート:
** Kmscon は CJK を含む、Unicode 文字を全て表示できます。
** Kmscon は libxkbcommon を使って国際化キーボードを扱えるため、X キーボードでサポートされている全てのキーボードレイアウトを利用することが可能です。
* ハードウェアアクセラレーションを使ったレンダリング。
* Multi-seat 可能。

{{Note|root で kmscon コンソールにログインするには、{{ic|pam_securetty}} モジュールを無効にする必要があります。{{ic|/etc/pam.d/login}} 内の適切な行を削除・コメントアウトしてください。}}

== インストール ==

KMS は kmscon に絶対必要というわけではありません。Kmscon は次のビデオバックエンドをサポートしています: fbdev (Linux fbdev ビデオバックエンド), drm2d (Linux DRM ソフトウェアレンダリングバックエンド), drm3d (Linux DRM ハードウェアレンダリングバックエンド)。あなたの環境でこの中のどれかひとつでも利用できるようにしてください。

{{AUR|kmscon}} もしくは開発版の {{AUR|kmscon-git}} をインストールしてください。

TTY1 で kmscon を使えるようにするには、以下を実行してください:
{{bc|
# systemctl disable getty@tty1.service
# systemctl enable kmsconvt@tty1.service
}}

全ての仮想端末で kmscon を有効にする場合は、root で、以下を実行してください:

{{bc|
# ln -s /usr/lib/systemd/system/kmsconvt\@.service /etc/systemd/system/autovt\@.service
}}
これで {{pkg|systemd}} がそれぞれの VT で agetty の代わりに kmscon を起動するようになります。より正確に言うと、このコマンドは systemd-logind が新しい VT で getty@.service の代わりに kmsconvt@.service を使うようにさせます。getty@.service を使っている他のユニットやスクリプトにはこの変更が適用されません。

何らかの理由で kmscon が実行できないときは、代わりに getty@.service が起動されます。そのため問題が生じても動作を継続するためのフォールバックが常に存在します。さらに、VT が利用できない場合、このユニットは何も起動しません。

{{Warning|すべてのターミナルで agetty 置き換えた場合は、マシンを再起動する前に kmscon からプロンプトが表示されることを確認してください。そうでない場合は、ライブ CD からリカバリする必要があります。}}

== CJK サポート ==

Kmscon はデフォルトのフォントエンジン {{pkg|pango}} を通して CJK 文字のレンダリングをサポートしています。ただし、モノスペースフォントのエイリアスを適切な CJK フォントにマップするよう {{pkg|fontconfig}} を設定する必要があります。日本語ユーザーは、以下のテンプレートで日本語を表示できます:
{{hc|/etc/fonts/conf.d/99-kmscon.conf|<nowiki>
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<match>
<test name="family"><string>monospace</string></test>
<edit name="family" mode="prepend" binding="strong">
<string>DejaVu Sans Mono</string>
<string>IPAGothic</string>
</edit>
</match>
</fontconfig>
</nowiki>}}
{{Pkg|ttf-dejavu}} と {{Pkg|otf-ipafont}} をインストールしてください。両方とも[[公式リポジトリ]]に含まれています。

== トラブルシューティング ==

=== Xorg と kmscon の切り替えに問題が発生する ===

[[Xorg]] と kmscon の切り替えに問題が発生する場合は ExecStart に {{ic|--hwaccel --drm}} を追加するとよいかもしれません。
ExecStart=/usr/bin/kmscon "--vt=%I" --seats=seat0 --no-switchvt --font-name Terminus --font-size 12 --hwaccel --drm

=== 音声を制御できない ===

バージョン 7 で、オーディオをコントロールできない場合、ユーザーを '''audio''' [[ユーザーとグループ#グループ管理|グループ]]に追加してください。ただしグループに追加すると[[Advanced Linux Sound Architecture#インストール|問題]]が発生します。

=== Vim で端末の出力が消去されない ===

Vim を開いたときに端末の出力が消えない場合があります。ファイルの編集は可能ですがテキストが変更するまで表示されません。回避策として、{{ic|1=TERM=vt220}} [[環境変数]]を設定してみてください。もしくは、{{Pkg|vi}} や [[Neovim]] などの vi ライクなテキストエディタを使ってください。
{{Note|{{ic|TERM}} を {{ic|vt220}} に設定した場合、カラーのサポートが利用できません。}}

=== 自動ログイン ===

これを {{ic|/etc/kmscon/kmscon.conf}} に追加することで、パスワードを要求せずにユーザーを自動的にログインさせることができます。

# Modify this command to do what you need

# Example: Login an user asking for user and password
login=/bin/bash --login

# Example: Login an user without asking for password
login=/bin/bash -c su <your_username>

=== HiDPI のサポート ===

{{ic|Ctrl++}}、{{ic|1=Ctrl+Shift+=}}、{{ic|Ctrl+-}} のショートカットを使用して、その場でフォントサイズを変更できます。また、{{ic|/etc/kmscon/kmscon.conf}} で 'font-dpi' と 'font-size' を設定することもできます。たとえば、'font-dpi=288' 288 は 96 * 3、つまり 300% のスケーリングです。96 がデフォルトです。

=== KMS コンソールからウィンドウマネージャーを起動できない ===

コマンドラインから [https://github.com/dvdhrm/kmscon/issues/65 startx] や [https://github.com/Cloudef/wlc/issues/206 sway] などを使用して Xorg や Wayland セッションを起動しようとすると失敗します。
この目的のために従来の非 KMS tty を使用するか、ログインマネージャーを利用してください。

Bcachefs

2025-10-07T14:52:33Z

Oech3: Linux 6.18からOOT/* インストール */

[[Category:ファイルシステム]]
[[en:Bcachefs]]
[[zh-hans:Bcachefs]]
{{Related articles start}}
{{Related|ファイルシステム}}
{{Related articles end}}
[https://bcachefs.org/ Bcachefs] は、[[Btrfs]] と [[ZFS]] の機能をよりクリーンなコードベース、より安定性、より高速、GPL 互換のライセンスを提供することを目的とした次世代の CoW ファイルシステムです。

[[Bcache]] は、主に Kent Overstreet によって開発されています。

== インストール ==

{{Pkg|bcachefs-tools}} と {{Pkg|bcachefs-dkms}} をインストールして下さい。

== セットアップ ==

=== シングルドライブ ===

# bcachefs format /dev/sd''X''
# mount -t bcachefs /dev/sd''X'' /mnt

=== 複数のドライブ===

Bcachefs は、RAID0 と同様に、デフォルトでデータをストライプ化します。冗長性は '''replicas''' オプションを介して処理されます。{{ic|1=--replicas=2}} を備えた 2 台のドライブは RAID1 に相当し、{{ic|1=--replicas=2}} を備えた 4 台のドライブは RAID10 に相当します。

# bcachefs format /dev/sd''X'' /dev/sd''Y'' --replicas=''n''
# mount -t bcachefs /dev/sd''X'':/dev/sd''Y'' /mnt

異種ドライブがサポートされています。サイズが異なる場合は、一部に大きなストライプが使用され、すべてが同じ割合で埋められます。速度が異なる場合、複製されたデータの読み取りは、IO 遅延が最も短いデータに送信されます。一部が他よりも信頼性が高い場合 (ハードウェア RAID デバイスなど)、{{ic|1=--durability=2 ''device''}} を設定して、そのデバイス上のデータの各コピーを 2 つの複製としてカウントできます。

=== 暗号化されたルートファイルシステム ===

Bcachefs は、ChaCha20Poly1305 を使用したファイルシステム全体の暗号化をサポートしています。暗号化されたファイルシステムをフォーマットするには、次のようにします:

# bcachefs format --encrypted /dev/sd''X''

ルートファイルシステムの場合、起動時や休止状態からの復帰時にファイルシステムの解除を求めるようにするため、{{ic|/etc/mkinitcpio.conf}} の設定ファイル内で [[Mkinitcpio#HOOKS|HOOKS]] 配列に {{ic|bcachefs}} を追加してください。

=== SSD キャッシング ===

Bcachefs には、バックグラウンド、フォアグラウンド、プロモートの3つのストレージカテゴリがあります。ファイルシステムへの書き込みでは、フォアグラウンドドライブに優先順位が付けられ、その後、時間の経過とともにバックグラウンドに移動されます。読み取りはプロモートドライブにキャッシュされます。

{{Note|これらは、単一の大規模プールに対する優先ガイドラインにすぎません。書き込みは、フォアグラウンドがいっぱいの場合はバックグラウンドに直接行われ、両方がいっぱいの場合はプロモートに行われます。メタデータはフォアグラウンドを優先しますが、どのメタデータにも書き込むことができます。キャッシュドライブにはまだデータが含まれている可能性があるため、キャッシュドライブを削除するときは注意してください。[[Bcachefs#デバイスの削除|デバイスの削除]] を参照してください。}}

推奨される設定は、フォアグラウンドとプロモートに ssd グループを使用し、バックグラウンド (ライトバックキャッシュ) に hdd グループを使用することです。

# bcachefs format \
--label=ssd.ssd1 /dev/sd''A'' \
--label=ssd.ssd2 /dev/sd''B'' \
--label=hdd.hdd1 /dev/sd''C'' \
--label=hdd.hdd2 /dev/sd''D'' \
--label=hdd.hdd3 /dev/sd''E'' \
--label=hdd.hdd4 /dev/sd''F'' \
--replicas=2 \
--foreground_target=ssd \
--promote_target=ssd \
--background_target=hdd
# mount -t bcachefs /dev/sd''A'':/dev/sd''B'':/dev/sd''C'':/dev/sd''D'':/dev/sd''E'':/dev/sd''F'' /mnt

ライトスルーキャッシュの場合は、上記と同じことを行いますが、各 SSD デバイスで {{ic|1=--durability=0 ''device''}} を設定します。
ライトアラウンドキャッシュの場合、フォアグラウンドターゲットを HDD グループに、プロモートターゲットを SSD グループに設定します。

=== マウント ===

デフォルトのマウント方法では、マウントディレクティブですべてのデバイスを指定します。

# mount -t bcachefs /dev/sd''A'':/dev/sd''B'':/dev/sd''C'':/dev/sd''D'':/

{{ic|mount.bcachefs}} コマンドは、UUID によるファイルシステムのマウントをサポートしています。
これは、ファイルシステムの作成時に {{ic|bcachefs format}} によって表示されます。

# mount.bcachefs UUID=f66d108f-83d2-4679-b50b-7d5e710f6a2b /mnt/

== 設定 ==

ほとんどのオプションは以下の方法で設定できます:

* {{ic|bcachefs format}} の実行時
* フォーマット後に {{ic|bcachefs set-fs-option}} を使用
* マウント時に {{ic|1=mount -o ''option=value''}} を指定
* または sysfs を介して、例:{{ic|echo ''X'' > /sys/fs/bcachefs/''UUID''/options/''option''}}

マウントオプションは他の方法で設定されたオプションを上書きします。これらの方法で設定されたオプションはファイルシステムのスーパーブロックに保存されます。

{{Note|sysfs を使用できるようにするには、ファイルシステムをマウントする必要があります。 fsck を除くすべての操作はライブファイルシステムで可能です。}}

使用可能なオプションの例は次の通りです:

{| class="wikitable"
|+ Bcachefs オプション
! オプション !! 説明
|-
| metadata_checksum || メタデータの書き込みに使用されるチェックサムアルゴリズムを指定します。デフォルトのアルゴリズムは ''crc32c'' です。{{ic|none}}、{{ic|crc32c}}、{{ic|crc64}}、{{ic|xxhash}} のいずれかを選択できます。
|-
| data_checksum || データの書き込みに使用されるチェックサムアルゴリズムを指定し、{{ic|metadata_checksum}} と同じデフォルトとオプションを共有します。
|-
| compression || (フォアグラウンド) 圧縮に使用するアルゴリズムを指定します。デフォルトでは、このオプションは指定されていません。{{ic|none}}、{{ic|lz4}}、{{ic|gzip}}、{{ic|zstd}} のいずれかを選択できます。
|-
| background_compression || (バックグラウンド) 圧縮に使用するアルゴリズムを指定し、{{ic|compression.}} と同じデフォルトとオプションを共有します。
|-
| str_hash || ディレクトリエントリと xattrs に使用されるハッシュ関数を指定します。{{ic|crc32c}}、{{ic|crc64}}、および {{ic|siphash}} のいずれかを選択できます。
|-
| nocow || 可能な場合は、すべての書き込みがその場で行われます。スナップショットと reflink では引き続き書き込みが COW になります。このオプションはデータのチェックサム、圧縮、暗号化を暗黙的に無効にします。
|-
| encrypted || ファイルシステム (chacha20/poly1305) で [https://bcachefs.org/Encryption/ 暗号化] を有効にします。パスフレーズの入力を求められます。
|-
|}

その他のオプションについては、[https://bcachefs-docs.readthedocs.io/en/latest/options.html bcachefs ドキュメント] を参照してください。

以下は、{{ic|1=bcachefs setattr ''file'' --option=value}} を使用して、ディレクトリごとまたはファイルごとに設定することもできます。ディレクトリにオプションを設定すると、再帰的にオプションが伝播されます。

{{Note|rebalance thread はまだバックグラウンドで replicas を調整していません。つまり、ファイルの replicas オプションを変更する場合は、手動で rereplicate コマンドを実行して、古いファイルが新しいルールに従っていることを確認する必要があります。}}

* data_replicas
* data_checksum
* compression, background_compression
* foreground_target, background_target, promote_target

どのオプションがアクティブであるかを確認するには、{{ic|getfattr -d -m 'bcachefs_effective\.' ''directory/file''}} を実行します。

{{Note|ディスク使用量レポートは現在、非圧縮サイズを表示しています。それ以外は圧縮が完了しています。}}

=== デバイスのグループの変更 ===

# echo ''group'' > /sys/fs/bcachefs/''filesystem_uuid''/dev-''X''/label

{{Note|これを有効にするには、再マウントが必要です。}}

=== デバイスの追加 ===

# bcachefs device add --group=''group'' /mnt /dev/''device''

これがグループ内の最初のドライブである場合は、それを使用するためにターゲット設定を変更する必要があります。この例は、キャッシュドライブを追加するためのものです。

# echo ''new_group'' > /sys/fs/bcachefs/''filesystem_uuid''/options/promote_target
# echo ''new_group'' > /sys/fs/bcachefs/''filesystem_uuid''/options/foreground_target
# echo ''old_group'' > /sys/fs/bcachefs/''filesystem_uuid''/options/background_target

{{Note|追加されたデバイス間でストライピングされるのは新しい書き込みのみです。ディスクのリバランスがトリガーされると、ディスク使用量が特定のしきい値に達するまで、既存のものは変更されません。現在、リバランス/リストライプを手動でトリガーすることはできません。}}

=== デバイスの削除 ===

まず、少なくとも 2 つのメタデータのレプリカがあることを確認します (Evacuate はメタデータに対して機能していないようです) データとメタデータがすでに複製されている場合は、この手順をスキップできます。

# echo 2 > /sys/fs/bcachefs/''UUID''/options/metadata_replicas
# bcachefs data rereplicate /mnt
# bcachefs device set-state ''device'' readonly
# bcachefs device evacuate ''device''

デバイスを削除します:

# bcachefs device remove ''device''
# bcachefs data rereplicate /mnt

=== レプリケーション ===

メタデータとデータのレプリカは、ユーザーが望む冗長性のレベルに応じて個別に設定できます。レプリカに関連するオプションは 5 つあります。

* {{ic|1=--replicas=X}} メタデータとデータのレプリカの数を同時に設定します。
* {{ic|1=--metadata_replicas=X}} 最終的に書き込まれるメタデータのレプリカの数を設定します。
* {{ic|1=--data_replicas=X}} 最終的に書き込まれるデータレプリカの数を設定します。
* {{ic|1=--metadata_replicas_required=X}} メタデータが "書き込まれた" とみなされる前に書き込む必要があるメタデータのレプリカの数を設定します。
* {{ic|1=--data_replicas_required=X}} データが "書き込まれた" とみなされる前に書き込む必要があるデータレプリカの数を設定します。

{{Note|{{ic|--[meta]data_replicas_required}} と {{ic|--[meta]data_replicas}} の区別は重要で、replicas required 値はすぐに書き込まれるレプリカの数のフロアを設定するのに対し、replicas 値は最終的に書き込まれるレプリカの目標数を設定します。
}}

=== 圧縮 ===

圧縮は、{{ic|1=--compression=}} オプションで設定します。圧縮レベルの設定も可能です。zstd 圧縮レベル 5 を設定する例、{{ic|1=--compression=zstd:5}}

=== サブボリューム ===

Bcachefsは、[[Btrfs#Subvolumes|Btrfs]] と同様のユーザースペースインターフェースを使用してサブボリュームとスナップショットをサポートしています。新しいサブボリュームは空の状態で作成することも、別のサブボリュームのスナップショットとして作成することもできます。スナップショットは書き込み可能で、さらにスナップショットを作成することもでき、スナップショットのツリー構造を形成します。

スナップショットの作成は非常に低コストです。[[Btrfs#Subvolumes|Btrfs]] のように COW(Copy-On-Write)Bツリーのクローンに基づいているのではなく、Bツリー内の個々のキーのバージョン管理に基づいています。何千、何百万ものスナップショットを作成することが可能で、唯一の制限はディスクスペースです。

==== サブボリュームの作成 ====

新しい空のサブボリュームを作成するには:

# bcachefs subvolume create ''/path/to/subvolume''

==== サブボリュームの削除 ====

既存のサブボリュームやスナップショットを削除するには:

# bcachefs subvolume delete ''/path/to/subvolume''

==== 既存のサブボリュームのスナップショットを作成する ====

既存のサブボリュームのスナップショットを作成するには、次の手順を実行します。

# bcachefs subvolume snapshot ''/path/to/source'' ''/path/to/dest''

{{ic|rm -rf}} のように、すべての内容を削除した後、通常の rmdir を使用してサブボリュームを削除することもできます。

再帰的なスナップショットの作成やサブボリュームを再帰的にリストする方法などの機能はまだ実装されていません。

== ヒントとテクニック ==

さらに有用なエラーメッセージについては、[[systemd/ジャーナル|ジャーナル]]を確認してください。

=== フラグの順序 ===

一部の {{ic|bcachefs format}} フラグは、引数の順序に基づいて設定され、フラグが切り替えられた後のドライブにのみ影響します。たとえば、SSD に {{ic|1=--durability=0}} を持たせて {{ic|--discard}} を有効にし、HDD ではデフォルトを使用する場合は、引数が次の順序で渡されるようにしてください。

# bcachefs format \
--label=hdd.hdd1 /dev/sd''C'' \
--label=hdd.hdd2 /dev/sd''D'' \
--label=hdd.hdd3 /dev/sd''E'' \
--label=hdd.hdd4 /dev/sd''F'' \
--durability=0 --discard \
--label=ssd.ssd1 /dev/sd''A'' \
--label=ssd.ssd2 /dev/sd''B'' \
--replicas=2 \
--foreground_target=ssd \
--promote_target=ssd \
--background_target=hdd

=== フォーマット後のレプリカの設定 ===

{{ic|set-fs-option}} を使用して、フォーマット後にレプリカ数を設定することができます。

# bcachefs set-fs-option --metadata_replicas=''2'' --data_replicas=''2'' /dev/sd''X''

その後、すべてのファイルに次のレプリカが存在することを確認するように bcachefs に指示する必要があります。

# bcachefs data rereplicate /mnt

== トラブルシューティング ==

=== 32-ビットプログラムがディレクトリの内容を認識しない ===

一部の 32-ビットプログラムは、{{man|3|readdir}} syscall の実行時にファイルシステムから返されるデータの非互換性により、Bcachefs 内のディレクトリの内容の取得に失敗する場合があります。[https://github.com/koverstreet/bcachefs/issues/650]

この問題は、そのようなプログラムの読み書きに [[tmpfs]] などの別のファイルシステムを一時的に使用することで回避できます。

=== スワップファイルにはサポートされていないエクステントが含まれています ===

Bcachefs は現在 [https://github.com/koverstreet/bcachefs/issues/368 swapfiles] をサポートしていません。

=== マルチデバイス fstab ===

現在、[https://github.com/systemd/systemd/issues/8234 systemd のバグ] があり、fstab でコロンで区切られたデバイスを使用して起動時にマルチデバイス bcachefs ファイルシステムをマウントできません。 mount -a を実行すると機能しますが、起動時にはマウントされません。ただし、bcachefs-tools バージョン 1.7.0 以降では、1 つのデバイスノードを使用してマルチデバイスアレイをマウントできるようになりました。これにより、通常の {{ic|1=UUID=}} 指定子の使用が可能になります。

# UUID=10176fc9-c4fa-4a30-9fd0-a756d861c4cd /mnt bcachefs defaults,nofail 0 0

ファイルシステム UUID / 外部 UUID は、次のいずれかを使用して見つけることができます:

# bcachefs fs usage
# bcachefs show-super device

=== 暗号化されたデバイスのマウントエラー ===

{{ic|--encrypted}} オプションで作成されたデバイスのマウントが、{{ic|bcachefs locked /dev/sd''XY''}} の後に失敗した場合
ERROR - bcachefs::commands::cmd_mount: Fatal error: Required key not available

これは、キーをセッション [https://lore.kernel.org/all/6018852.lOV4Wx5bFT@lichtvoll.de/] に手動でリンクすることで回避できます:

# keyctl link @u @s
# mount /dev/sd''XY'' /mnt
Enter passphrase:

''mount'' によって照会されるパスフレーズを新たに入力する必要はありません ({{ic|Enter}} を押すだけで十分です。)

== 参照 ==

* [https://bcachefs.org/bcachefs-principles-of-operation.pdf 公式マニュアル]
* [https://www.patreon.com/bcachefs Kent Overstreet's Patreon page]
* [[Wikipedia:Bcachefs]]
* [https://bcachefs-docs.readthedocs.io/en/latest/introduction.html bcachefs on ReadTheDocs]

Chromium

2025-10-05T15:31:06Z

Oech3: fix templete/* ネイティブ Wayland サポート */

[[Category:ウェブブラウザ]]
[[Category:Google]]
[[de:Chromium]]
[[en:Chromium]]
[[zh-hans:Chromium]]
{{Related articles start}}
{{Related|ブラウザ拡張機能}}
{{Related|Firefox}}
{{Related|Vivaldi}}
{{Related articles end}}

[[Wikipedia:ja:Chromium|Chromium]] は、[[Wikipedia:ja:Blink (レンダリングエンジン)|Blink]] レンダリングエンジンをベースとした、オープンソースなグラフィカルウェブブラウザです。プロプライエタリな Google Chrome ブラウザの基礎となっています。

Chromium と Google Chrome との違いについては [https://chromium.googlesource.com/chromium/src/+/master/docs/chromium_browser_vs_google_chrome.md このページ] を見てください。さらに:

* 同期は Chromium 89 以上 (2021-03-02) で利用できません。[https://archlinux.org/news/chromium-losing-sync-support-in-early-march/]

{{Note|同期は、[https://gist.github.com/foutrelis/14e339596b89813aa9c37fd1b4e5d9d5 Chrome の OAuth2 認証情報を使用する]か、[https://www.chromium.org/developers/how-tos/api-keys 自分の認証情報を取得する]ことで一時的に利用可能にできますが、免責事項に注意し、この方法を長期的な解決策と考えないでください。
長期的な解決策としては、ブックマークの同期するための [https://www.xbrowsersync.org xbrowsersync] に移行することを検討してください。}}

他の Chromium ベースのブラウザは [[アプリケーション一覧/インターネット#Blink ベース]] を見てください。

== インストール ==

Chromium を[[インストール]]できるパッケージがいくつか存在します:

* {{Pkg|chromium}} — 安定版
* {{AUR|chromium-dev}} — 開発版
* {{AUR|chromium-snapshot-bin}} — nightly ビルド

Google Chrome のパッケージは:

* {{AUR|google-chrome}} — 安定版
* {{AUR|google-chrome-beta}} — ベータ版
* {{AUR|google-chrome-dev}} — 開発版
* {{AUR|google-chrome-canary}} — カナリアリリース

{{Note|[https://www.chromium.org/Home/chromium-privacy Chromium プライバシーページ]によると(日本語訳):「Chromium のソースコードをコンパイルすることで利用可能になる Google と通信する機能は、[https://www.google.com/policies/privacy/ Google プライバシーポリシー]に従います。」Google サービスとの統合をすべて避けたい人向けに[[アプリケーション一覧/インターネット#プライバシー重視の chromium 派生版|プライバシー重視の Chromium 派生版]]があります。}}

== 設定 ==

=== デフォルトアプリケーション ===

Chromium をデフォルトのブラウザに設定したり、ダウンロードしたファイルを開くときに Chromium がどのアプリケーションを起動するかを変更したりするには、[[デフォルトアプリケーション]] を見てください。

=== 証明書 ===

Chromium は証明書の管理に [[Network Security Services]] を使っています。{{ic|chrome://settings/certificates}} で証明書を管理できます。

=== フラグを永続化する ===

{{Note|{{ic|chromium-flags.conf}} ファイルとそれに付随するカスタムランチャースクリプトは、Arch Linux の様々な Chromium パッケージに固有のものです。Google Chrome に対しては、代わりに {{ic|chrome-flags.conf}} (開発版やベータ版の場合は {{ic|chrome-''チャネル名''-flags.conf}}) を使用してください。}}

フラグは、{{ic|$HOME/.config/}} 内 ({{ic|$XDG_CONFIG_HOME}} 環境変数を設定した場合は、その環境変数が示すディレクトリの中) の {{ic|chromium-flags.conf}} ファイルに記述することができます。グローバルに設定したい場合は、{{ic|/etc/}} 内に配置できます。

特別な構文は使用されず、フラグはターミナルに書き込まれるのと同じように定義されます。

* 引数は空白で分割され、シェルの引用符の規則が適用されますが、それ以上の解析は実行されません。
* ファイル中のどこかが不適切に引用符によって囲まれている場合、致命的なエラーが発生します。
* フラグは読みやすくするために個別の行に分けることができますが、これは必須ではありません。
* ハッシュ記号 (#) で始まる行は読み飛ばされます。(これは Chromium のランチャースクリプトでのみサポートされており、Google Chrome を使用している場合は動作しません。)

以下は、フラグ {{ic|--start-maximized --incognito}} を定義している {{ic|chromium-flags.conf}} ファイルの例です:

{{hc|~/.config/chromium-flags.conf|
# この行は無視されます。
--start-maximized
--incognito
}}

=== GPU アクセラレーションを強制する ===

少なくとも Chromium 110 から、ほとんどのシステムに対して GPU アクセラレーションがデフォルトで有効化されています。あなたのシステム構成が[https://chromium.googlesource.com/chromium/src/gpu/+/master/config/software_rendering_list.json ブラックリスト]と合致する場合、以下のフラグを[[#フラグを永続化する|永続的な設定]]に[[追加]]する必要があります:

{{Warning|レンダリングブラックリストを無効化すると、ホストのクラッシュなどの不安定な挙動を引き起こすかもしれません。詳細については {{ic|chrome://gpu}} にあるバグレポートを見てください。}}

{{hc|~/.config/chromium-flags.conf|
--ignore-gpu-blocklist
--enable-zero-copy
}}

=== ハードウェアビデオアクセラレーション ===

{{Note|1=<nowiki/>
* この機能に対する Chromium や Arch Linux からの公式サポートはありません [https://chromium.googlesource.com/chromium/src/+/master/docs/gpu/vaapi.md#vaapi-on-linux]。しかし、公式リポジトリの {{Pkg|chromium}} は VA-API サポートありでコンパイルされており、[https://bbs.archlinux.org/viewtopic.php?id=244031 専用のフォーラムスレッド]で助けを求めることができます。
* Chromium バージョン 122 から、追加の [[VA-API]] のパッケージはもはや必要なくなりました。公式リポジトリの {{Pkg|chromium}} パッケージでネイティブな Wayland バックエンドを使用している場合、VA-API は動作します。
* AMD GPU デバイス上では、VA-API は[https://crbug.com/1445074 そのままでは動作しません]。動作させるには mesa >= 24.1 が必要であり、[https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26165 Vulkan を有効化する]必要があります。これによって、X11/XWayland で WebGL の問題が発生する場合があります。[[#ネイティブ Wayland サポート|ネイティブ Wayland サポートでの]] Vulkan はバージョン 125.0.6422.141-1 から動作します。
}}

{{Note|1=<nowiki/>
{{ic|chromium-flags.conf}} の適切なフラグの組み合わせを見つけようとしているのであれば、このファイルには {{ic|--enable-features}} や {{ic|--disable-features}} で始まる行はそれぞれ多くとも1行しか含むことができないことに注意してください。複数の機能はコンマで繋げることができます。
}}

{{ic|1=vainfo}} ([[ハードウェアビデオアクセラレーション#VA-API の確認]] を参照) の出力を見て VA-API のサポートがあることを確認した場合は、ひとまず以下のフラグだけで試してみてください:

{{hc|~/.config/chromium-flags.conf|2=
--enable-features=AcceleratedVideoDecodeLinuxGL
}}

{{Note|バージョン 131 より前の Chromium では、上記のフラグではなく {{ic|1=--enable-features=VaapiVideoDecodeLinuxGL}} を使用する必要があります。}}

それ以外の場合は、以下も読んでください。

Chromium でアクセラレートされた'''エン'''コードを有効化するには:

* {{ic|AcceleratedVideoEncoder}} を features に追加してください (例: {{ic|1=--enable-features=AcceleratedVideoDecodeLinuxGL,AcceleratedVideoEncoder}})。詳細は、[https://github.com/chromium/chromium/blob/main/docs/gpu/vaapi.md#vaapi-on-linux] と [https://issues.chromium.org/issues/40225939#comment54] を読んでください。

VA-API サポートを有効にするには:

* 使用中のビデオカード用の適切な VA-API ドライバをインストールしてください。そして、VA-API が有効化されて正常に動作していることを確認してください。[[ハードウェアビデオアクセラレーション]]を見てください。プロプライエタリな NVIDIA サポートは、{{Pkg|libva-nvidia-driver}} をインストールする必要があります。
* {{ic|1=--enable-features=VaapiVideoDecoder}} オプションを設定してください。ANGLE GL レンダラーと {{Pkg|libva-intel-driver}} を使用している場合は、これで十分です。
* ANGLE を使用すると、{{Pkg|intel-media-driver}} が使用されている場合、Chromium は古い i965 ドライバを強制的に使用し失敗します。回避策として、[[ハードウェアビデオアクセラレーション#VA-API の設定|VA-API を手動で設定]]してください。詳細については [https://github.com/intel/media-driver/issues/818] を見てください。
* Xorg か Wayland でシステムの GL レンダラを使用するには、{{ic|1=--use-gl=egl}} を使用してください。Chrome 112 を使用している場合、このオプションはもはや必要ないかもしれず、AMD GPU を使用している場合は GPU アクセラレーションの機能が壊れる場合があります。
* VA-API がまだ動かない場合は、{{ic|1=--enable-features=VaapiIgnoreDriverChecks}} か {{ic|1=--disable-features=UseChromeOSDirectVideoDecoder}} フラグを試してください。
* VA-API が Xorg と古い GPU 上でまだ動かない場合は、{{ic|1=LIBVA_DRI3_DISABLE=1}} [[環境変数]]を設定してください [https://www.phoronix.com/news/VA-API-libva-2.18]。

==== Vulkan ====

Vulkan を使用する場合、以下のフラグが必要で、Chromium 126 と Mesa 24.1 ではこれで十分でしょう:

{{hc|~/.config/chromium-flags.conf|2=
--enable-features=VaapiVideoDecoder,VaapiIgnoreDriverChecks,Vulkan,DefaultANGLEVulkan,VulkanFromANGLE
}}

先述の追加のフラグは入れないでください。

==== ヒントとテクニック ====

{{Out of date|
* Wayland + RADV の環境では Chromium は AV1 に VaapiVideoDecoder を使用します。
* Wayland + RADV の環境では Chromium は全てのサイスの動画に VaapiVideoDecoder を使用します。
}}

使用中の VA-API ドライバでサポートされているコーデックの動画の視聴がうまく行くかどうか確認するには (''vainfo'' はどのコーデックがサポートされているかを表示しますが、Chromium は VP9 と h264 だけをサポートします):

* {{ic|Ctrl+Shift+I}} を押すか、コンテキスト (右クリック) メニューの ''検証'' ボタンを押して DevTools を開いてください
* Media inspection タブを追加してください: ''ハンバーガーメニュー(︙) > More tools > Media''
* 新しく開いた Media タブで、Video Decoder の Hardware decoder の状態を見てください。

十分に大きな動画でテストしてください。バージョン 86 から、デスクトップ版の Chromium は [https://bugs.chromium.org/p/chromium/issues/detail?id=684792 720p よりも大きい動画でしかアクセラレーションを使用しません]。

VP8/VP9 ハードウェアデコードが使用できない Youtube 動画を視聴しているときに CPU 使用率を減らすには、[https://chrome.google.com/webstore/detail/h264ify/aleakchihdccplidncghkekgioiakgal h264ify] や [https://chrome.google.com/webstore/detail/enhanced-h264ify/omkfmpieigblcllmkgbflkikinpkodlk enhanced-h264ify]、[https://chrome.google.com/webstore/detail/not-yet-av1/dcmllfkiihingappljlkffafnlhdpbai Not yet, AV1][https://bbs.archlinux.org/viewtopic.php?pid=2039884#p2039884] 拡張機能を使用してください。

一部のシステム (特に Xwayland) では、[[#GPU アクセラレーションを強制する]] 必要があるかもしれません。このセクションでの目的に対しては {{ic|--ignore-gpu-blocklist}} のみで十分です。

Skia レンダラーは、現在ビデオデコードアクセラレーションと互換性がないので、無効化する必要があるかもしれません: {{ic|1=--disable-features=UseSkiaRenderer}}

=== KDE 統合 ===

[[Plasma]] との統合は {{Pkg|plasma-browser-integration}} を[[インストール]]してください。詳細は [https://community.kde.org/Plasma/Browser_Integration KDE Plasma Browser Integration] を見てください。

=== PDF ビューアプラグイン ===

Chromium と Google Chrome には ''Chromium PDF Viewer'' プラグインがバンドルされています。このプラグインを使用したくない場合は、{{ic|chrome://settings/content/pdfDocuments}} 内の ''Download PDFs'' を確認してください。

=== Xwayland での動作 ===

NVIDIA 社のプロプライエタリドライバを使用している場合、Xwayland 上で Chromium を実行すると、GPU プロセスが時々クラッシュすることがあります。GPU プロセスがクラッシュしないようにするには、以下のフラグを追加してください:

--use-angle=vulkan --use-cmd-decoder=passthrough

{{Note|これはすべての Xwayland 関連のクラッシュを防止するわけではありません。}}

=== ネイティブ Wayland サポート ===

Chromium 140では、デフォルトで[[Wayland]]をサポートします。
古いバージョンでは{{ic|1=--ozone-platform-hint=auto --enable-wayland-ime --wayland-text-input-version=3}}が必要でした。

追加で、[https://bugs.chromium.org/p/chromium/issues/detail?id=1422087 インプットメソッドの問題]が発生している場合は、新しい GTK を強制すると良いかもしれません:

--gtk-version=4

{{Note|{{ic|text_input_v1}} プロトコルがデフォルトで実装されている場合、{{ic|--enable-wayland-ime}} フラグは機能します。このプロトコルを実装している既知のコンポジタは Weston、KWin、Hyprland です。}}

==== ナビゲーションのタッチパッドジェスチャ ====

2本の指でスワイプすると戻ったり進んだりする機能を有効にするには、以下のフラグを使用してください:

--enable-features=TouchpadOverscrollHistoryNavigation

== ヒントとテクニック ==

特に注意書きがなければ以下のヒントとテクニックは Chromium と Chrome の両方で使うことができます。

=== ブラウズのエクスペリエンス ===

==== chrome:// URL ====

多くの調整は Chrome の URL からアクセスすることができます。完全なリストは '''chrome://chrome-urls''' を参照してください。

* '''chrome://flags''' - WebGL などの実験的な機能や GPU によるウェブページのレンダリングなどにアクセスできます。
* '''chrome://extensions''' - 現在使用している Chromium 拡張を表示・有効化・無効化。
* '''chrome://gpu''' - 様々な GPU オプションの状態。
* '''chrome://sandbox''' - サンドボックスの状態を表示。
* '''chrome://version''' - バージョンや {{ic|/usr/bin/chromium}} を実行するときに使われたスイッチを表示。

Chromium のスイッチ (コマンドラインパラメータ) の自動的に更新される完全なリストが [https://peter.sh/experiments/chromium-command-line-switches/ こちら] にあります。

==== Chromium タスクマネージャ ====

Shift+ESC でブラウザのタスクマネージャを立ち上げることができます。メモリや CPU、ネットワークの使用量が閲覧可能です。

==== Chromium が Preferences ファイルを上書き/オーバーライドしてしまう ====

Google アカウントの同期を有効にしている場合、{{ic|~/.config/chromium/Default/Preferences}} 下の Preferences ファイルに直接編集を加えていても Chromium によって上書きされてしまいます。上書きされないようにするには、{{ic|--disable-sync-preferences}} スイッチを付けて Chromium を起動してください:
$ chromium --disable-sync-preferences

デスクトップ環境のログイン時にバックグラウンドで Chromium を起動する場合、デスクトップ環境から使用するコマンドを以下のようにしてください:
$ chromium --disable-sync-preferences --no-startup-window

==== 検索エンジン ====

[https://wiki.archlinux.org wiki.archlinux.org] や [https://en.wikipedia.org wikipedia.org] などのウェブサイトは検索を実行してから ''Settings > Search'' を選択して ''Manage search engines..'' ボタンをクリックすることで簡単に検索できるように設定できます。エントリを "Edit" してキーワードを '''w''' などに変更してください (ショートカットは自由に決めて下さい)。これでアドレスバーに "'''w arch linux'''" と入力するだけで "Arch Linux" で検索できるようになります。

{{Note|URL バーに何か入力すると自動的に Google 検索が使われます。また、ハードコードされたキーワードトリガとして '''?''' プレフィックスが使えます。}}

==== Tmpfs ====

===== tmpfs にキャッシュ =====

{{Note|Chromium はブラウザのプロファイルディレクトリとキャッシュディレクトリを分離して保存します。}}

物理ディスクに対する Chromium のキャッシュの書き込みを制限したい場合、{{ic|--disk-cache-dir}} フラグでキャッシュの書き込み先を変更することができます:

$ chromium --disk-cache-dir="$XDG_RUNTIME_DIR/chromium-cache"

キャッシュは一時的になり、再起動したりハードロックすると'''消えます'''。もしくは、tmpfs 領域を {{ic|/etc/fstab}} 内でセットアップすることもできます:

{{hc|/etc/fstab|2=
tmpfs /home/''username''/.cache tmpfs noatime,nodev,nosuid,size=400M 0 0
}}

または、{{ic|/tmp}} へのシンボリックリンクを作成してください。以下のコマンドを実行する前に、Chromium のキャッシュフォルダは削除しておいてください:

$ ln -s /tmp /home/''ユーザ名''/.cache/chromium

また、全てのアプリケーションで有効な[[XDG_Base_Directory#ユーザーディレクトリ|XDG_CACHE_HOME]]もあります。

===== tmpfs にプロファイル =====

{{ic|/tmp}} や {{ic|/dev/shm}} などの [[Wikipedia:ja:Tmpfs|tmpfs]] ファイルシステムにプロファイルを保存することで、プロファイル全体が RAM 内に保存されるので、Chromium の応答性が改善されます。

{{Pkg|profile-sync-daemon}} などの、プロファイルを動的に管理するスクリプトを使うことで信頼性と使いやすさを最大限高めることができます。profile-sync-daemon はブラウザプロファイルのディレクトリのシンボリックリンクを作成し、定期的にメモリと同期をとります。詳細については [[Profile-sync-daemon]] の記事を参照して下さい。

==== 新しいブラウザインスタンスを起動 ====

ブラウザを起動すると、最初に同じプロファイルを使っているインスタンスが他にないか確認されます。存在する場合、新しいウィンドウは既存のインスタンスに関連付けられます。以下のように {{ic|--user-data-dir}} パラメータを使って起動することで別のプロファイルでブラウザを起動できます:

$ chromium --user-data-dir=''/path/to/some/directory''

{{Note|ユーザーデータのデフォルトパスは {{ic|~/.config/chromium/}} です。}}

==== torrent クライアントで *.torrent ファイルやマグネットリンクを直接開く ====

デフォルトでは Chromium は {{ic|*.torrent}} ファイルを直接ダウンロードするため、ファイルを torrent クライアントで開くには画面左下の通知をクリックする必要があります。以下の方法で毎回クリックする手間を省けます:

* {{ic|*.torrent}} ファイルをダウンロード。
* 画面左下に表示される通知を右クリック。
* "Always Open Files of This Type" チェックボックスにチェックを入れる。

デフォルトの関連付けの変更については [[xdg-open]] を見てください。

==== タッチスクリーンデバイスでタッチスクロール ====

使用するタッチデバイスを指定する必要があります。タッチスクリーンデバイスを {{ic|xinput list}} で確認して、{{ic|1=--touch-devices='''x'''}} パラメータを付けて Chromium を起動してください ("'''x'''" はデバイスの id に置き換えてください)。
{{Note|スレーブポインタのデバイスは使えません。マスターポインタの ID を使ってください。}}

==== メモリの使用量を減らす ====

デフォルトでは、Chromium は開いているウェブサイトの数だけ OS プロセスを作成します [https://www.chromium.org/developers/design-documents/process-models#Supported_Models]。Chromium の起動時にコマンドラインスイッチを指定することで挙動を変更することが可能です。

例えば、全てのウェブサイトでひとつのプロセスを共有するには:

$ chromium --process-per-site

シングルプロセスモデルを使うには:

$ chromium --single-process

{{Warning|シングルプロセスモデルは安全でなく他のモデルに存在しないバグが含まれている可能性があるため推奨されていません [https://www.chromium.org/developers/design-documents/process-models#TOC-Single-process]。}}

さらに [https://chrome.google.com/webstore/detail/tab-suspender/fiabciakcmgepblmdkmemdbbkilneeeh?hl=en Tab Suspender] や [https://chrome.google.com/webstore/detail/onetab/chphlpgkkbolifaimnlloiipkdnihall?hl=en OneTab] などの拡張を使うことでアクティブでないタブを停止・保存することができます。

==== ユーザーエージェント ====

Chromium の起動時に {{Ic|<nowiki>--user-agent="[string]"</nowiki>}} パラメータを指定することでユーザーエージェントは任意に変更することができます。

==== DOM Distiller ====

Chromium には Firefox にあるのと似たレンダリングモードが存在します。これは DOM Distiller と呼ばれ、[https://github.com/chromium/dom-distiller オープンソースプロジェクト]です。
デフォルトでは無効化されていますが、{{Ic|chrome://flags/#enable-reader-mode}} フラグを使用することにより有効化できます。このフラグは[[#フラグを永続化する|永続化]]させることができます。
DOM Distiller は、ページのコンテンツから不要なものを取り除くことでより良いレンダリングエクスペリエンスを提供するだけでなく、印刷用にページを単純化してくれます。後者のチェックボックスオプションが印刷ダイアログから削除されたものの、不要なものを取り除いたページを印刷することは依然として可能です。これらには、基本的には同じ効果があります。

フラグを有効化すると、ウェブサイトから不要なものを取り除くことができると Chromium が判断したときに、"Enter reader mode" メニューアイテムとアイコンがアドレスバーに出現します。

==== 特定の GPU の使用を強制する ====

GPU が複数ある環境の場合、Chromium はレンダリングに使用する GPU (ディスクリートや統合 GPU) を自動的に検出します。99% は問題ありませんが、誤った GPU が選択された場合 (VFIO GPU パススルー環境でディスクリートグラフィックが選ばれるなど)、{{ic|chrome://gpu}} は GPU プロセスを初期化できないというエラーを吐きます。同じページの '''Driver Information''' には複数の GPU が表示されます (GPU0, GPU1, ...)。ユーザーフレンドリな方法で GPU を切り替えることはできませんが、デバイス/ベンダー ID を使って Chromium のフラグで使用する GPU を設定できます:

$ chromium --gpu-testing-vendor-id=0x8086 --gpu-testing-device-id=0x1912

{{ic|0x8086}} と {{ic|0x1912}} は使用したい GPU の ID に置き換えてください ({{ic|chrome://gpu}} ページで確認できます)。

==== Firefox からブックマークをインポート ====

[[Firefox]] から Chromium にブックマークをインポートすることができます。

Chromium で {{ic|chrome://settings/importData}} を開いてください。

コンピュータに Firefox がインストールされている場合、直接 Firefox からブックマークなどをインポートできます。

'''Mozilla Firefox''' を選択してください。不要なアイテムのチェックは外してかまいません。'''Import''' をクリックしてから '''Done''' をクリックすればインポートは完了です。

{{note|Chromium でまだ何もブックマークを作成していない場合、ブックマークバーにブックマークが表示されます。既にブックマークが存在する場合、ブックマークは "Imported From Firefox" というラベルが付いた新しいフォルダに保存されます。}}

他の PC からブックマークをインポートする場合、先に Firefox からブックマークをエクスポートする必要があります。

Firefox で {{ic|Ctrl+Shift+o}} ''Import and Backup > Export Bookmarks To HTML'' を選択してください

後の作業は同じです。{{ic|chrome://settings/importData}} を開いてください。ただし今度は '''From''' ドロップダウンメニューで '''Bookmarks HTML File''' を選択して '''Choose File''' ボタンをクリックしてブックマークファイルをアップロードします。

後の作業は同じです。{{ic|chrome://settings/importData}} を開いてください。ただし今度は '''From''' ドロップダウンメニューで '''Bookmarks HTML File''' を選択して '''Choose File''' ボタンをクリックしてブックマークファイルをアップロードします。

==== ネイティブ通知の有効化 ====

{{ic|chrome://flags#enable-system-notifications}} を開いて、''Enabled'' を選択してください。

==== マウスの中ボタンでの自動スクロールを有効化する ====

自動スクロールはまだ試験的な機能です [https://niek.github.io/chrome-features/]。開発版ビルドでない Chromium または Chromium ベースのブラウザで、Linux 環境で動作させている場合は、デフォルトで無効化されています。[https://issues.chromium.org/issues/40811836]

この機能を有効化するには、ブラウザを {{ic|1=--enable-features=MiddleClickAutoscroll}} フラグで起動してください。このオプションを永続化させたい場合は、[[#フラグを永続化する]] を見てください。

{{Note|
* {{ic|--enable-blink-features}} は {{ic|--enable-features}} と同じように動作しますが、ブラウザが、このフラグはサポートされておらず、安定性とセキュリティが損なわれると警告を表示することがあります。
* 代替策として Chrome Web Store から似たような機能を持つ [https://chromewebstore.google.com/detail/wheely-wheel-scroll-for-l/kkmfljfnlmppiaoijkfaejgkhccokpdn WHEELY] のような拡張機能を追加することもできます。
}}

{{Tip|もう一つの手段は、{{AUR|chromium-extension-autoscroll}} です。しかし、このパッケージは古くなっており、公式ではないため、推奨されていません。使用する場合は注意してください。}}

==== U2F 認証 ====

{{Pkg|libfido2}} ライブラリをインストールしてください。このパッケージは、(通常) ユーザとして [[U2F]] キーにアクセスできるようにするために必要な udev ルールを提供します。
U2F キーはデフォルトでは root としてしかアクセスできないので、これらのルールが無いと Chromium はエラーを吐きます。

==== テーマ ====

Chromium に現在の GTK テーマをブラウザメニューやコントロールで使用させることができます。{{ic|chrome://settings/appearance}} で ''Use GTK'' を押してください。

==== ダークモード ====

Chromium 114 から、ユーザの優先外観を自動的に決定するために [[XDG デスクトップポータル]] が使用されるようになりました ([https://bugs.chromium.org/p/chromium/issues/detail?id=998903 issue])。よって、ダークモードの有効化とユーザの GTK テーマが切り離されました。この設定は、CSS、JavaScript、設定、そして Dev-Tools の ''prefers-color-scheme'' に適用されます。

優先外観を変更する方法は、XDG Desktop Portal バックエンドに依存します。例えば、多くのデスクトップ環境はそれぞれの外観設定インターフェイスにモードを切り替えるスイッチを提供しています。または、例えば {{Pkg|xdg-desktop-portal-gtk}} 場合は、以下のコマンドを使って優先モードを {{ic|prefer-light}} や {{ic|prefer-dark}}、{{ic|default}} に設定します:

$ dconf write /org/gnome/desktop/interface/color-scheme \'prefer-dark\'

{{Pkg|dbus}} の {{ic|dbus-send}} を使用することで、現在の優先外観をクエリできます ([https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Settings ドキュメント]):

$ dbus-send --session --print-reply=literal --dest=org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Settings.Read string:org.freedesktop.appearance string:color-scheme | tr -s ' ' | cut -d ' ' -f 5

* '''0''': 設定無し
* '''1''': ダークモードを優先
* '''2''': ライトモードを優先

===== Chromium 114 より前 =====

ダークモードを有効化し、ダークテーマ (通常、incognito モードで使用されます) を有効化するには、以下のフラグを[[#フラグを永続化する|永続的な設定]]に[[追加]]してください:

{{hc|1=~/.config/chromium-flags.conf|2=
--force-dark-mode
--enable-features=WebUIDarkMode
}}

==== サイドパネルを有効化する ====

サイドパネルは {{ic|chrome://flags}} から有効化できます。'''Side panel''' を有効化/無効化することができ、'''Side panel border''' や '''Side panel drag and drop''' といったオプションを変更できます。

=== プロファイルのメンテナンス ===

Chromium は [[Sqlite]] データベースを使用して履歴やお気に入りを管理しています。Sqlite データベースは使っているうちに断片化していきます。しかしながら、データベースをチェックしたり最適化するプロセスが存在しないため、断片化によって段々とパフォーマンスに影響が出て来ます。デフラグを行ってデータベースから未使用領域を削除することで、起動時間やブックマークや履歴に関連する作業を素早く実行することができます。

{{Pkg|profile-cleaner}} と {{AUR|browser-vacuum}} でメンテナンスができます。

=== セキュリティ ===

==== JIT を無効化 ====

[https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ JS エンジンにおけるセキュリティ上の脆弱性のうち約半分]は JIT に原因があります。パフォーマンスが劣化しますが、{{ic|1=--js-flags=--jitless}} フラグを使用することで、JavaScript からネイティブなコードへの just-in-time コンパイルを無効化できます。

==== WebRTC ====

WebRTC は JavaScript を使用する通信プロトコルですが、VPN を使っている場合でもマシンの IP アドレスやハードウェアのハッシュ値が漏洩する可能性があります。VPN ソフトウェアによってはスクリプトの実行が阻止されることもありますが、プロトコルを直接ブロックしてしまう方が安全です。2016年10月現在、デスクトップ版 Chromium で WebRTC を無効化する方法はありませんが、ローカル IP アドレスの漏洩を阻止する拡張が存在します。そのひとつがこの[https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia 拡張機能]です。

WebRTC は https://browserleaks.com/webrtc でテストできます。

{{Warning|IP の漏洩は防げても、Chromium はユニークなハッシュを送信しており、それを止める方法はありません。詳しくは https://www.browserleaks.com/webrtc#webrtc-disable を読んでください。}}

==== SSL 証明書 ====

Chromium には SSL 証明書マネージャが存在しません。Chromium は NSS の共有データベース {{ic|~/.pki/nssdb}} を使用しています。データベースに SSL 証明書を追加するには、シェルを使う必要があります。

===== 自己署名証明書の CAcert 証明書を追加 =====

CAcerts を取得して {{ic|nssdb}} を作成してください (存在しない場合)。作成するには {{Pkg|nss}} パッケージをインストールして以下を実行する必要があります:

$ mkdir -p $HOME/.pki/nssdb
$ cd $HOME/.pki/nssdb
$ certutil -N -d sql:.

$ curl -k -o "cacert-root.crt" "http://www.cacert.org/certs/root.crt"
$ curl -k -o "cacert-class3.crt" "http://www.cacert.org/certs/class3.crt"
$ certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "CAcert.org" -i cacert-root.crt
$ certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "CAcert.org Class 3" -i cacert-class3.crt

{{Note|データベースのパスワードを作成していない場合、作成する必要があります。}}

これでユーザーは手動で自己署名証明書をインポートできるようになります。

===== 例 1: シェルスクリプトを使って TomatoUSB から証明書を分離 =====

以下は証明書を展開してユーザーの {{ic|nssdb}} に追加するシンプルなスクリプトです:

#!/bin/sh
#
# usage: import-cert.sh remote.host.name [port]
#
REMHOST=$1
REMPORT=${2:-443}
exec 6>&1
exec > $REMHOST
echo | openssl s_client -connect ${REMHOST}:${REMPORT} 2>&1 |sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n "$REMHOST" -i $REMHOST
exec 1>&6 6>&-

使用方法はコメント化されている行を見てください。

参照:
*https://web.archive.org/web/20180718193807/https://blog.avirtualhome.com/adding-ssl-certificates-to-google-chrome-linux-ubuntu
*https://chromium.googlesource.com/chromium/src/+/master/docs/linux/cert_management.md

===== 例 2: Firefox を使って TomatoUSB から証明書を分離 =====

{{Pkg|firefox}} ブラウザを使って証明書をファイルに保存してデータベースに手動でインポートすることができます。

Firefox を使って:
#取得先の URL を開く。
#"This Connection is Untrusted" 警告画面が表示されたら ''I understand the Risks > Add Exception...'' をクリック。
#''View > Details > Export'' をクリックしてどこか一時的な場所に証明書を保存 (以下の例では {{ic|/tmp/easy.pem}} を使用)。

Chromium で使用する証明書をインポート:
$ certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "easy" -i /tmp/easy.pem

{{Note|名前は証明書にあわせて変更してください。上記の例では "easy" が証明書の名前です。}}

参照:
*https://sahissam.blogspot.com/2012/06/new-ssl-certificates-for-tomatousb-and.html

==== Canvas Fingerprinting ====

Canvas Fingerprinting は HTML5 の canvas のレンダリング結果の差異を使ってユーザーを識別する技術です。{{ic|--disable-reading-from-canvas}} フラグを使うことで Canvas Fingerprinting を使えないようにすることができます。

フラグが機能しているかどうか確認するには [https://panopticlick.eff.org こちらのテスト] を実行して "hash of canvas fingerprint" の結果を確認してください。

{{Note|1=<nowiki/>
* 一部の拡張機能は canvas からの読み込みを必要としており、{{ic|--disable-reading-from-canvas}} を設定すると壊れる場合があります。
* YouTube プレイヤーや Google マップは canvas からの読み込みができないと正しく動作しません ([https://github.com/qutebrowser/qutebrowser/issues/5345 Qutebrowser issue 5345]、[https://bbs.archlinux.org/viewtopic.php?id=255958 BBS#255958]、[https://bbs.archlinux.org/viewtopic.php?id=276425 BBS#276425] を参照)。
}}

==== プライバシー拡張 ====

[[ブラウザ拡張機能#プライバシー]] を参照してください。

{{Tip|あまりにも多くの拡張機能をインストールしてしまうと、ツールバーのスペースを圧迫してしまうかもしれません。ユーザと対話しない拡張機能は、拡張機能を右クリックして ''Hide in Chromium menu'' を選択することで隠すことができます。}}

==== Do Not Track ====

[[wikipedia:Do Not Track|Do Not Track]] を有効化するには、{{ic|chrome://settings}} を開き、''Advanced'' まで下へスクロールして、''Privacy and security'' の ''Send a "Do Not Track" request with your browsing traffic'' にチェックを入れてください。

==== 特定のパスワードストアを強制する ====

Chromium はパスワードストアを使ってパスワードと (cookie の値を暗号化するのに使われる) ''Chromium Safe Storage'' キーを保存します [https://codereview.chromium.org/24734007]。

デフォルトでは Chromium は使用するパスワードストアを自動的に認識しますが、デスクトップ環境やウィンドウマネージャを変えたときにパスワードと cookie が失われてしまう可能性があります。

{{ic|--password-store}} フラグで以下のどれかの値を指定して Chromium を起動することで特定のパスワードストアを強制的に使うようにすることができます [https://chromium.googlesource.com/chromium/src/+/master/docs/linux/password_storage.md]:

* {{ic|gnome-libsecret}} - [https://gitlab.gnome.org/GNOME/libsecret libsecret] 経由で [[Gnome Keyring]] を使用
* {{ic|kwallet5}} - [[KDE Wallet]] 5 を使用。
* {{ic|kwallet6}} - [[KDE Wallet]] 6 を使用。
* {{ic|basic}} - {{ic|Login Data}} ファイルにプレーンテキストとしてパスワードと cookie の暗号鍵を保存
* {{ic|detect}} - デフォルトの自動認識

例えば、Gnome Keyring を使うようにするには {{ic|1=--password-store=gnome-libsecret}} を付けてください。永続化する方法は [[#フラグを永続化する]] を参照。

他のデスクトップ環境のパスワードストアを使う場合、自動的にアンロックされるように設定すると良いでしょう。[[GNOME/Keyring#キーリングを使用する]] や [[KDE Wallet#ログイン時に KDE ウォレットを自動的にアンロック]] を参照。

==== ハイブリッドポスト量子鍵交換を有効化する ====

バージョン 155 から Chromium は、TLS 1.3 向けのハイブリッドポスト量子鍵交換 [https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html X25519Kyber768] をサポートしています [https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html]。この機能はデフォルトで無効化されていますが、{{Ic|chrome://flags/#enable-tls13-kyber}} フラグで有効化できます。

== トラブルシューティング ==

=== フォント ===

{{Note|Chromium は独自のサンドボックスを使っているため、fontconfig/GTK/Pango/X などと完全な統合がされていません。詳しくは [https://dev.chromium.org/developers/linux-technical-faq Linux Technical FAQ] を参照してください。}}

==== タブのフォントサイズが大きすぎる ====

[[GTK#設定]] で言及されているように、Chromium は GTK の設定を使用します。Chromium はタブに {{ic|gtk-font-name}} の設定を使用します (これにより、ウインドウのフォントサイズと合わなくなる場合があります)。この設定を上書きするには、{{ic|1=--force-device-scale-factor=1.0}} を使用してください。

Chrome Refresh 2023 がデフォルトになってから、Cantarell フォントを使用している GNOME で動かすとタブタイトル内の一部の文字 (小文字の g など) が切れてしまうことがあります。[https://issues.chromium.org/issues/40934082 chromium.org のイシュー]を参照してください。

この問題が解決するまでの回避策は、[[フォント設定#デフォルトまたは代替フォントを設定する]] に載っている設定を使って Cantarell から別のフォントに変えることです。例えば:

{{hc|~/.config/fontconfig/conf.d/10-chromium-font.conf|<nowiki>
<match target="pattern">
<test name="prgname" compare="eq">
<string>chromium</string>
</test>
<test qual="any" name="family">
<string>Cantarell</string>
</test>
<edit name="family" mode="assign" binding="strong">
<string>Ubuntu</string>
</edit>
</match>
</nowiki>}}

この設定は、プロセスの名前が {{ic|chromium}} にマッチする場合にのみ適用されます。Google Chrome に対しては {{ic|chrome}} としてください。

=== WebGL ===

使用中のグラフィックカードが Chromium のブラックリストに入っている可能性があります。[[#GPU アクセラレーションを強制する]] を見てください。

[[Bumblebee]] で Chromium を使っている場合、GPU のサンドボックスによって WebGL がクラッシュすることがあります。このようなときは、{{ic|optirun chromium --disable-gpu-sandbox}} で GPU のサンドボックスを無効にできます。

WebGL サポートのデバッグ情報は {{ic|chrome://gpu/}} を見てください。

Chromium はユーザプロファイルに GPU に関する誤った情報を保存することがあります。例えば、Optimus を使って Nvidia カードから Intel カードに切り替えた場合、たとえ Nvidia カードや primusrun/optirun を使用していなくても、{{ic|chrome://gpu}} に Nvidia カードが表示されます。異なるユーザデータディレクトリを使って実行することにより (例: {{ic|1=chromium --user-data-dir=$(mktemp -d)}})、この問題を解決できる場合があります。持続的な解決策として、{{ic|~/.config/chromium/Local\ State}} を削除して GPU の情報をリセットできます。

=== HiDPI の描画がおかしい ===

Chromium は自動的に [[HiDPI]] ディスプレイでの倍率設定を行います。しかし、これにより GUI の描画がおかしくなることがあります。

{{ic|1=--force-device-scale-factor=1}} フラグをを使用して、自動倍率設定を上書きできます。

[[#ネイティブ Wayland サポート|ネイティブの Wayland サポート]] が有効化されている場合、Chromium は、各モニタに設定された倍率を元に自動的に倍率を設定します。

=== GNOME Keyring を使用していると起動するたびにパスワードを要求される ===

[[GNOME/Keyring#パスワードが保存されない]] を見てください。

=== パスワードだけが同期されない ===

同期がパスワードに対してだけ機能しない場合 ({{ic|chrome://sync-internals/}} で確認できます)、プロファイルのログインデータを削除してください:

$ rm ~/.config/chromium/Default/Login\ Data*

詳細は [https://support.google.com/chrome/thread/9947763?hl=en&msgid=23687608 Google Chrome Help forum] を見てください。

=== デスクトップ環境を切り替えると cookie とパスワードが消える ===

Chromium を起動したときにターミナルに {{ic|Failed to decrypt token for service AccountId-*}} というメッセージが表示される場合、Chromium が間違ったパスワード保存バックエンドを使おうとしたのかもしれません。これはデスクトップ環境を切り替えたときに起こりえます。

[[#特定のパスワードストアを強制する]] を見てください。

=== Google Sync を有効化すると起動時に固まる ===

{{ic|1=--password-store=basic}} フラグを使うか、他の適切なパスワードストアを使って Chrome を起動してみてください。

[[#特定のパスワードストアを強制する]] を見てください。

=== デフォルトのブラウザとして設定するかを毎回尋ねてくる ===

KDE を使用していて、一度 Firefox を (Firefox 内のボタンをクリックして) デフォルトのブラウザとして設定したことがある場合、たとえ "デフォルトに設定" ボタンをクリックしたとしても、Chromium を起動するたびに毎回 Chromium をデフォルトのブラウザとして設定するかを尋ねられることがあります。

Chromium は {{ic|xdg-settings check default-web-browser chromium.desktop}} を実行することで chromium がデフォルトのブラウザであるかを確認します。そのコマンドの出力が "no" である場合、chromium がデフォルトのブラウザでないと認識します。{{ic|xdg-settings}} スクリプトは以下の MIME の関連付けを確認し、すべてが {{ic|chromium.desktop}} であることを期待します:

{{bc|
x-scheme-handler/http
x-scheme-handler/https
text/html}}

これを直すには、''システム設定 > アプリケーション > デフォルトのアプリケーション > Web browser'' を開いて、Chormium を指定してください。そして、{{ic|text/html}} の MIME の関連付けを設定してください:

$ xdg-mime default chromium.desktop text/html

最後に、[[XDG_MIME_Applications#新しい MIME タイプ|MIME のデータベースを更新]]してください:

$ update-mime-database ~/.local/share/mime

=== "このブラウザまたはアプリは安全でない可能性があります" Google へのログインエラー ===

2020年04月20日以降、Web 開発用に {{ic|1=--remote-debugging-port=9222}} フラグを指定して chromium を実行すると、 Google アカウントにログインできません。このフラグを一時的に無効にしてログインすると、再び有効にできます。

=== 60 FPS より高いリフレッシュレートのディスプレイを使用しているのに Chromium は 60 FPS で描画される ===

一般的な問題に関する上流のバグレポートは[https://bugs.chromium.org/p/chromium/issues/detail?id=1200167 ここ]にあり、その他の回避策が見つかるかもしれません。また、混合リフレッシュレートに関する問題は[https://bugs.chromium.org/p/chromium/issues/detail?id=1138080 ここ]で報告されています。

==== 混合リフレッシュレート ====

{{Tip|この問題は Wayland バックエンドには存在しない可能性があります。要検証。}}

混合リフレッシュレート (例えば 60 Hz と 144 Hz) のあるディスプレイを使用している場合、Chromium は最も低いリフレッシュレートのディスプレイに合わせて描画するかもしれません。

この問題に対する適切な回避策があります。以下のフラグを[[#フラグを永続化する|永続的な設定]]に[[追加]]してください:

{{hc|1=~/.config/chromium-flags.conf|2=
--use-gl=egl
--ignore-gpu-blocklist
--enable-gpu-rasterization
}}

これにより、コンポジタが 144 FPS でリフレッシュする場合、144Hz ディスプレイ上で使用すると Chromium が 144 FPS で実行されます。これにより、少しカクつくかもしれないことを留意してください {{Bug|67035}}。しかし、60 FPS で止まるよりはマシです。

==== Wayland バックエンドで実行する ====

この問題を引き起こす Wayland コンポジタ固有の問題があるようです。

特に、Plasma 5 は環境によらず 60Hz で描画されるようですが、Plasma 6 (この記事の時点では rc1) では Chromium が高いリフレッシュレートでも問題なく動作します。

その他の解決策がうまく行かなかった場合は、XWayland バックエンドに切り替えてみてください。

=== Chromium でスクロール速度が遅い ===

Chromium や Electron ベースのアプリケーションでマウスホイールのスクロールが遅すぎることがあります。以下にいくつか解決法を挙げます。

[[Libinput#マウスホイールのスクロール速度の調整]] では libinput の {{ic|libinput_event_pointer_get_axis_value}} 関数をインジェクトし、スケール係数を変更するインターフェイスを提供します。これはアプリケーションレベルのインジェクションではないので、アプリケーション固有のスケール係数調整用の追加スクリプトが必要です。Chromium の縦幅の小さい開発者ツールでは、スケール係数を十分大きくするとスクロールが速くなりすぎるかもしれないことに注意してください。

[[imwheel]] は X のホイールボタンのイベントを複数回リプレイすることでスクロールの距離を増やします。しかし、chromium は実際のスクロールとリプレイされたスクロールを2つのイベントとして認識します。これらの間には小さいですが感知できる遅延が存在します。なので、一回のマウスホイールスクロールで2回のページジャンプが発生します。タッチパッドのスクロールでも注意が必要です。

[https://chrome.google.com/webstore/detail/linux-scroll-speed-fix/mlboohjioameadaedfjcpemcaangkkbp Linux Scroll Speed Fix] と [https://chrome.google.com/webstore/detail/smoothscroll/nbokbjkabcmbfdlbddjidfmibcpneigj SmoothScroll] はスクロール距離の変更をサポートする chromium 拡張機能です。ウェブページ内でスクロールすると、現在フォーカスされているノードの最も近いスクロールできる祖先を見つけて、たとえその祖先が一番下までスクロールされていたとしても、その祖先に対してスクロールメソッドがピクセル距離を使って呼ばれます。なので、テキストエディタやスクロール可能な要素にスクロールすると、マウスを動かす以外の方法でその要素からスクロールして出ることはできません。また、拡張機能ベースの手段は Chromium 外では利用できません。

=== 動画がロードされるが再生されない ===

これは PulseAudio の問題である場合があります。[[PulseAudio/トラブルシューティング#ブラウザ (firefox) が動画をロードするが、再生しない]] で提案されている修正方法を確認してください。

=== データベースの破損によりパスワードが保存されない ===

パスワードデータベースは破損することがあり、その場合、再ビルドする必要があります。再ビルドすると、データベース内の全データが破壊され、保存されているパスワードは失われます。

ターミナルから Chromium を起動すると、以下のように出力されます:

[472531:472565:1207/055404.688559:ERROR:login_database.cc(1048)] Password decryption failed, encryption_result is 2

Chromium を終了し、3つのデータベースファイル ({{ic|~/.config/chromium/Default/Login Data*}}) を削除してください。

Chromium を再度起動すると、データベースファイルが再作成されるはずです。

=== KDE Wayland でカーソルが正しく描画されない ===

[[KDE#Plasma のカーソルがときどきおかしくなる]] を参照してください。

=== Wayland で Chromium のウィンドウが透明になる ===

ある[https://issues.chromium.org/issues/329678163 バグ]により、chromium 124 はコマンドラインフラグ {{ic|1=--ozone-platform=wayland}} を明示的に指定して起動する必要があります。

=== Wayland hardware acceleration buffer handle is null エラー ===

とある[https://issues.chromium.org/issues/331796411 バグ]により (特にハードウェアアクセラレーションが有効化されている場合)、ターミナルから起動した際に以下のような出力がログに現れることがあります:

{{bc|1=[333310:333425:0919/121130.103852:ERROR:gpu_channel.cc(502)] Buffer Handle is null.
[333341:18:0919/121130.104000:ERROR:shared_image_interface_proxy.cc(134)] Buffer handle is null. Not creating a mailbox from it.
[333310:333425:0919/121130.137149:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
}}

今のところの回避策は以下のフラグを使用することです:

{{hc|1=~/.config/chromium-flags.conf|2=
--disable-gpu-memory-buffer-video-frames
}}

=== サウンドサーバー無しだと音が出ない ===

Chromiumは[[Advanced_Linux_Sound_Architecture#ハードウェアを直接割り当てる]]をサポートしません。
等ページを見てミキシングの為のデバイス{{ic|pcm.dmixer}},{{ic|pcm.dsnooper}}を設定し、
{{ic|1=-alsa-output-device=pcm.dmixer -alsa-input-device=pcm.dsnooper}}フラグを使ってください。

== 参照 ==

* [https://www.chromium.org/ Chromium ホームページ]
* [https://chromereleases.googleblog.com/ Google Chrome リリースノート]
* [https://chrome.google.com/webstore/ Chrome ウェブストア]
* [[Wikipedia:Chromium (web browser)#Differences from Google Chrome|Chromium と Google Chrome の違い]]
* [https://peter.sh/experiments/chromium-command-line-switches/ Chromium コマンドラインスイッチのリスト]
* [[Profile-sync-daemon]] - Chromium プロファイルを tmpfs に保存し、ディスクと同期する systemd サービス
* [[Tmpfs]] - {{ic|/etc/fstab}} での tmpfs ファイルシステム
* [https://docs.kernel.org/filesystems/tmpfs.html 公式の tmpfs カーネルドキュメント]

{{TranslationStatus|Chromium|2025-03-08|827760}}

Chromium

2025-10-05T15:30:42Z

Oech3: Chromium 140はデフォルトでWaylandをサポート/* ネイティブ Wayland サポート */

[[Category:ウェブブラウザ]]
[[Category:Google]]
[[de:Chromium]]
[[en:Chromium]]
[[zh-hans:Chromium]]
{{Related articles start}}
{{Related|ブラウザ拡張機能}}
{{Related|Firefox}}
{{Related|Vivaldi}}
{{Related articles end}}

[[Wikipedia:ja:Chromium|Chromium]] は、[[Wikipedia:ja:Blink (レンダリングエンジン)|Blink]] レンダリングエンジンをベースとした、オープンソースなグラフィカルウェブブラウザです。プロプライエタリな Google Chrome ブラウザの基礎となっています。

Chromium と Google Chrome との違いについては [https://chromium.googlesource.com/chromium/src/+/master/docs/chromium_browser_vs_google_chrome.md このページ] を見てください。さらに:

* 同期は Chromium 89 以上 (2021-03-02) で利用できません。[https://archlinux.org/news/chromium-losing-sync-support-in-early-march/]

{{Note|同期は、[https://gist.github.com/foutrelis/14e339596b89813aa9c37fd1b4e5d9d5 Chrome の OAuth2 認証情報を使用する]か、[https://www.chromium.org/developers/how-tos/api-keys 自分の認証情報を取得する]ことで一時的に利用可能にできますが、免責事項に注意し、この方法を長期的な解決策と考えないでください。
長期的な解決策としては、ブックマークの同期するための [https://www.xbrowsersync.org xbrowsersync] に移行することを検討してください。}}

他の Chromium ベースのブラウザは [[アプリケーション一覧/インターネット#Blink ベース]] を見てください。

== インストール ==

Chromium を[[インストール]]できるパッケージがいくつか存在します:

* {{Pkg|chromium}} — 安定版
* {{AUR|chromium-dev}} — 開発版
* {{AUR|chromium-snapshot-bin}} — nightly ビルド

Google Chrome のパッケージは:

* {{AUR|google-chrome}} — 安定版
* {{AUR|google-chrome-beta}} — ベータ版
* {{AUR|google-chrome-dev}} — 開発版
* {{AUR|google-chrome-canary}} — カナリアリリース

{{Note|[https://www.chromium.org/Home/chromium-privacy Chromium プライバシーページ]によると(日本語訳):「Chromium のソースコードをコンパイルすることで利用可能になる Google と通信する機能は、[https://www.google.com/policies/privacy/ Google プライバシーポリシー]に従います。」Google サービスとの統合をすべて避けたい人向けに[[アプリケーション一覧/インターネット#プライバシー重視の chromium 派生版|プライバシー重視の Chromium 派生版]]があります。}}

== 設定 ==

=== デフォルトアプリケーション ===

Chromium をデフォルトのブラウザに設定したり、ダウンロードしたファイルを開くときに Chromium がどのアプリケーションを起動するかを変更したりするには、[[デフォルトアプリケーション]] を見てください。

=== 証明書 ===

Chromium は証明書の管理に [[Network Security Services]] を使っています。{{ic|chrome://settings/certificates}} で証明書を管理できます。

=== フラグを永続化する ===

{{Note|{{ic|chromium-flags.conf}} ファイルとそれに付随するカスタムランチャースクリプトは、Arch Linux の様々な Chromium パッケージに固有のものです。Google Chrome に対しては、代わりに {{ic|chrome-flags.conf}} (開発版やベータ版の場合は {{ic|chrome-''チャネル名''-flags.conf}}) を使用してください。}}

フラグは、{{ic|$HOME/.config/}} 内 ({{ic|$XDG_CONFIG_HOME}} 環境変数を設定した場合は、その環境変数が示すディレクトリの中) の {{ic|chromium-flags.conf}} ファイルに記述することができます。グローバルに設定したい場合は、{{ic|/etc/}} 内に配置できます。

特別な構文は使用されず、フラグはターミナルに書き込まれるのと同じように定義されます。

* 引数は空白で分割され、シェルの引用符の規則が適用されますが、それ以上の解析は実行されません。
* ファイル中のどこかが不適切に引用符によって囲まれている場合、致命的なエラーが発生します。
* フラグは読みやすくするために個別の行に分けることができますが、これは必須ではありません。
* ハッシュ記号 (#) で始まる行は読み飛ばされます。(これは Chromium のランチャースクリプトでのみサポートされており、Google Chrome を使用している場合は動作しません。)

以下は、フラグ {{ic|--start-maximized --incognito}} を定義している {{ic|chromium-flags.conf}} ファイルの例です:

{{hc|~/.config/chromium-flags.conf|
# この行は無視されます。
--start-maximized
--incognito
}}

=== GPU アクセラレーションを強制する ===

少なくとも Chromium 110 から、ほとんどのシステムに対して GPU アクセラレーションがデフォルトで有効化されています。あなたのシステム構成が[https://chromium.googlesource.com/chromium/src/gpu/+/master/config/software_rendering_list.json ブラックリスト]と合致する場合、以下のフラグを[[#フラグを永続化する|永続的な設定]]に[[追加]]する必要があります:

{{Warning|レンダリングブラックリストを無効化すると、ホストのクラッシュなどの不安定な挙動を引き起こすかもしれません。詳細については {{ic|chrome://gpu}} にあるバグレポートを見てください。}}

{{hc|~/.config/chromium-flags.conf|
--ignore-gpu-blocklist
--enable-zero-copy
}}

=== ハードウェアビデオアクセラレーション ===

{{Note|1=<nowiki/>
* この機能に対する Chromium や Arch Linux からの公式サポートはありません [https://chromium.googlesource.com/chromium/src/+/master/docs/gpu/vaapi.md#vaapi-on-linux]。しかし、公式リポジトリの {{Pkg|chromium}} は VA-API サポートありでコンパイルされており、[https://bbs.archlinux.org/viewtopic.php?id=244031 専用のフォーラムスレッド]で助けを求めることができます。
* Chromium バージョン 122 から、追加の [[VA-API]] のパッケージはもはや必要なくなりました。公式リポジトリの {{Pkg|chromium}} パッケージでネイティブな Wayland バックエンドを使用している場合、VA-API は動作します。
* AMD GPU デバイス上では、VA-API は[https://crbug.com/1445074 そのままでは動作しません]。動作させるには mesa >= 24.1 が必要であり、[https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26165 Vulkan を有効化する]必要があります。これによって、X11/XWayland で WebGL の問題が発生する場合があります。[[#ネイティブ Wayland サポート|ネイティブ Wayland サポートでの]] Vulkan はバージョン 125.0.6422.141-1 から動作します。
}}

{{Note|1=<nowiki/>
{{ic|chromium-flags.conf}} の適切なフラグの組み合わせを見つけようとしているのであれば、このファイルには {{ic|--enable-features}} や {{ic|--disable-features}} で始まる行はそれぞれ多くとも1行しか含むことができないことに注意してください。複数の機能はコンマで繋げることができます。
}}

{{ic|1=vainfo}} ([[ハードウェアビデオアクセラレーション#VA-API の確認]] を参照) の出力を見て VA-API のサポートがあることを確認した場合は、ひとまず以下のフラグだけで試してみてください:

{{hc|~/.config/chromium-flags.conf|2=
--enable-features=AcceleratedVideoDecodeLinuxGL
}}

{{Note|バージョン 131 より前の Chromium では、上記のフラグではなく {{ic|1=--enable-features=VaapiVideoDecodeLinuxGL}} を使用する必要があります。}}

それ以外の場合は、以下も読んでください。

Chromium でアクセラレートされた'''エン'''コードを有効化するには:

* {{ic|AcceleratedVideoEncoder}} を features に追加してください (例: {{ic|1=--enable-features=AcceleratedVideoDecodeLinuxGL,AcceleratedVideoEncoder}})。詳細は、[https://github.com/chromium/chromium/blob/main/docs/gpu/vaapi.md#vaapi-on-linux] と [https://issues.chromium.org/issues/40225939#comment54] を読んでください。

VA-API サポートを有効にするには:

* 使用中のビデオカード用の適切な VA-API ドライバをインストールしてください。そして、VA-API が有効化されて正常に動作していることを確認してください。[[ハードウェアビデオアクセラレーション]]を見てください。プロプライエタリな NVIDIA サポートは、{{Pkg|libva-nvidia-driver}} をインストールする必要があります。
* {{ic|1=--enable-features=VaapiVideoDecoder}} オプションを設定してください。ANGLE GL レンダラーと {{Pkg|libva-intel-driver}} を使用している場合は、これで十分です。
* ANGLE を使用すると、{{Pkg|intel-media-driver}} が使用されている場合、Chromium は古い i965 ドライバを強制的に使用し失敗します。回避策として、[[ハードウェアビデオアクセラレーション#VA-API の設定|VA-API を手動で設定]]してください。詳細については [https://github.com/intel/media-driver/issues/818] を見てください。
* Xorg か Wayland でシステムの GL レンダラを使用するには、{{ic|1=--use-gl=egl}} を使用してください。Chrome 112 を使用している場合、このオプションはもはや必要ないかもしれず、AMD GPU を使用している場合は GPU アクセラレーションの機能が壊れる場合があります。
* VA-API がまだ動かない場合は、{{ic|1=--enable-features=VaapiIgnoreDriverChecks}} か {{ic|1=--disable-features=UseChromeOSDirectVideoDecoder}} フラグを試してください。
* VA-API が Xorg と古い GPU 上でまだ動かない場合は、{{ic|1=LIBVA_DRI3_DISABLE=1}} [[環境変数]]を設定してください [https://www.phoronix.com/news/VA-API-libva-2.18]。

==== Vulkan ====

Vulkan を使用する場合、以下のフラグが必要で、Chromium 126 と Mesa 24.1 ではこれで十分でしょう:

{{hc|~/.config/chromium-flags.conf|2=
--enable-features=VaapiVideoDecoder,VaapiIgnoreDriverChecks,Vulkan,DefaultANGLEVulkan,VulkanFromANGLE
}}

先述の追加のフラグは入れないでください。

==== ヒントとテクニック ====

{{Out of date|
* Wayland + RADV の環境では Chromium は AV1 に VaapiVideoDecoder を使用します。
* Wayland + RADV の環境では Chromium は全てのサイスの動画に VaapiVideoDecoder を使用します。
}}

使用中の VA-API ドライバでサポートされているコーデックの動画の視聴がうまく行くかどうか確認するには (''vainfo'' はどのコーデックがサポートされているかを表示しますが、Chromium は VP9 と h264 だけをサポートします):

* {{ic|Ctrl+Shift+I}} を押すか、コンテキスト (右クリック) メニューの ''検証'' ボタンを押して DevTools を開いてください
* Media inspection タブを追加してください: ''ハンバーガーメニュー(︙) > More tools > Media''
* 新しく開いた Media タブで、Video Decoder の Hardware decoder の状態を見てください。

十分に大きな動画でテストしてください。バージョン 86 から、デスクトップ版の Chromium は [https://bugs.chromium.org/p/chromium/issues/detail?id=684792 720p よりも大きい動画でしかアクセラレーションを使用しません]。

VP8/VP9 ハードウェアデコードが使用できない Youtube 動画を視聴しているときに CPU 使用率を減らすには、[https://chrome.google.com/webstore/detail/h264ify/aleakchihdccplidncghkekgioiakgal h264ify] や [https://chrome.google.com/webstore/detail/enhanced-h264ify/omkfmpieigblcllmkgbflkikinpkodlk enhanced-h264ify]、[https://chrome.google.com/webstore/detail/not-yet-av1/dcmllfkiihingappljlkffafnlhdpbai Not yet, AV1][https://bbs.archlinux.org/viewtopic.php?pid=2039884#p2039884] 拡張機能を使用してください。

一部のシステム (特に Xwayland) では、[[#GPU アクセラレーションを強制する]] 必要があるかもしれません。このセクションでの目的に対しては {{ic|--ignore-gpu-blocklist}} のみで十分です。

Skia レンダラーは、現在ビデオデコードアクセラレーションと互換性がないので、無効化する必要があるかもしれません: {{ic|1=--disable-features=UseSkiaRenderer}}

=== KDE 統合 ===

[[Plasma]] との統合は {{Pkg|plasma-browser-integration}} を[[インストール]]してください。詳細は [https://community.kde.org/Plasma/Browser_Integration KDE Plasma Browser Integration] を見てください。

=== PDF ビューアプラグイン ===

Chromium と Google Chrome には ''Chromium PDF Viewer'' プラグインがバンドルされています。このプラグインを使用したくない場合は、{{ic|chrome://settings/content/pdfDocuments}} 内の ''Download PDFs'' を確認してください。

=== Xwayland での動作 ===

NVIDIA 社のプロプライエタリドライバを使用している場合、Xwayland 上で Chromium を実行すると、GPU プロセスが時々クラッシュすることがあります。GPU プロセスがクラッシュしないようにするには、以下のフラグを追加してください:

--use-angle=vulkan --use-cmd-decoder=passthrough

{{Note|これはすべての Xwayland 関連のクラッシュを防止するわけではありません。}}

=== ネイティブ Wayland サポート ===

Chromium 140では、デフォルトで[[Wayland]]をサポートします。
古いバージョンでは{{ic|--ozone-platform-hint=auto --enable-wayland-ime --wayland-text-input-version=3}}が必要でした。

追加で、[https://bugs.chromium.org/p/chromium/issues/detail?id=1422087 インプットメソッドの問題]が発生している場合は、新しい GTK を強制すると良いかもしれません:

--gtk-version=4

{{Note|{{ic|text_input_v1}} プロトコルがデフォルトで実装されている場合、{{ic|--enable-wayland-ime}} フラグは機能します。このプロトコルを実装している既知のコンポジタは Weston、KWin、Hyprland です。}}

==== ナビゲーションのタッチパッドジェスチャ ====

2本の指でスワイプすると戻ったり進んだりする機能を有効にするには、以下のフラグを使用してください:

--enable-features=TouchpadOverscrollHistoryNavigation

== ヒントとテクニック ==

特に注意書きがなければ以下のヒントとテクニックは Chromium と Chrome の両方で使うことができます。

=== ブラウズのエクスペリエンス ===

==== chrome:// URL ====

多くの調整は Chrome の URL からアクセスすることができます。完全なリストは '''chrome://chrome-urls''' を参照してください。

* '''chrome://flags''' - WebGL などの実験的な機能や GPU によるウェブページのレンダリングなどにアクセスできます。
* '''chrome://extensions''' - 現在使用している Chromium 拡張を表示・有効化・無効化。
* '''chrome://gpu''' - 様々な GPU オプションの状態。
* '''chrome://sandbox''' - サンドボックスの状態を表示。
* '''chrome://version''' - バージョンや {{ic|/usr/bin/chromium}} を実行するときに使われたスイッチを表示。

Chromium のスイッチ (コマンドラインパラメータ) の自動的に更新される完全なリストが [https://peter.sh/experiments/chromium-command-line-switches/ こちら] にあります。

==== Chromium タスクマネージャ ====

Shift+ESC でブラウザのタスクマネージャを立ち上げることができます。メモリや CPU、ネットワークの使用量が閲覧可能です。

==== Chromium が Preferences ファイルを上書き/オーバーライドしてしまう ====

Google アカウントの同期を有効にしている場合、{{ic|~/.config/chromium/Default/Preferences}} 下の Preferences ファイルに直接編集を加えていても Chromium によって上書きされてしまいます。上書きされないようにするには、{{ic|--disable-sync-preferences}} スイッチを付けて Chromium を起動してください:
$ chromium --disable-sync-preferences

デスクトップ環境のログイン時にバックグラウンドで Chromium を起動する場合、デスクトップ環境から使用するコマンドを以下のようにしてください:
$ chromium --disable-sync-preferences --no-startup-window

==== 検索エンジン ====

[https://wiki.archlinux.org wiki.archlinux.org] や [https://en.wikipedia.org wikipedia.org] などのウェブサイトは検索を実行してから ''Settings > Search'' を選択して ''Manage search engines..'' ボタンをクリックすることで簡単に検索できるように設定できます。エントリを "Edit" してキーワードを '''w''' などに変更してください (ショートカットは自由に決めて下さい)。これでアドレスバーに "'''w arch linux'''" と入力するだけで "Arch Linux" で検索できるようになります。

{{Note|URL バーに何か入力すると自動的に Google 検索が使われます。また、ハードコードされたキーワードトリガとして '''?''' プレフィックスが使えます。}}

==== Tmpfs ====

===== tmpfs にキャッシュ =====

{{Note|Chromium はブラウザのプロファイルディレクトリとキャッシュディレクトリを分離して保存します。}}

物理ディスクに対する Chromium のキャッシュの書き込みを制限したい場合、{{ic|--disk-cache-dir}} フラグでキャッシュの書き込み先を変更することができます:

$ chromium --disk-cache-dir="$XDG_RUNTIME_DIR/chromium-cache"

キャッシュは一時的になり、再起動したりハードロックすると'''消えます'''。もしくは、tmpfs 領域を {{ic|/etc/fstab}} 内でセットアップすることもできます:

{{hc|/etc/fstab|2=
tmpfs /home/''username''/.cache tmpfs noatime,nodev,nosuid,size=400M 0 0
}}

または、{{ic|/tmp}} へのシンボリックリンクを作成してください。以下のコマンドを実行する前に、Chromium のキャッシュフォルダは削除しておいてください:

$ ln -s /tmp /home/''ユーザ名''/.cache/chromium

また、全てのアプリケーションで有効な[[XDG_Base_Directory#ユーザーディレクトリ|XDG_CACHE_HOME]]もあります。

===== tmpfs にプロファイル =====

{{ic|/tmp}} や {{ic|/dev/shm}} などの [[Wikipedia:ja:Tmpfs|tmpfs]] ファイルシステムにプロファイルを保存することで、プロファイル全体が RAM 内に保存されるので、Chromium の応答性が改善されます。

{{Pkg|profile-sync-daemon}} などの、プロファイルを動的に管理するスクリプトを使うことで信頼性と使いやすさを最大限高めることができます。profile-sync-daemon はブラウザプロファイルのディレクトリのシンボリックリンクを作成し、定期的にメモリと同期をとります。詳細については [[Profile-sync-daemon]] の記事を参照して下さい。

==== 新しいブラウザインスタンスを起動 ====

ブラウザを起動すると、最初に同じプロファイルを使っているインスタンスが他にないか確認されます。存在する場合、新しいウィンドウは既存のインスタンスに関連付けられます。以下のように {{ic|--user-data-dir}} パラメータを使って起動することで別のプロファイルでブラウザを起動できます:

$ chromium --user-data-dir=''/path/to/some/directory''

{{Note|ユーザーデータのデフォルトパスは {{ic|~/.config/chromium/}} です。}}

==== torrent クライアントで *.torrent ファイルやマグネットリンクを直接開く ====

デフォルトでは Chromium は {{ic|*.torrent}} ファイルを直接ダウンロードするため、ファイルを torrent クライアントで開くには画面左下の通知をクリックする必要があります。以下の方法で毎回クリックする手間を省けます:

* {{ic|*.torrent}} ファイルをダウンロード。
* 画面左下に表示される通知を右クリック。
* "Always Open Files of This Type" チェックボックスにチェックを入れる。

デフォルトの関連付けの変更については [[xdg-open]] を見てください。

==== タッチスクリーンデバイスでタッチスクロール ====

使用するタッチデバイスを指定する必要があります。タッチスクリーンデバイスを {{ic|xinput list}} で確認して、{{ic|1=--touch-devices='''x'''}} パラメータを付けて Chromium を起動してください ("'''x'''" はデバイスの id に置き換えてください)。
{{Note|スレーブポインタのデバイスは使えません。マスターポインタの ID を使ってください。}}

==== メモリの使用量を減らす ====

デフォルトでは、Chromium は開いているウェブサイトの数だけ OS プロセスを作成します [https://www.chromium.org/developers/design-documents/process-models#Supported_Models]。Chromium の起動時にコマンドラインスイッチを指定することで挙動を変更することが可能です。

例えば、全てのウェブサイトでひとつのプロセスを共有するには:

$ chromium --process-per-site

シングルプロセスモデルを使うには:

$ chromium --single-process

{{Warning|シングルプロセスモデルは安全でなく他のモデルに存在しないバグが含まれている可能性があるため推奨されていません [https://www.chromium.org/developers/design-documents/process-models#TOC-Single-process]。}}

さらに [https://chrome.google.com/webstore/detail/tab-suspender/fiabciakcmgepblmdkmemdbbkilneeeh?hl=en Tab Suspender] や [https://chrome.google.com/webstore/detail/onetab/chphlpgkkbolifaimnlloiipkdnihall?hl=en OneTab] などの拡張を使うことでアクティブでないタブを停止・保存することができます。

==== ユーザーエージェント ====

Chromium の起動時に {{Ic|<nowiki>--user-agent="[string]"</nowiki>}} パラメータを指定することでユーザーエージェントは任意に変更することができます。

==== DOM Distiller ====

Chromium には Firefox にあるのと似たレンダリングモードが存在します。これは DOM Distiller と呼ばれ、[https://github.com/chromium/dom-distiller オープンソースプロジェクト]です。
デフォルトでは無効化されていますが、{{Ic|chrome://flags/#enable-reader-mode}} フラグを使用することにより有効化できます。このフラグは[[#フラグを永続化する|永続化]]させることができます。
DOM Distiller は、ページのコンテンツから不要なものを取り除くことでより良いレンダリングエクスペリエンスを提供するだけでなく、印刷用にページを単純化してくれます。後者のチェックボックスオプションが印刷ダイアログから削除されたものの、不要なものを取り除いたページを印刷することは依然として可能です。これらには、基本的には同じ効果があります。

フラグを有効化すると、ウェブサイトから不要なものを取り除くことができると Chromium が判断したときに、"Enter reader mode" メニューアイテムとアイコンがアドレスバーに出現します。

==== 特定の GPU の使用を強制する ====

GPU が複数ある環境の場合、Chromium はレンダリングに使用する GPU (ディスクリートや統合 GPU) を自動的に検出します。99% は問題ありませんが、誤った GPU が選択された場合 (VFIO GPU パススルー環境でディスクリートグラフィックが選ばれるなど)、{{ic|chrome://gpu}} は GPU プロセスを初期化できないというエラーを吐きます。同じページの '''Driver Information''' には複数の GPU が表示されます (GPU0, GPU1, ...)。ユーザーフレンドリな方法で GPU を切り替えることはできませんが、デバイス/ベンダー ID を使って Chromium のフラグで使用する GPU を設定できます:

$ chromium --gpu-testing-vendor-id=0x8086 --gpu-testing-device-id=0x1912

{{ic|0x8086}} と {{ic|0x1912}} は使用したい GPU の ID に置き換えてください ({{ic|chrome://gpu}} ページで確認できます)。

==== Firefox からブックマークをインポート ====

[[Firefox]] から Chromium にブックマークをインポートすることができます。

Chromium で {{ic|chrome://settings/importData}} を開いてください。

コンピュータに Firefox がインストールされている場合、直接 Firefox からブックマークなどをインポートできます。

'''Mozilla Firefox''' を選択してください。不要なアイテムのチェックは外してかまいません。'''Import''' をクリックしてから '''Done''' をクリックすればインポートは完了です。

{{note|Chromium でまだ何もブックマークを作成していない場合、ブックマークバーにブックマークが表示されます。既にブックマークが存在する場合、ブックマークは "Imported From Firefox" というラベルが付いた新しいフォルダに保存されます。}}

他の PC からブックマークをインポートする場合、先に Firefox からブックマークをエクスポートする必要があります。

Firefox で {{ic|Ctrl+Shift+o}} ''Import and Backup > Export Bookmarks To HTML'' を選択してください

後の作業は同じです。{{ic|chrome://settings/importData}} を開いてください。ただし今度は '''From''' ドロップダウンメニューで '''Bookmarks HTML File''' を選択して '''Choose File''' ボタンをクリックしてブックマークファイルをアップロードします。

後の作業は同じです。{{ic|chrome://settings/importData}} を開いてください。ただし今度は '''From''' ドロップダウンメニューで '''Bookmarks HTML File''' を選択して '''Choose File''' ボタンをクリックしてブックマークファイルをアップロードします。

==== ネイティブ通知の有効化 ====

{{ic|chrome://flags#enable-system-notifications}} を開いて、''Enabled'' を選択してください。

==== マウスの中ボタンでの自動スクロールを有効化する ====

自動スクロールはまだ試験的な機能です [https://niek.github.io/chrome-features/]。開発版ビルドでない Chromium または Chromium ベースのブラウザで、Linux 環境で動作させている場合は、デフォルトで無効化されています。[https://issues.chromium.org/issues/40811836]

この機能を有効化するには、ブラウザを {{ic|1=--enable-features=MiddleClickAutoscroll}} フラグで起動してください。このオプションを永続化させたい場合は、[[#フラグを永続化する]] を見てください。

{{Note|
* {{ic|--enable-blink-features}} は {{ic|--enable-features}} と同じように動作しますが、ブラウザが、このフラグはサポートされておらず、安定性とセキュリティが損なわれると警告を表示することがあります。
* 代替策として Chrome Web Store から似たような機能を持つ [https://chromewebstore.google.com/detail/wheely-wheel-scroll-for-l/kkmfljfnlmppiaoijkfaejgkhccokpdn WHEELY] のような拡張機能を追加することもできます。
}}

{{Tip|もう一つの手段は、{{AUR|chromium-extension-autoscroll}} です。しかし、このパッケージは古くなっており、公式ではないため、推奨されていません。使用する場合は注意してください。}}

==== U2F 認証 ====

{{Pkg|libfido2}} ライブラリをインストールしてください。このパッケージは、(通常) ユーザとして [[U2F]] キーにアクセスできるようにするために必要な udev ルールを提供します。
U2F キーはデフォルトでは root としてしかアクセスできないので、これらのルールが無いと Chromium はエラーを吐きます。

==== テーマ ====

Chromium に現在の GTK テーマをブラウザメニューやコントロールで使用させることができます。{{ic|chrome://settings/appearance}} で ''Use GTK'' を押してください。

==== ダークモード ====

Chromium 114 から、ユーザの優先外観を自動的に決定するために [[XDG デスクトップポータル]] が使用されるようになりました ([https://bugs.chromium.org/p/chromium/issues/detail?id=998903 issue])。よって、ダークモードの有効化とユーザの GTK テーマが切り離されました。この設定は、CSS、JavaScript、設定、そして Dev-Tools の ''prefers-color-scheme'' に適用されます。

優先外観を変更する方法は、XDG Desktop Portal バックエンドに依存します。例えば、多くのデスクトップ環境はそれぞれの外観設定インターフェイスにモードを切り替えるスイッチを提供しています。または、例えば {{Pkg|xdg-desktop-portal-gtk}} 場合は、以下のコマンドを使って優先モードを {{ic|prefer-light}} や {{ic|prefer-dark}}、{{ic|default}} に設定します:

$ dconf write /org/gnome/desktop/interface/color-scheme \'prefer-dark\'

{{Pkg|dbus}} の {{ic|dbus-send}} を使用することで、現在の優先外観をクエリできます ([https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Settings ドキュメント]):

$ dbus-send --session --print-reply=literal --dest=org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Settings.Read string:org.freedesktop.appearance string:color-scheme | tr -s ' ' | cut -d ' ' -f 5

* '''0''': 設定無し
* '''1''': ダークモードを優先
* '''2''': ライトモードを優先

===== Chromium 114 より前 =====

ダークモードを有効化し、ダークテーマ (通常、incognito モードで使用されます) を有効化するには、以下のフラグを[[#フラグを永続化する|永続的な設定]]に[[追加]]してください:

{{hc|1=~/.config/chromium-flags.conf|2=
--force-dark-mode
--enable-features=WebUIDarkMode
}}

==== サイドパネルを有効化する ====

サイドパネルは {{ic|chrome://flags}} から有効化できます。'''Side panel''' を有効化/無効化することができ、'''Side panel border''' や '''Side panel drag and drop''' といったオプションを変更できます。

=== プロファイルのメンテナンス ===

Chromium は [[Sqlite]] データベースを使用して履歴やお気に入りを管理しています。Sqlite データベースは使っているうちに断片化していきます。しかしながら、データベースをチェックしたり最適化するプロセスが存在しないため、断片化によって段々とパフォーマンスに影響が出て来ます。デフラグを行ってデータベースから未使用領域を削除することで、起動時間やブックマークや履歴に関連する作業を素早く実行することができます。

{{Pkg|profile-cleaner}} と {{AUR|browser-vacuum}} でメンテナンスができます。

=== セキュリティ ===

==== JIT を無効化 ====

[https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ JS エンジンにおけるセキュリティ上の脆弱性のうち約半分]は JIT に原因があります。パフォーマンスが劣化しますが、{{ic|1=--js-flags=--jitless}} フラグを使用することで、JavaScript からネイティブなコードへの just-in-time コンパイルを無効化できます。

==== WebRTC ====

WebRTC は JavaScript を使用する通信プロトコルですが、VPN を使っている場合でもマシンの IP アドレスやハードウェアのハッシュ値が漏洩する可能性があります。VPN ソフトウェアによってはスクリプトの実行が阻止されることもありますが、プロトコルを直接ブロックしてしまう方が安全です。2016年10月現在、デスクトップ版 Chromium で WebRTC を無効化する方法はありませんが、ローカル IP アドレスの漏洩を阻止する拡張が存在します。そのひとつがこの[https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia 拡張機能]です。

WebRTC は https://browserleaks.com/webrtc でテストできます。

{{Warning|IP の漏洩は防げても、Chromium はユニークなハッシュを送信しており、それを止める方法はありません。詳しくは https://www.browserleaks.com/webrtc#webrtc-disable を読んでください。}}

==== SSL 証明書 ====

Chromium には SSL 証明書マネージャが存在しません。Chromium は NSS の共有データベース {{ic|~/.pki/nssdb}} を使用しています。データベースに SSL 証明書を追加するには、シェルを使う必要があります。

===== 自己署名証明書の CAcert 証明書を追加 =====

CAcerts を取得して {{ic|nssdb}} を作成してください (存在しない場合)。作成するには {{Pkg|nss}} パッケージをインストールして以下を実行する必要があります:

$ mkdir -p $HOME/.pki/nssdb
$ cd $HOME/.pki/nssdb
$ certutil -N -d sql:.

$ curl -k -o "cacert-root.crt" "http://www.cacert.org/certs/root.crt"
$ curl -k -o "cacert-class3.crt" "http://www.cacert.org/certs/class3.crt"
$ certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "CAcert.org" -i cacert-root.crt
$ certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "CAcert.org Class 3" -i cacert-class3.crt

{{Note|データベースのパスワードを作成していない場合、作成する必要があります。}}

これでユーザーは手動で自己署名証明書をインポートできるようになります。

===== 例 1: シェルスクリプトを使って TomatoUSB から証明書を分離 =====

以下は証明書を展開してユーザーの {{ic|nssdb}} に追加するシンプルなスクリプトです:

#!/bin/sh
#
# usage: import-cert.sh remote.host.name [port]
#
REMHOST=$1
REMPORT=${2:-443}
exec 6>&1
exec > $REMHOST
echo | openssl s_client -connect ${REMHOST}:${REMPORT} 2>&1 |sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n "$REMHOST" -i $REMHOST
exec 1>&6 6>&-

使用方法はコメント化されている行を見てください。

参照:
*https://web.archive.org/web/20180718193807/https://blog.avirtualhome.com/adding-ssl-certificates-to-google-chrome-linux-ubuntu
*https://chromium.googlesource.com/chromium/src/+/master/docs/linux/cert_management.md

===== 例 2: Firefox を使って TomatoUSB から証明書を分離 =====

{{Pkg|firefox}} ブラウザを使って証明書をファイルに保存してデータベースに手動でインポートすることができます。

Firefox を使って:
#取得先の URL を開く。
#"This Connection is Untrusted" 警告画面が表示されたら ''I understand the Risks > Add Exception...'' をクリック。
#''View > Details > Export'' をクリックしてどこか一時的な場所に証明書を保存 (以下の例では {{ic|/tmp/easy.pem}} を使用)。

Chromium で使用する証明書をインポート:
$ certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "easy" -i /tmp/easy.pem

{{Note|名前は証明書にあわせて変更してください。上記の例では "easy" が証明書の名前です。}}

参照:
*https://sahissam.blogspot.com/2012/06/new-ssl-certificates-for-tomatousb-and.html

==== Canvas Fingerprinting ====

Canvas Fingerprinting は HTML5 の canvas のレンダリング結果の差異を使ってユーザーを識別する技術です。{{ic|--disable-reading-from-canvas}} フラグを使うことで Canvas Fingerprinting を使えないようにすることができます。

フラグが機能しているかどうか確認するには [https://panopticlick.eff.org こちらのテスト] を実行して "hash of canvas fingerprint" の結果を確認してください。

{{Note|1=<nowiki/>
* 一部の拡張機能は canvas からの読み込みを必要としており、{{ic|--disable-reading-from-canvas}} を設定すると壊れる場合があります。
* YouTube プレイヤーや Google マップは canvas からの読み込みができないと正しく動作しません ([https://github.com/qutebrowser/qutebrowser/issues/5345 Qutebrowser issue 5345]、[https://bbs.archlinux.org/viewtopic.php?id=255958 BBS#255958]、[https://bbs.archlinux.org/viewtopic.php?id=276425 BBS#276425] を参照)。
}}

==== プライバシー拡張 ====

[[ブラウザ拡張機能#プライバシー]] を参照してください。

{{Tip|あまりにも多くの拡張機能をインストールしてしまうと、ツールバーのスペースを圧迫してしまうかもしれません。ユーザと対話しない拡張機能は、拡張機能を右クリックして ''Hide in Chromium menu'' を選択することで隠すことができます。}}

==== Do Not Track ====

[[wikipedia:Do Not Track|Do Not Track]] を有効化するには、{{ic|chrome://settings}} を開き、''Advanced'' まで下へスクロールして、''Privacy and security'' の ''Send a "Do Not Track" request with your browsing traffic'' にチェックを入れてください。

==== 特定のパスワードストアを強制する ====

Chromium はパスワードストアを使ってパスワードと (cookie の値を暗号化するのに使われる) ''Chromium Safe Storage'' キーを保存します [https://codereview.chromium.org/24734007]。

デフォルトでは Chromium は使用するパスワードストアを自動的に認識しますが、デスクトップ環境やウィンドウマネージャを変えたときにパスワードと cookie が失われてしまう可能性があります。

{{ic|--password-store}} フラグで以下のどれかの値を指定して Chromium を起動することで特定のパスワードストアを強制的に使うようにすることができます [https://chromium.googlesource.com/chromium/src/+/master/docs/linux/password_storage.md]:

* {{ic|gnome-libsecret}} - [https://gitlab.gnome.org/GNOME/libsecret libsecret] 経由で [[Gnome Keyring]] を使用
* {{ic|kwallet5}} - [[KDE Wallet]] 5 を使用。
* {{ic|kwallet6}} - [[KDE Wallet]] 6 を使用。
* {{ic|basic}} - {{ic|Login Data}} ファイルにプレーンテキストとしてパスワードと cookie の暗号鍵を保存
* {{ic|detect}} - デフォルトの自動認識

例えば、Gnome Keyring を使うようにするには {{ic|1=--password-store=gnome-libsecret}} を付けてください。永続化する方法は [[#フラグを永続化する]] を参照。

他のデスクトップ環境のパスワードストアを使う場合、自動的にアンロックされるように設定すると良いでしょう。[[GNOME/Keyring#キーリングを使用する]] や [[KDE Wallet#ログイン時に KDE ウォレットを自動的にアンロック]] を参照。

==== ハイブリッドポスト量子鍵交換を有効化する ====

バージョン 155 から Chromium は、TLS 1.3 向けのハイブリッドポスト量子鍵交換 [https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html X25519Kyber768] をサポートしています [https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html]。この機能はデフォルトで無効化されていますが、{{Ic|chrome://flags/#enable-tls13-kyber}} フラグで有効化できます。

== トラブルシューティング ==

=== フォント ===

{{Note|Chromium は独自のサンドボックスを使っているため、fontconfig/GTK/Pango/X などと完全な統合がされていません。詳しくは [https://dev.chromium.org/developers/linux-technical-faq Linux Technical FAQ] を参照してください。}}

==== タブのフォントサイズが大きすぎる ====

[[GTK#設定]] で言及されているように、Chromium は GTK の設定を使用します。Chromium はタブに {{ic|gtk-font-name}} の設定を使用します (これにより、ウインドウのフォントサイズと合わなくなる場合があります)。この設定を上書きするには、{{ic|1=--force-device-scale-factor=1.0}} を使用してください。

Chrome Refresh 2023 がデフォルトになってから、Cantarell フォントを使用している GNOME で動かすとタブタイトル内の一部の文字 (小文字の g など) が切れてしまうことがあります。[https://issues.chromium.org/issues/40934082 chromium.org のイシュー]を参照してください。

この問題が解決するまでの回避策は、[[フォント設定#デフォルトまたは代替フォントを設定する]] に載っている設定を使って Cantarell から別のフォントに変えることです。例えば:

{{hc|~/.config/fontconfig/conf.d/10-chromium-font.conf|<nowiki>
<match target="pattern">
<test name="prgname" compare="eq">
<string>chromium</string>
</test>
<test qual="any" name="family">
<string>Cantarell</string>
</test>
<edit name="family" mode="assign" binding="strong">
<string>Ubuntu</string>
</edit>
</match>
</nowiki>}}

この設定は、プロセスの名前が {{ic|chromium}} にマッチする場合にのみ適用されます。Google Chrome に対しては {{ic|chrome}} としてください。

=== WebGL ===

使用中のグラフィックカードが Chromium のブラックリストに入っている可能性があります。[[#GPU アクセラレーションを強制する]] を見てください。

[[Bumblebee]] で Chromium を使っている場合、GPU のサンドボックスによって WebGL がクラッシュすることがあります。このようなときは、{{ic|optirun chromium --disable-gpu-sandbox}} で GPU のサンドボックスを無効にできます。

WebGL サポートのデバッグ情報は {{ic|chrome://gpu/}} を見てください。

Chromium はユーザプロファイルに GPU に関する誤った情報を保存することがあります。例えば、Optimus を使って Nvidia カードから Intel カードに切り替えた場合、たとえ Nvidia カードや primusrun/optirun を使用していなくても、{{ic|chrome://gpu}} に Nvidia カードが表示されます。異なるユーザデータディレクトリを使って実行することにより (例: {{ic|1=chromium --user-data-dir=$(mktemp -d)}})、この問題を解決できる場合があります。持続的な解決策として、{{ic|~/.config/chromium/Local\ State}} を削除して GPU の情報をリセットできます。

=== HiDPI の描画がおかしい ===

Chromium は自動的に [[HiDPI]] ディスプレイでの倍率設定を行います。しかし、これにより GUI の描画がおかしくなることがあります。

{{ic|1=--force-device-scale-factor=1}} フラグをを使用して、自動倍率設定を上書きできます。

[[#ネイティブ Wayland サポート|ネイティブの Wayland サポート]] が有効化されている場合、Chromium は、各モニタに設定された倍率を元に自動的に倍率を設定します。

=== GNOME Keyring を使用していると起動するたびにパスワードを要求される ===

[[GNOME/Keyring#パスワードが保存されない]] を見てください。

=== パスワードだけが同期されない ===

同期がパスワードに対してだけ機能しない場合 ({{ic|chrome://sync-internals/}} で確認できます)、プロファイルのログインデータを削除してください:

$ rm ~/.config/chromium/Default/Login\ Data*

詳細は [https://support.google.com/chrome/thread/9947763?hl=en&msgid=23687608 Google Chrome Help forum] を見てください。

=== デスクトップ環境を切り替えると cookie とパスワードが消える ===

Chromium を起動したときにターミナルに {{ic|Failed to decrypt token for service AccountId-*}} というメッセージが表示される場合、Chromium が間違ったパスワード保存バックエンドを使おうとしたのかもしれません。これはデスクトップ環境を切り替えたときに起こりえます。

[[#特定のパスワードストアを強制する]] を見てください。

=== Google Sync を有効化すると起動時に固まる ===

{{ic|1=--password-store=basic}} フラグを使うか、他の適切なパスワードストアを使って Chrome を起動してみてください。

[[#特定のパスワードストアを強制する]] を見てください。

=== デフォルトのブラウザとして設定するかを毎回尋ねてくる ===

KDE を使用していて、一度 Firefox を (Firefox 内のボタンをクリックして) デフォルトのブラウザとして設定したことがある場合、たとえ "デフォルトに設定" ボタンをクリックしたとしても、Chromium を起動するたびに毎回 Chromium をデフォルトのブラウザとして設定するかを尋ねられることがあります。

Chromium は {{ic|xdg-settings check default-web-browser chromium.desktop}} を実行することで chromium がデフォルトのブラウザであるかを確認します。そのコマンドの出力が "no" である場合、chromium がデフォルトのブラウザでないと認識します。{{ic|xdg-settings}} スクリプトは以下の MIME の関連付けを確認し、すべてが {{ic|chromium.desktop}} であることを期待します:

{{bc|
x-scheme-handler/http
x-scheme-handler/https
text/html}}

これを直すには、''システム設定 > アプリケーション > デフォルトのアプリケーション > Web browser'' を開いて、Chormium を指定してください。そして、{{ic|text/html}} の MIME の関連付けを設定してください:

$ xdg-mime default chromium.desktop text/html

最後に、[[XDG_MIME_Applications#新しい MIME タイプ|MIME のデータベースを更新]]してください:

$ update-mime-database ~/.local/share/mime

=== "このブラウザまたはアプリは安全でない可能性があります" Google へのログインエラー ===

2020年04月20日以降、Web 開発用に {{ic|1=--remote-debugging-port=9222}} フラグを指定して chromium を実行すると、 Google アカウントにログインできません。このフラグを一時的に無効にしてログインすると、再び有効にできます。

=== 60 FPS より高いリフレッシュレートのディスプレイを使用しているのに Chromium は 60 FPS で描画される ===

一般的な問題に関する上流のバグレポートは[https://bugs.chromium.org/p/chromium/issues/detail?id=1200167 ここ]にあり、その他の回避策が見つかるかもしれません。また、混合リフレッシュレートに関する問題は[https://bugs.chromium.org/p/chromium/issues/detail?id=1138080 ここ]で報告されています。

==== 混合リフレッシュレート ====

{{Tip|この問題は Wayland バックエンドには存在しない可能性があります。要検証。}}

混合リフレッシュレート (例えば 60 Hz と 144 Hz) のあるディスプレイを使用している場合、Chromium は最も低いリフレッシュレートのディスプレイに合わせて描画するかもしれません。

この問題に対する適切な回避策があります。以下のフラグを[[#フラグを永続化する|永続的な設定]]に[[追加]]してください:

{{hc|1=~/.config/chromium-flags.conf|2=
--use-gl=egl
--ignore-gpu-blocklist
--enable-gpu-rasterization
}}

これにより、コンポジタが 144 FPS でリフレッシュする場合、144Hz ディスプレイ上で使用すると Chromium が 144 FPS で実行されます。これにより、少しカクつくかもしれないことを留意してください {{Bug|67035}}。しかし、60 FPS で止まるよりはマシです。

==== Wayland バックエンドで実行する ====

この問題を引き起こす Wayland コンポジタ固有の問題があるようです。

特に、Plasma 5 は環境によらず 60Hz で描画されるようですが、Plasma 6 (この記事の時点では rc1) では Chromium が高いリフレッシュレートでも問題なく動作します。

その他の解決策がうまく行かなかった場合は、XWayland バックエンドに切り替えてみてください。

=== Chromium でスクロール速度が遅い ===

Chromium や Electron ベースのアプリケーションでマウスホイールのスクロールが遅すぎることがあります。以下にいくつか解決法を挙げます。

[[Libinput#マウスホイールのスクロール速度の調整]] では libinput の {{ic|libinput_event_pointer_get_axis_value}} 関数をインジェクトし、スケール係数を変更するインターフェイスを提供します。これはアプリケーションレベルのインジェクションではないので、アプリケーション固有のスケール係数調整用の追加スクリプトが必要です。Chromium の縦幅の小さい開発者ツールでは、スケール係数を十分大きくするとスクロールが速くなりすぎるかもしれないことに注意してください。

[[imwheel]] は X のホイールボタンのイベントを複数回リプレイすることでスクロールの距離を増やします。しかし、chromium は実際のスクロールとリプレイされたスクロールを2つのイベントとして認識します。これらの間には小さいですが感知できる遅延が存在します。なので、一回のマウスホイールスクロールで2回のページジャンプが発生します。タッチパッドのスクロールでも注意が必要です。

[https://chrome.google.com/webstore/detail/linux-scroll-speed-fix/mlboohjioameadaedfjcpemcaangkkbp Linux Scroll Speed Fix] と [https://chrome.google.com/webstore/detail/smoothscroll/nbokbjkabcmbfdlbddjidfmibcpneigj SmoothScroll] はスクロール距離の変更をサポートする chromium 拡張機能です。ウェブページ内でスクロールすると、現在フォーカスされているノードの最も近いスクロールできる祖先を見つけて、たとえその祖先が一番下までスクロールされていたとしても、その祖先に対してスクロールメソッドがピクセル距離を使って呼ばれます。なので、テキストエディタやスクロール可能な要素にスクロールすると、マウスを動かす以外の方法でその要素からスクロールして出ることはできません。また、拡張機能ベースの手段は Chromium 外では利用できません。

=== 動画がロードされるが再生されない ===

これは PulseAudio の問題である場合があります。[[PulseAudio/トラブルシューティング#ブラウザ (firefox) が動画をロードするが、再生しない]] で提案されている修正方法を確認してください。

=== データベースの破損によりパスワードが保存されない ===

パスワードデータベースは破損することがあり、その場合、再ビルドする必要があります。再ビルドすると、データベース内の全データが破壊され、保存されているパスワードは失われます。

ターミナルから Chromium を起動すると、以下のように出力されます:

[472531:472565:1207/055404.688559:ERROR:login_database.cc(1048)] Password decryption failed, encryption_result is 2

Chromium を終了し、3つのデータベースファイル ({{ic|~/.config/chromium/Default/Login Data*}}) を削除してください。

Chromium を再度起動すると、データベースファイルが再作成されるはずです。

=== KDE Wayland でカーソルが正しく描画されない ===

[[KDE#Plasma のカーソルがときどきおかしくなる]] を参照してください。

=== Wayland で Chromium のウィンドウが透明になる ===

ある[https://issues.chromium.org/issues/329678163 バグ]により、chromium 124 はコマンドラインフラグ {{ic|1=--ozone-platform=wayland}} を明示的に指定して起動する必要があります。

=== Wayland hardware acceleration buffer handle is null エラー ===

とある[https://issues.chromium.org/issues/331796411 バグ]により (特にハードウェアアクセラレーションが有効化されている場合)、ターミナルから起動した際に以下のような出力がログに現れることがあります:

{{bc|1=[333310:333425:0919/121130.103852:ERROR:gpu_channel.cc(502)] Buffer Handle is null.
[333341:18:0919/121130.104000:ERROR:shared_image_interface_proxy.cc(134)] Buffer handle is null. Not creating a mailbox from it.
[333310:333425:0919/121130.137149:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
}}

今のところの回避策は以下のフラグを使用することです:

{{hc|1=~/.config/chromium-flags.conf|2=
--disable-gpu-memory-buffer-video-frames
}}

=== サウンドサーバー無しだと音が出ない ===

Chromiumは[[Advanced_Linux_Sound_Architecture#ハードウェアを直接割り当てる]]をサポートしません。
等ページを見てミキシングの為のデバイス{{ic|pcm.dmixer}},{{ic|pcm.dsnooper}}を設定し、
{{ic|1=-alsa-output-device=pcm.dmixer -alsa-input-device=pcm.dsnooper}}フラグを使ってください。

== 参照 ==

* [https://www.chromium.org/ Chromium ホームページ]
* [https://chromereleases.googleblog.com/ Google Chrome リリースノート]
* [https://chrome.google.com/webstore/ Chrome ウェブストア]
* [[Wikipedia:Chromium (web browser)#Differences from Google Chrome|Chromium と Google Chrome の違い]]
* [https://peter.sh/experiments/chromium-command-line-switches/ Chromium コマンドラインスイッチのリスト]
* [[Profile-sync-daemon]] - Chromium プロファイルを tmpfs に保存し、ディスクと同期する systemd サービス
* [[Tmpfs]] - {{ic|/etc/fstab}} での tmpfs ファイルシステム
* [https://docs.kernel.org/filesystems/tmpfs.html 公式の tmpfs カーネルドキュメント]

{{TranslationStatus|Chromium|2025-03-08|827760}}

Doas

2025-09-04T12:33:33Z

Oech3: Drop removed package/* sudo から doas への移行 */

{{Lowercase title}}
[[Category:セキュリティ]]
[[Category:コマンド]]
[[en:doas]]
[[ru:doas]]
[[zh-hans:Doas]]
{{Related articles start}}
{{Related|ユーザーとグループ}}
{{Related|sudo}}
{{Related|アプリケーション一覧/セキュリティ#管理者権限}}
{{Related articles end}}
OpenDoas は OpenBSD の [[Wikipedia:doas|doas]] コマンドの移植版です。[[sudo]] と比べてサイズがかなり小さいことで知られています。''sudo'' と同じように、''doas'' はシステム上の他のユーザーとして実行したいときに使います。

== インストール ==

{{Pkg|opendoas}} パッケージをインストールしてください。

== 使用方法 ==

非特権ユーザーで ''doas'' を使い始めるには、設定が必要です。[[#設定]]を見てください。

''doas'' を使う時はコマンドとその引数の前に {{ic|doas}} とスペースを追加します:

$ doas ''cmd''

例えば [[pacman]] を使う場合:

$ doas pacman -Syu

別のユーザーとして対話型シェルに入るには({{ic|-u ''user''}} を省略すると、デフォルトで root になります):

$ doas -su ''user''

一部のコマンドを実行するには、別のユーザーとしてログインする必要があります。詳しくは [[Sudo#ログインシェル]] を参照してください。

詳細については、 {{man|1|doas}} を参照してください。

== 設定 ==

[[PAM]] モジュールはインストールされますが、デフォルトの設定やサンプルは含まれていません。

[[ユーザーとグループ#ユーザーグループ|wheel]] グループのメンバーに他のユーザーとしてコマンドの実行を許可するには、以下の内容の設定ファイルを作成します:

{{hc|/etc/doas.conf|
permit setenv {{{{ic|PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin}}}} :wheel

}}

{{Note|
* 設定ファイルは改行で終わる必要があります。
* {{ic|setenv}} オプションは、OpenDoas の BSD 由来の [https://github.com/Duncaen/OpenDoas/issues/117 問題] を回避します。Linux では、{{ic|/usr/local/bin}} は一般的に実行可能ファイルを上書きするために使われるので、パッケージの実行可能ファイルを含む {{ic|/usr/bin}} の前に置かれます
}}

{{ic|/etc/doas.conf}} の所有者および所有グループは {{ic|0}} に、ファイルのパーミッションは {{ic|0400}} に設定してください:

# chown -c root:root /etc/doas.conf
# chmod -c 0400 /etc/doas.conf

{{ic|/etc/doas.conf}} の構文エラーをチェックするには、以下のコマンドを実行:

# doas -C /etc/doas.conf && echo "config ok" || echo "config error"

{{Warning|{{ic|/etc/doas.conf}} に構文エラーが含まれないように必ずチェックしてください。}}

{{ic|plugdev}} グループのメンバーが root ユーザーとして [[S.M.A.R.T.#smartctl|smartctl]] をパスワードなしで実行できるようにするには:

{{hc|/etc/doas.conf|
permit nopass :plugdev as root cmd /usr/bin/smartctl
}}

{{ic|/etc/doas.conf}} の基本構文は以下のとおりです:

permit|deny [options] identity [as target] [cmd command [args ...]]

詳しくは {{man|5|doas.conf}} を読んでください。

== ヒントとテクニック ==

=== doas の persist 機能 ===

''doas'' には永続機能があります: ユーザーが認証成功した後、しばらくはパスワードを要求しなくなります。デフォルトでは無効になっているので、{{ic|persist}} オプションで有効にしてください:

{{hc|/etc/doas.conf|2=
permit '''persist''' setenv {PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin} :wheel
}}

{{ic|doas -L}} を実行すると、自動的なタイムアウト前に保存されていた認証情報がクリアされます。

{{Note|永続的機能はデフォルトで無効になっています。これは潜在的に危険であるためです。元の ''doas'' では、カーネル API を使ってタイムアウトの設定と解除を行っています。この API は OpenBSD 特有のもので、他のオペレーティングシステムには同様の API が存在しません。そのため、代替手段として、''sudo'' と同様にタイムスタンプファイルを使って永続機能が実装されています。}}

=== sudo から doas への移行 ===

後方互換を保ちつつ ''sudo'' から ''doas'' にスムーズに移行するために、以下の設定を追加すると良いかもしれません:

alias sudo='doas'
alias sudoedit='doas rnano'

または、代わりに、''sudo'' を ''doas'' へのシンボリックリンクにします。(ただし {{ic|sudoedit}} コマンドは提供されません):

# ln -s /usr/bin/doas /usr/local/bin/sudo

{{Note|デフォルトでは、''sudo'' はいくつかの環境変数を保持しますが、''doas'' は保持しません。特に XAUTHORITY、LANG、LC_ALL は保持しません。これは、X でグラフィカルなアプリケーションを起動したり、ユーザーのロケールにアクセスしたりすることが、さらなる設定なしではできないことを意味します。例えば、''wheel'' グループのメンバーがグラフィカルなアプリケーションを実行したり、setenv オプションを使用してユーザーのロケールにアクセスできるようにするには、次のようにします。
{{hc|/etc/doas.conf|
permit setenv { XAUTHORITY LANG LC_ALL } :wheel
}}
}}

=== Bash タブ補完 ===

デフォルトでは、bash はカレントまたは参照ディレクトリ内のファイルとディレクトリのみをタブで補完します。引数を別のコマンドのように補完するようにするには(他のコマンドのタブ補完の設定も利用する)、次のようにユーザの {{ic|.bashrc}} またはグローバルの {{ic|/etc/bash.bashrc}} に追加します。

{{hc|~/.bashrc|
complete -cf doas
}}

{{Pkg|bash-completion}} がインストールされている場合は、以下を使用して、ターゲットコマンドの追加補完を可能にすることもできます。
{{hc|~/.bashrc|
complete -F _command doas
}}

{{TranslationStatus|doas|2025-05-07|736536}}

Vivaldi

2025-08-21T17:40:22Z

Oech3: Add package/* メディア再生 */

[[Category:ウェブブラウザ]]
[[de:Vivaldi]]
[[en:Vivaldi]]
[[es:Vivaldi]]
[[pl:Vivaldi]]
[[pt:Vivaldi]]
[[ru:Vivaldi]]
[[zh-hans:Vivaldi]]
{{Related articles start}}
{{Related|Chromium}}
{{Related|Firefox}}
{{Related|Opera}}
{{Related articles end}}
[https://vivaldi.com/ Vivaldi] は旧 [[Opera]] の創設者と開発メンバーによるウェブブラウザです。[[Chromium]] をベースとしており、ユーザーの手に馴染むようにすることに重点を置いています。

== インストール ==

Vivaldi は {{Pkg|vivaldi}} か {{AUR|vivaldi-snapshot}} で[[インストール]]することができます。
もしくは非公式の [[非公式ユーザーリポジトリ#herecura|herecura]] リポジトリを追加して、ビルド済みのパッケージを使用することも可能です。

スナップショット版と安定版との違いについては、[https://vivaldi.com/blog/snapshot-vs-stable/ このページ]を見てください。

ファイル選択ダイアログに [[GTK]] ではなく [[Qt]] を使用するには、{{Pkg|kdialog}} をインストールしてください。

== 拡張機能 ==

Vivaldi は Chrome のほとんどの拡張機能と互換性があります。
[https://chrome.google.com/webstore/category/extensions Chrome Web Store] から直接インストールできます。

{{Tip|Vivaldi では {{ic|1=--proxy-server="socks5://127.0.0.1:1080"}} によりコマンドラインに '''プロキシサーバ''' パラメータを追加することができます。これは、特定の条件下におけるネットワーク接続の問題を解決するのに役立つ場合があります。}}

どの拡張機能がインストール/有効化されているか確認するには、アドレスバーに {{ic|vivaldi://extensions}} と入力してください。

[[Wikipedia:Google Chrome Extension]] も参照。

== Media playback ==

Vivaldiは自動的に{{ic|$HOME/.local/lib/vivaldi/media-codecs-7.5/libffmpeg.so}}をダウンロードし、H.264やAACメディアの再生を有効にします。

リポジトリの外からダウンロードされたバイナリを使いたくない場合、{{Pkg|vivaldi-ffmpeg-codecs}}, {{AUR|vivaldi-snapshot-ffmpeg-codecs}} ([https://chromium.googlesource.com/chromium/third_party/ffmpeg/ chromiumソース]) 又は{{AUR|chromium-ffmpeg}} ([https://git.ffmpeg.org/ffmpeg.git ffmpeg.orgソース])をインストールします。

そして、Vivaldiを再起動して下さい。

== フラグを永続化させる ==

{{Note|{{ic|vivaldi-stable.conf}} ファイルの使用は、Arch Linux の {{Pkg|vivaldi}} パッケージ固有のものです。}}

{{ic|$HOME/.config/}} 下 (あるいは、{{ic|$XDG_CONFIG_HOME}} 環境変数を設定している場合、{{ic|$XDG_CONFIG_HOME}}下) の {{ic|vivaldi-stable.conf}} ファイル内にフラグを記述することにより可能です。

特殊な文法は使用されていません。フラグは、ターミナルで記述されるような形で定義されます。

* 引数は空白で区切られ、シェルの引用符の規則も適用されます。しかし、それ以上のパースは行われません。
* 可読性のためにフラグは別々の行に記述することもできます。しかし、これは必須ではありません。

以下は、ブラウザのハードウェアメディアキーを無効化する {{ic|vivaldi-stable.conf}} ファイルの例です:

{{hc|~/.config/vivaldi-stable.conf|
<nowiki>--disable-features=HardwareMediaKeyHandling</nowiki>
}}

{{AUR|vivaldi-snapshot}} パッケージは、{{ic|vivaldi-snapshot.conf}} ファイルでフラグを設定できます。

== 改造 ==

Vivaldi は {{ic|browser.html}} ファイルによる[https://forum.vivaldi.net/topic/10549/modding-vivaldi?lang=en-US 改造機能]を有しています。

このファイルは {{ic|/opt/vivaldi/resources/vivaldi/browser.html}} にあります。

{{ic|browser.html}} のパスを見つけるもう一つの方法は、{{ic|vivaldi://about/}} の ''Executable Path'' (''実行ファイルのパス'') セクションです。

また、{{AUR|vivaldi-autoinject-custom-js-ui}} を使用することもできます。これは、改造を管理 ({{ic|browser.html}} に対する追加と削除、vivaldi 更新時における変更のやり直し) するのに役立ちます。

== ヒントとテクニック ==

=== プロファイルをスナップショット版に転送する ===

安定版に機能が無いためにスナップショット版に切り替えた場合、元のユーザプロファイルを使用したいことがあります。{{ic|~/.config/vivaldi/Default}} を {{ic|~/.config/vivaldi-snapshot/Default}} にコピーしてください。

=== Google 検索候補 ===

Vivaldi は google 検索の候補を有効にして[https://forum.vivaldi.net/topic/28880/google-suggestions-in-address-bar/2 リリースすることができません]。検索設定で検索候補の url '''https://www.google.com/complete/search?client=chrome&q=%s''' を手動で追加しなければなりません。

=== ネイティブな Wayland サポート ===

chrome://flags のページを開き、wayland と検索してください。Preferred Ozone platform という設定があります。この設定を auto に設定してください。デフォルトは "X11" です。"Auto" は、可能であれば Wayland を選択し、無理ならば X11 を選択します。

=== ピクチャーインピクチャーのウィンドウを他のウィンドウの上に表示させる ===

何かしらの動画を視聴する際に、ピクチャーインピクチャーのボタンを押すと、動画を別のウィンドウに分離させることができます。デフォルトでは、このウィンドウは他のウィンドウの上に保持されず、不便です。KDE でこれを修正するには、このウィンドウを他のウィンドウの上に表示させるウィンドウルールを作成してください。[[KDE#ウィンドウのルールを使う]] を見てください。

== トラブルシューティング ==

=== Chromium ページ ===

ハードウェアアクセラレーションを強制的に有効にするなど、一部のトラブルシューティングは Vivaldi と Chromium に共通です。場合によって、[[Chromium#トラブルシューティング]] を参照してください。

=== タスクバーに一般の wayland アイコンが表示される ===

現在、vivaldi のウィンドウがデスクトップ環境によって vivaldi ブラウザとして認識されないバグが存在しています。https://forum.vivaldi.net/topic/75556/vivaldi-on-native-wayland-not-showing-app_id を参照してください。KDE における回避策は [https://www.reddit.com/r/kde/comments/tzw738/comment/i424ces/?utm_source=share&utm_medium=web2x&context=3 ここ] を見てください。

=== 証明書の管理 ===

現在 (Vivaldi 6.2.3105.54 (安定したチャネル)) は、証明書管理設定がありません。これを回避するには、アドレス {{ic|chrome://settings/certificates}} を手動で入力します。アドレスは {{ic|vivaldi://settings/certificates}} に変更されますが、最初から入力することはできないことに注意してください (そうしないと、証明書管理が欠落している vivaldi 設定が表示されます。) 詳細については、[https://forum.vivaldi.net/topic/57001/import-client-certificates ここ] を参照してください。

{{TranslationStatus|Vivaldi|2023-10-22|773804}}

Zoom ミーティング

2025-07-29T15:16:50Z

Oech3: Oech3 (トーク) による版 40045 を取り消し

[[Category:Voice over IP]]
[[en:Zoom Meetings]]
{{Related articles start}}
{{Related|Jitsi-meet}}
{{Related|アプリケーション一覧/インターネット#その他 IM クライアント}}
{{Related articles end}}

[[Wikipedia:ja:Zoom (アプリケーション)|Zoom ミーティング (Zoom Meetings)]] (略して "Zoom" とも) とは、プロプライエタリ、クロスプラットフォーム、クラウドベースのビデオ会議プラットフォームです。

== インストール ==

{{AUR|zoom}} を[[インストール]]することが望ましいです。Zoom のウェブサイトからダウンロードできるファイルでは自己アップデートができないからです。

== ヒントとテクニック ==

{{Note|{{Pkg|xf86-video-intel}} ドライバ (現在、非推奨となっています) では、Intel 統合 GPU で画面共有のチラツキが発生する場合があります。非推奨に関する情報は [[Intel Graphics]] を見てください。}}

=== バーチャル背景 ===

Zoom はデフォルトのバーチャル背景を {{ic|~/.zoom/data/VirtualBkgnd_Default}} に保存し、カスタムのバーチャル背景を {{ic|~/.zoom/data/VirtualBkgnd_Custom}} に保存します。

=== ログ ===

Zoom はログを {{ic|/home/''user''/.zoom/logs/zoom_stdout_stderr.log}} に保存します。

=== システムのテーマを使う ===

{{Note|これは多くのバグを引き起こす可能性があります。}}

{{ic|~/.config/zoomus.conf}} を[[編集]]して {{ic|useSystemTheme}} の値を {{ic|true}} に変更し、Zoom を再起動してください。

=== Zoom ミニウィンドウを無効化する ===

Zoom の「ミニウィンドウ」機能は、Zoom のビデオを小さくできますが、常に最前面に表示されます。それを無効化するには:

{{ic|~/.config/zoomus.conf}} を[[編集]]して {{ic|enableMiniWindow}} の値を {{ic|false}} に変更し、Zoom を再起動してください。

=== インターフェイスのサイズを大きくする ===

{{ic|~/.config/zoomus.conf}} を[[テキスト編集|編集]]して {{ic|1=scaleFactor=1.2}} オプションを追加してください。変更を適用するには Zoom を再起動してください。このオプションが有効化されている場合は {{ic|autoScale}} の設定は無視されることに注意してください。

もう一つのより信頼性の高い方法は、Zoom の起動前に {{ic|1=QT_SCALE_FACTOR=2}} [[環境変数]]を設定することです。これを設定しないと Zoom の "Schedule" パネルが正しくスケーリングされません。

=== ZoomWebviewHostを無効化する ===

RAMを節約したければ、{{ic|~/.config/zoomus.conf}}を{{ic|1=disableCef=false}}に設定する事でZoomWebviewHostを無効化できます。しかし、ホワイトボード等の機能を使えなくなります。

=== Xwayland無しでWayland上で起動する ===

Xwaylandを使わない場合は、{{ic|~/.config/zoomus.conf}}で{{ic|1=xwayland=false}}を設定します。Xwayland無しでは{{ic|ZoomWebviewHost}}プロセスが0MBの消費メモリで停止するかも知れません。

=== 画面共有 ===

==== Wayland ====

Wayland で画面共有するには、[[PipeWire#WebRTC 画面共有|WebRTC 画面共有]]のために必要なパッケージを[[インストール]]し、{{ic|~/.config/zoomus.conf}} 内の {{ic|enableWaylandShare}} の値を {{ic|true}} に変更し、zoom を再起動してください。

依存関係を満たしているにも関わらず、Zoom が依然として pipewire を画面共有に使用しないという報告があります。そのような場合、[https://community.zoom.com/t5/Meetings/Screen-Sharing-Broken-with-5-14-10-on-Linux-KDE-Plasma-Wayland/m-p/126522/highlight/true#M72056 Zoom に Pipewire を使用させるように手動で設定するとうまく動作したと報告されています]。これは以下のようにして設定できます:

# Zoom デスクトップクライアントを起動し、''設定 > 画面共有'' を開く
# ''詳細'' をクリックする
# Screen capture mode を (Auto Mode ではなく) Pipewire Mode に変更する

==== Xorg ====

Xorg で画面共有を有効化するには、セッションの種類を {{ic|X11}} に変更しておかなければなりません (つまり、[[環境変数]] {{ic|1=XDG_SESSION_TYPE=X11}} を設定するということ)。グラフィカルセッションがどのように起動されるかに依りますが、この変数はデフォルトで設定されていないことがあります。

== ブラウザからミーティングに参加する ==

Zoom バイナリを使いたくない場合、合理的な代替手段は [https://support.zoom.us/hc/ja/articles/214629443-Getting-started-with-the-Zoom-web-client Zoom ウェブクライアント]です。ウェブクライアントは、[https://support.zoom.us/hc/ja/articles/360027397692 クライアントバイナリによって提供されている機能を全て持っているわけではありません]が、スムーズで安定したエクスペリエンスを提供し、プロプライエタリなバイナリをインストールするよりもセキュリティ上の懸念が少ないです。

元のミーティング URL が {{ic|1=https://<subdomain>.zoom.us/j/''meeting_id''<nowiki>?</nowiki>pwd=''password''}} である場合、ウェブクライアントは {{ic|1=https://<subdomain>.zoom.us/wc/join/''meeting_id''<nowiki>?</nowiki>pwd=''password''}} でアクセスできます。

=== "Redirector" ブラウザ拡張機能 ===

[[Firefox]]、[[Chromium]]、そして [[Opera]] では、[https://einaregilsson.com/redirector/ Redirector 拡張機能]を使うことで、URL の書き換えを自動化できます。以下のようなルールを作成してください:

* Description: Zoom web client
* Example URL: {{ic|<nowiki>https://sub.zoom.us/j/123456?pwd=pass</nowiki>}}
* Include pattern: {{ic|*//*.zoom.us/j/*}}
* Redirect to: {{ic|$1//$2.zoom.us/wc/join/$3}}
* Pattern type: Wildcard

{{TranslationStatus|Zoom Meetings|2024-11-11|820489}}

Wine

2025-06-16T16:58:25Z

Oech3: Extra/wineのビルドフラグに関する変更

[[Category:エミュレーション]]
[[Category:ゲーム]]
[[de:Wine]]
[[en:Wine]]
[[fr:Wine]]
[[ru:Wine]]
[[zh-hans:Wine]]
{{Related articles start}}
{{Related|CrossOver}}
{{Related|Deepin-wine}}
{{Related|Wine パッケージガイドライン}}
{{Related articles end}}
[[Wikipedia:ja:Wine|Wine]] は、Microsoft Windows のアプリケーションを UNIX ライクな OS で動かすための ''互換レイヤー'' です。Wine で実行されるプログラムは、エミュレータにあるようなパフォーマンスやメモリのペナルティなしに、ネイティブプログラムと同じように機能します。

{{Warning|
* Wine はシステムから分離されていません。
* ユーザーアカウントでファイルまたはリソースにアクセスできる場合は、Wine で実行されているプログラムもそれらにアクセスできます。[[#Wine を別のユーザアカウントで実行する]] と [[セキュリティ#アプリケーションのサンドボックス化]] を参照してください。
* Wine はマルウェアを実行することもできます ([https://wiki.winehq.org/FAQ#Is_Wine_malware-compatible.3F Wine FAQ on Malware compatibility] を参照)。}}

== インストール ==

[[multilib]] リポジトリを有効にし、{{Pkg|wine}} (開発版)、{{AUR|wine-stable}} (安定版)、{{Pkg|wine-staging}} (テスト版) のどれかをインストールすることで、Wine を利用できます。[https://wine-staging.com/ Wine Staging] は [https://www.winehq.org/ Wine] にパッチが適用されたバージョンで、安定ブランチや開発ブランチにマージされていないバグフィックスや機能追加が含まれています。これらは、64 ビット Linux ライブラリのみを使用しており、32 ビット Windows アプリケーションを実行するためのモード付きでビルドされています。

その他の要件については [[#グラフィックドライバ]] と [[#サウンド]] も見てください。

Internet Explorer や .NET に依存しているアプリケーションを使う場合、それぞれ {{pkg|wine-gecko}} と {{pkg|wine-mono}} をインストールしてください。Wine は必要なときに関連ファイルをダウンロードするので、これらのパッケージは厳密には必要ありません。しかし、[[システムメンテナンス#パッケージマネージャーを使用してソフトウェアをインストールする|これらのパッケージは pacman で管理]]べきです。

=== 任意の依存パッケージ ===

{{Tip|一般的な依存パッケージ (特にゲーム関連) は [https://github.com/lutris/docs/blob/master/WineDependencies.md#archendeavourosmanjaroother-arch-derivatives lutris のドキュメント]にリストアップされています。}}

Wine には、基本的なアプリケーションでは必要ないが、サウンド、3D グラフィックス、動画再生などを提供するためにインストールする必要がある[[任意の依存パッケージ]]が多くあります。

多くの Windows アプリケーションは 32 ビットであり、32 ビット版のライブラリが必要であることに注意してください。これらのライブラリの一部は [[AUR]] でしか入手できません。標準 (64 ビット) のライブラリは、64 ビットアプリケーションに対して、または、新しい WoW64 モード ([[#インストール]] 章のノートを参照) のある Wine バージョンを実行している場合は全てのアプリケーションに対して使用することができます。Windows 実行ファイルが 64 ビットであるかどうかは、{{man|1|file}} コマンドで確認することができます。

==== グラフィックドライバ ====

グラフィックドライバの32ビットバージョンをインストールする必要があります。[[Xorg#ドライバーのインストール]] にある表の ''OpenGL (multilib)'' 列に載っているパッケージをインストールしてください。

Wine がターミナルウィンドウに以下のようなメッセージを出力する場合、ドライバが不適切であるか正しく設定されていないことの印です:

Direct rendering is disabled, most likely your OpenGL drivers have not been installed correctly

{{Note|適切なライブラリをインストールした後は X を再起動する必要があるかもしれません。}}

==== サウンド ====

デフォルトの状態では、Wine アプリケーションを実行する際にサウンドの問題が発生する場合があります。''winecfg'' でサウンドデバイスが1つだけ選択されていることを確認してください。

あなたが使いたいオーディオドライバの正しいパッケージをインストールしてください:

* [[ALSA]] の場合、{{Pkg|lib32-alsa-lib}} と {{Pkg|lib32-alsa-plugins}} をインストールしてください
* [[PulseAudio]] の場合、{{Pkg|lib32-libpulse}} をインストールしてください
* [[PipeWire]] の場合、{{Pkg|lib32-pipewire}} と、以下のどれかをインストールしてください:
** PulseAudio をフロントエンドとして使用するには {{Pkg|pipewire-pulse}} と {{Pkg|lib32-libpulse}}。
** ALSA をフロントエンドとして使用するには {{Pkg|pipewire-alsa}}、{{Pkg|lib32-alsa-lib}}、{{Pkg|lib32-alsa-plugins}}。
* [[OSS]] の場合、{{Pkg|lib32-alsa-oss}} をインストールしてください

上記のパッケージをインストールしても''なお''、''winecfg'' がオーディオドライバを見つけられない時 (Selected driver: (none)) は、[https://wiki.winehq.org/Wine_User's_Guide#Using_Regedit レジストリから設定してください]。例えば、64ビットの標準の wine-1.9.7 で32ビットの Windows アプリケーションを使ったときにマイクが機能しない場合、次の手順でサウンドハードウェア (サウンドプレイバックとマイク) にアクセスできるようになります: ''regedit'' を開いて ''HKEY_CURRENT_USER > Software > Wine > Drivers'' と進んで ''Audio'' という名前の文字列を追加して値を ''alsa'' に設定してください。また、[[#WINEPREFIX|prefix を再作成]]することで解決するかもしれません。

===== MIDI サポート =====

90年代のビデオゲームでは音楽に [[MIDI]] を使うのが人気でした。古いゲームを動かすときは、設定をしないと音楽が再生できないのは珍しくありません。
Wine には素晴らしい MIDI サポートがあります。ただし、最初に MIDI がシステムで動くように設定する必要があります。詳しくは [[MIDI]] を見てください。そして Wine が適切な MIDI 出力を使うように設定しなくてはなりません。

==== 他の依存パッケージ ====

一部のアプリケーションは追加のパッケージを必要とします [https://wiki.winehq.org/Building_Wine#Satisfying_Build_Dependencies]。

* 暗号化サポートは、{{Pkg|lib32-gnutls}} をインストールしてください。
* 32ビットの prefix におけるジョイスティックとゲームパッドのサポートは、{{Pkg|lib32-sdl2}} をインストールしてください。
* 32ビットプログラムでのメディアプレイバックは、{{Pkg|lib32-gst-plugins-base}}、{{Pkg|lib32-gst-plugins-good}}、{{Aur|lib32-gst-plugins-bad}}、{{Aur|lib32-gst-plugins-ugly}}、{{Aur|lib32-gst-libav}} をインストールしてください。
* [[Wikipedia:ja:NTLM|NTLM]] 認証は、{{Pkg|samba}} をインストールしてください。

=== Prefix 内の依存パッケージ ===

システムの依存パッケージとは別に、多くのプログラムは追加のフォントや DLL が Wine prefix にインストールされていることを要求します [https://wiki.winehq.org/FAQ#My_application_says_some_DLL_or_font_is_missing._What_do_I_do?]。これらの依存関係は、[https://github.com/Winetricks/winetricks Winetricks] を使うことでインストールすることができます。Winetricks はシンプルなパッケージマネージャで、何かをインストールしたり、設定の調整を行ったりする ''verb'' が用意されています。Winetricks には2つの使い方があります:

* CLI から: {{ic|winetricks ''verb_name''}} を実行する。
* GUI から: {{Pkg|zenity}} か {{Pkg|kdialog}} をインストールし、{{ic|winetricks}} を実行する。

依存パッケージ間の衝突により、何でもできる "完璧な" Windows 環境を構築することができない場合があります [https://github.com/Winetricks/winetricks/issues/1580#issuecomment-666604256] [https://github.com/Winetricks/winetricks/issues/469]。そうするよりも、(重要な設定やデータが存在しない限り) prefix を使い捨てにして、異なる依存パッケージを必要とするプログラム毎に個別の prefix を使用するほうが良いです。[[#WINEPREFIX]] 環境変数を使うことで、どの prefix に対して verb を実行するかを指定することができます。

プログラムが必要とする verb を知るには、多くのトライアンドエラーが必要になる可能性があります。一部のより一般的な依存パッケージは [https://usebottles.com/database/dependencies/ Bottles の依存関係ページ]を、また以下のプログラム固有のリソースを参照してください:

* [https://appdb.winehq.org/ Wine Application Database]: 公式のリソースですが、古く、他のものと比べてメンテナンスされていないかもしれません。
* [https://lutris.net/ Lutris のウェブサイト]。このサイトで扱われているゲームを実行しようとしているならば、ドロップダウンメニューをクリックして、''View install script'' をクリックすることで Lutris で使用されている Winetricks の verb を見ることができます。
* [https://github.com/bottlesdevs/programs Bottles のプログラムリポジトリ]。小さいですが、ゲーム以外もあります。
* [https://www.protondb.com/ ProtonDB]。Proton は Wine とは異なる互換性があります (それに加え、このサイトを見るなら単に Proton を使うほうが良いかもしれません)。しかし、ユーザーが書き込んだ verb は使えるかもしれません。
** また、[https://github.com/GloriousEggroll/proton-ge-custom proton-ge-custom] に同梱されている変化の速い [https://github.com/Open-Wine-Components/ULWGL-protonfixes/ protonfixes] ツールのソースを参照することもできます。しかし、このツールはゲームを修正する追加の Proton と GE のパッチが存在していることを想定しています。

ゲームの prefix を管理するのに多くの時間が掛かる場合は、prefix を管理してくれるサードパーティのアプリケーションを使う方が簡単かもしれません。

=== サードパーティ製アプリケーション ===

以下のアプリケーションは、独自のコミュニティーとウェブサイトを持っており、メインの Wine コミュニティによって '''サポートされていません'''。詳しくは [https://wiki.winehq.org/Third_Party_Applications Wine Wiki] を見てください。

* {{App|[[Bottles]]|Wine 用のグラフィカルな prefix マネージャであり、ランナーマネージャ。GTK ベース。|https://usebottles.com/|{{AUR|bottles}}}}
* {{App|[[CrossOver]]|公式の商用版 Wine。グラフィカルなインターフェイスと包括的なエンドユーザーサポートを提供しています。|https://www.codeweavers.com|{{AUR|crossover}}}}
* {{App|[[Wikipedia:Lutris|Lutris]]|Wine のゲームから Linux ネイティブのゲーム、エミュレータまで、あらゆるゲームに対応するゲームランチャー (prefix の管理機能が存在します)。|https://lutris.net|{{Pkg|lutris}}}}
* {{App|[[Wikipedia:PlayOnLinux|PlayOnLinux]]|Wine のグラフィカルな prefix マネージャです。プログラムのインストールと設定を支援するスクリプトが含まれています。|https://www.playonlinux.com|{{AUR|playonlinux}}}}
* {{App|[[Proton]]|[[Steam]] のために作成された互換ツール。Wine と追加のコンポーネントをベースとしています。互換性のリストは [https://www.protondb.com/ ProtonDB] を見てください。|https://github.com/ValveSoftware/Proton|{{AUR|proton}}}}
* {{App|PyWinery|シンプルでグラフィカルな Wine 用の prefix マネージャ。|https://github.com/ergoithz/pywinery|{{AUR|pywinery}}}}
* {{App|Q4Wine|Wine のグラフィカルな prefix マネージャ。[[Qt]] テーマを Wine の設定に適用することで見た目を統合することができます。|https://sourceforge.net/projects/q4wine/|{{AUR|q4wine-git}}}}
* {{App|WINEgui|ユーザフレンドリーな WINE グラフィカルインターフェイス。|https://gitlab.melroy.org/melroy/winegui|{{AUR|winegui}}, {{AUR|winegui-bin}}}}

== 設定 ==

通常 Wine の設定には以下を用います:

* [https://wiki.winehq.org/Winecfg winecfg] は Wine の GUI 設定ツールです。{{ic|winecfg}} を実行することで起動できます。
* [https://wiki.winehq.org/Regedit regedit] は Wine のレジストリ編集ツールです。{{ic|regedit}} を実行することで起動できます。WineHQ の記事 [https://wiki.winehq.org/Useful_Registry_Keys Useful Registry Keys] を見てください。
* [https://wiki.winehq.org/Control control] は Windows コントロールパネルの Wine 実装です。{{ic|wine control}} を実行することで起動できます。
* 完全なリストは WineHQ の [https://wiki.winehq.org/List_of_Commands List of Commands] を見てください。

=== WINEPREFIX ===

デフォルトでは、Wine の設定ファイルとインストールされた Windows プログラムは {{ic|~/.wine}} に置かれます。このディレクトリは一般的に "Wine prefix" や "Wine bottle" と呼ばれます。Windows プログラムを動かしたり、Wine を設定するための {{ic|winecfg}} を動かすと自動的にフォルダが作成されます。そして Wine で動いているプログラムはこのフォルダの下のツリーを {{ic|C:}} (C ドライブ) とみなします。

{{Note|Wine の prefix には前方互換性がありません。新しいバージョンの Wine は、必要に応じて自動的に古い prefix をアップグレードします。アップグレードされると、その prefix は古いバージョンの Wine で動作しなくなる場合があります。[https://github.com/GloriousEggroll/wine-ge-custom/releases/tag/7.0-GE-8-LoL]}}

{{ic|WINEPREFIX}} [[環境変数]]を設定することで、Wine が使用する prefix の場所を指定することができます。これは Windows プログラムにそれぞれ違う設定をしたいときに便利です。初めて新しい Wine の prefix を使ってプログラムを起動した時、Wine は自動で C ドライブとレジストリの入ったディレクトリを作成します。

例えば、{{ic|1=env WINEPREFIX=~/.win-a wine program-a.exe}} と {{ic|1=env WINEPREFIX=~/.win-b wine program-b.exe}} のようにプログラムを動かせば、2つのプログラムは別の C ドライブとレジストリを使います。

{{Warning|Wine の prefix は[[Wikipedia:ja:サンドボックス (セキュリティ)|サンドボックス]]ではありません！Wine で動いているプログラムは依然として Wine システムの外にアクセスすることが可能です (例えば、Wine の prefix に関係なく、{{ic|Z:}} は {{ic|/}} にマッピングされます)。}}

Windows プログラムや GUI ツールを実行せずに、デフォルトの prefix を作成するには:

$ env WINEPREFIX=~/.customprefix wineboot -u

=== WINEARCH ===

Wine はデフォルトで 64 ビットの環境を作ります。この挙動は {{ic|WINEARCH}} [[環境変数]]を使うことで変更できます。{{ic|~/.wine}} ディレクトリの名前を変更し、{{ic|1=$ WINEARCH=win32 winecfg}} を実行して新しい Wine 環境を作成してください。これで 32 ビットの Wine 環境が作られます。{{ic|WINEARCH}} を設定しないときは 64 ビット環境が作られます。

{{ic|WINEPREFIX}} を使うことで {{ic|win32}} 環境と {{ic|win64}} 環境を分離することができます:

$ WINEARCH=win32 WINEPREFIX=~/win32 winecfg
$ WINEPREFIX=~/win64 winecfg

{{ic|WINEARCH}} を ''winetricks'' などの他の Wine プログラムと一緒に使うこともできます (以下の例では Steam):

WINEARCH=win32 WINEPREFIX=~/.local/share/wineprefixes/steam winetricks steam

prefix のアーキテクチャは、レジストリファイルを見ることで確認できます。以下のコマンドは、{{ic|~/.wine}} prefix のシステムレジストリを読み込み、アーキテクチャタイプに応じて {{ic|1=#arch=win32}} か {{ic|1=#arch=win64}} を返します:

$ grep '#arch' ~/.wine/system.reg

=== フォント ===

Wine アプリケーションで読みづらいフォントや不足しているフォントがある場合、フォントがインストールされていないのかもしれません。Wine からアクセスできるようにシステムフォントにすべてリンクするには:

$ cd ${WINEPREFIX:-~/.wine}/drive_c/windows/Fonts && for i in /usr/share/fonts/**/*.{ttf,otf}; do ln -s "$i"; done

Wine はフォントをレンダリングするために FreeType を使用します。FreeType のデフォルトは数リリース前に変更されました。Wine でプログラムを実行する際に以下の[[環境変数]]を使ってみてください:

FREETYPE_PROPERTIES="truetype:interpreter-version=35"

他の手段として、Wine prefix に [[MS フォント#インストール|Microsoft の TrueType フォントをインストール]]するというものがあります。これでもうまく行かない場合、まず {{ic|winetricks corefonts}} を実行し、最後の手段として {{ic|winetricks allfonts}} を実行してみてください。

プログラムを実行した後は、すべての Wine サーバを kill して {{ic|winecfg}} を実行してください。これでフォントが読めるようになるはずです。

フォントが汚く見える場合、[https://wiki.winehq.org/FAQ#How_do_I_edit_the_Wine_registry.3F regedit] を使って以下のテキストファイルを Wine のレジストリにインポートしてください:

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Wine\X11 Driver]
"ClientSideWithRender"="N"

高解像度ディスプレイにおいては、dpi の値を winecfg で調整できます。

[[フォント設定#fontconfig をサポートしていないアプリケーション]] も参照してください。

==== フォントスムージングの有効化 ====

Wine のフォントレンダリングを改善する良い方法として、cleartype フォントスムージングを有効化するというものがあります。
"Subpixel smoothing (ClearType) RGB" を有効化するには:

{{hc|/tmp/fontsmoothing.reg|2=
REGEDIT4

[HKEY_CURRENT_USER\Control Panel\Desktop]
"FontSmoothing"="2"
"FontSmoothingOrientation"=dword:00000001
"FontSmoothingType"=dword:00000002
"FontSmoothingGamma"=dword:00000578
EOF
}}

$ WINE=${WINE:-wine} WINEPREFIX=${WINEPREFIX:-$HOME/.wine} $WINE regedit /tmp/fontsmoothing.reg 2> /dev/null

詳細は [https://askubuntu.com/a/219795 元になった回答] を見てください。

=== デスクトップランチャーメニュー ===

Windows アプリケーションインストーラによってショートカットが作成された場合、Wine は [[.desktop]] ファイルを作成します。Arch Linux ではデフォルトで以下の場所にファイルが作成されます:

* デスクトップショートカットは {{ic|~/Desktop}} に保存されます
* スタートメニューのショートカットは {{ic|~/.local/share/applications/wine/Programs/}} に保存されます

{{Note|1=Wine は全てのユーザー共通で Windows アプリケーションをインストールすることはできません。{{ic|.desktop}} ファイルが {{ic|/usr/share/applications}} に作成されることはありません。詳しくは WineHQ バグの [https://bugs.winehq.org/show_bug.cgi?id=11112 11112] を見てください。}}

{{Tip|メニューがインストールしてもファイルが''作られなかったり''もしくは消えてしまった場合、{{ic|wine winemenubuilder}} を使ってください。}}

==== Wine ユーティリティのメニューエントリを作成する ====

デフォルトでは、Wine をインストールしても Wine に付属しているソフトウェア (例:''winecfg'' や ''winebrowser'' など) のデスクトップメニューやアイコンは作られません。{{AUR|wine-installer}} か {{AUR|wine-installer-git}} をインストールすることでこれらを作成できます。あるいは、以下の指示により、これらのアプリケーションのエントリを追加できます。

まず、ベースメニューを作るために Wine で Windows プログラムをインストールします。ベースメニューが作られたら、{{ic|~/.local/share/applications/wine/}} に以下のファイルを作成してください:

{{hc|wine-browsedrive.desktop|2=
[Desktop Entry]
Name=Browse C: Drive
Comment=Browse your virtual C: drive
Exec=wine winebrowser c:
Terminal=false
Type=Application
Icon=folder-wine
Categories=Wine;
}}

{{hc|wine-uninstaller.desktop|2=
[Desktop Entry]
Name=Uninstall Wine Software
Comment=Uninstall Windows applications for Wine
Exec=wine uninstaller
Terminal=false
Type=Application
Icon=wine-uninstaller
Categories=Wine;
}}

{{hc|wine-winecfg.desktop|2=
[Desktop Entry]
Name=Configure Wine
Comment=Change application-specific and general Wine options
Exec=winecfg
Terminal=false
Icon=wine-winecfg
Type=Application
Categories=Wine;
}}

そして {{ic|~/.config/menus/applications-merged/}} に次のファイルを作成してください:

{{hc|wine.menu|<nowiki>
<!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"
"http://www.freedesktop.org/standards/menu-spec/menu-1.0.dtd">
<Menu>
<Name>Applications</Name>
<Menu>
<Name>wine-wine</Name>
<Directory>wine-wine.directory</Directory>
<Include>
<Category>Wine</Category>
</Include>
</Menu>
</Menu>
</nowiki>}}

以上の設定でアイコンが表示されない、あるいはアイコンが醜い場合は、有効になっているアイコンセットにランチャーのためのアイコンが存在しないのが原因です。使いたいアイコンの位置を指定してアイコンの設定を置き換えてください。プロパティメニューのアイコンをクリックしても同じことができます。これらのショートカットをサポートしているアイコンセットは {{AUR|gnome-colors-icon-theme}} です。

==== メニューエントリを削除する ====

Wine によって作成されるエントリは {{ic|~/.local/share/applications/wine/Programs/}} にあります。プログラムの ".desktop" エントリを削除すればメニューからアプリケーションが削除されます。

Wine による不要な拡張を削除するのに加えて、以下のコマンドを実行: [https://wiki.winehq.org/FAQ#How_do_I_clean_the_Open_With_List.3F]

$ rm ~/.local/share/mime/packages/x-wine*
$ rm ~/.local/share/applications/wine-extension*
$ rm ~/.local/share/icons/hicolor/*/*/application-x-wine-extension*
$ rm ~/.local/share/mime/application/x-wine-extension*

場合によっては、KDE の Wine サブメニューからアイテムを完全に削除するために、{{ic|wine-*.menu}} も {{ic|/.config/menus/}} から削除する必要があります。

=== 外観 ===

XP のような見た目のテーマを[https://archive.org/download/zune-desktop-theme/ZuneDesktopTheme.msi ダウンロード]できます。これをインストールするには、[https://wiki.winehq.org/Wine_User%27s_Guide#Running_.msi_files この上流の wiki 記事] を見てください。最後に、''winecfg'' を使ってそのテーマを選択してください。

{{Note|上記のリンクのテーマは、Windows XP の prefix バージョンが設定された32ビット prefix にしかインストールできません。64ビット prefix にインストールするには、一時的な32ビット prefix を作成し、テーマをインストールし、{{ic|drive_c/Windows/Resources/Themes}} から {{ic|Zune}} フォルダと {{ic|Zune.theme}} ファイルを64ビットの prefix の同じ場所にコピーする必要があるかもしれません。}}

Wine staging のユーザは、現在の GTK テーマにマッチさせるために、代わりに ''winecfg'' の Staging セクションの ''Enable GTK3 Theming'' オプションを有効化する必要があるかもしれません。

=== 印刷 ===

''win32 prefix'' で wine アプリケーション (例: MS Word) を使ってプリンター (ローカル・ネットワーク両方) を使用するには {{Pkg|lib32-libcups}} パッケージをインストールしてください。それから wine アプリケーションを再起動 (''wineboot'') してください。

=== ネットワーク ===

アプリケーションが LTS や HTTPS 接続を行えるようにするために、場合によっては Wine のインストール後に {{pkg|lib32-gnutls}} を[[インストール]]する必要があります。

ICMP (ping) の場合、[https://wiki.winehq.org/FAQ#Failed_to_use_ICMP_.28network_ping.29.2C_this_requires_special_permissions WineHQ FAQ] で説明されているように Wine はネットワークアクセスを必要とします:

# setcap cap_net_raw+epi /usr/bin/wine-preloader

このコマンドを実行した後に問題が発生する場合 (キャッチされない例外や特権命令など)、以下を実行してケーパビリティを削除してください:

# setcap -r /usr/bin/wine-preloader

== 使用法 ==

{{Warning|Wine アプリケーションを root として実行/インストールしないでください! 詳細は [https://wiki.winehq.org/FAQ#Should_I_run_Wine_as_root.3F Wine FAQ] を見てください。}}

Wine の使用法に関する一般的な情報は [https://wiki.winehq.org/Wine_User%27s_Guide#Using_Wine Wine User's Guide] を見てください。

Wine における特定の Windows アプリケーションに関する追加の情報は [https://appdb.winehq.org/ Wine Application Database (AppDB)] を見てください。

=== Wayland ===

{{Warning|ネイティブな [[Wayland]] ドライバはまだ実験段階です。}}

デフォルトでは、Wine は Wayland 上で動作する際に [[Xwayland]] を使用します。これは、ほとんどのユーザーにとって十分なエクスペリエンスを得られます。バージョン 9.0rc1 現在、Wine はネイティブな Wayland サポートにおいて大幅な進捗があり、一部のユースケースにおいては使用に適した状態になっています。

最近の Wine バージョンで追加されたネイティブな Wayland ドライバを試すには、以下の手順を踏んでください:

* [https://wiki.winehq.org/FAQ#How_do_I_edit_the_Wine_registry.3F regedit] で以下のテキストファイルを Wine レジストリにインポートしてください:

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Wine\Drivers]
"Graphics"="x11,wayland"

* {{Ic|DISPLAY}} [[環境変数]]を空にして、Xwayland を使用せずにネイティブな Wayland ドライバを強制してください:

$ DISPLAY= wine example.exe

2番目の手順で Wine が停止した場合は、インストールされている Wine のバージョンが新しい Wayland ドライバのサポートありでビルドされていることを確認してください。

=== Wine の実行を停止する ===

起動済みのプログラムを停止する ({{ic|wine}} に対して {{ic|wine}}、あるいは {{ic|wineconsole}} に対して Ctrl+C を押す) と、バックグラウンドでプロセスが実行中のままになってしまうかもしれません。例えば:
{{bc|<nowiki>$ ps -xo pid,cmd
PID CMD
297 -bash
933 /usr/bin/wineserver
939 C:\windows\system32\services.exe
942 C:\windows\system32\winedevice.exe
950 C:\windows\system32\explorer.exe /desktop
954 C:\windows\system32\winedevice.exe
965 C:\windows\system32\plugplay.exe
977 C:\windows\system32\svchost.exe -k LocalServiceNetworkRestricted
984 C:\windows\system32\rpcss.exe
997 mbserver.exe
1017 start.exe /exec
1019 C:\windows\system32\conhost.exe --unix --width 169 --height 40 --server 0x10
1021 Z:\home\wineuser\mbserver.exe
1030 ps -xo pid,cmd</nowiki>}}
実行中の {{ic|wine}} と {{ic|wineconsole}} プロセスは、[https://wiki.winehq.org/Wine_User%27s_Guide#-k_%5Bn%5D wineserver -k] コマンドを使って一度にすべて停止できます。例えば:
{{bc|<nowiki>$ wineserver -k 15</nowiki>}}
このコマンドは {{ic|WINEPREFIX}} 変数に依存しているため、カスタムの Wine prefix を使用している場合は、以下のコマンドを使用してください:
{{bc|<nowiki>$ WINEPREFIX=~/wine/my-prefix wineserver -k</nowiki>}}
上記の例で挙げたプログラムを両方停止するコマンドは以下のようになります:
{{bc|<nowiki>$ kill 997 1021</nowiki>}}

== ヒントとテクニック ==

=== Wineconsole ===

''.exe'' を実行してゲームファイルにパッチを適用する必要がある場合 (例えば古いゲームにワイドスクリーン対応 MOD を適用するなど)、通常の方法で Wine から ''.exe'' を実行しても何も起きないことがあります。その場合、ターミナルを開いて以下のコマンドを実行してください:

$ wineconsole cmd

そして、プログラムがあるフォルダまで移動して、''.exe'' プログラムを実行してください。

=== Winetricks ===

[https://wiki.winehq.org/Winetricks Winetricks] は Windows プログラムを動かすために必要なランタイムなどをインストールするためのスクリプトです。DirectX 9.x や MSXML (Microsoft Office 2007 や Internet Explorer で必要)、Visual ランタイムライブラリなどをインストールできます。

使うには {{pkg|winetricks}} パッケージ (あるいは {{AUR|winetricks-git}}) を[[インストール]]してください。そして、以下で実行してください:
$ winetricks

GUI を使う場合、{{pkg|zenity}} (GTK) か {{pkg|kdialog}} (Qt) を[[インストール]]してください。

=== パフォーマンス ===

==== CSMT ====

CSMT は OpenGL 呼び出しに対して別のスレッドを使うことでパフォーマンスを著しく向上させる技術で、Wine によって使われています。Wine 3.2 から CSMT はデフォルトで有効になっています。

アプリケーションによっては CSMT がパフォーマンスを劣化させることがあります。そのような場合、{{ic|wine regedit}} を実行してレジストリエディタを起動し、''HKEY_CURRENT_USER -> Software > Wine > Direct3D > csmt'' に DWORD の値 0x00 を設定して、CSMT を無効化してください。

詳細:
:CSMT の開発者 Stefan Dösinger による [https://www.phoronix.com/forums/showthread.php?93967-Wine-s-Big-Command-Stream-D3D-Patch-Set-Updated/page3&s=7775d7c3d4fa698089d5492bb7b1a435 Phoronix Forum の議論]

==== ゲームで強制的に OpenGL モードにする ====

多くのゲームには OpenGL モードがあり''多くの場合''デフォルトの DirectX モードより良いパフォーマンスが出ます。OpenGL レンダリングを有効にする方法は''それぞれのアプリケーションによる''一方、多くのゲームは {{Ic|-opengl}} パラメータを認識します。

$ wine ''/path/to/3d_game.exe'' -opengl

詳しい情報は、それぞれのアプリケーションのドキュメントや Wine の [https://appdb.winehq.org AppDB] を見てください。

==== VKD3D-Proton ====

[https://github.com/HansKristian-Work/vkd3d-proton VKD3D-Proton] は [https://wiki.winehq.org/Vkd3d VKD3D] のフォークで、Vulkan を用いて完全な Direct3D 12 API の実装を目指しています。このプロジェクトは、Proton で Direct3D 12 をサポートし、DirectX 12 ゲームのパフォーマンスと互換性を向上させるものです。

VKD3D-Proton を使うには、{{AUR|vkd3d-proton-mingw}} または {{AUR|vkd3d-proton-bin}} をインストールしてください。そして、以下のコマンドを実行し、prefix (デフォルトでは {{ic|~/.wine}}) で VKD3D-Proton を有効化してください:
$ WINEPREFIX=''your-prefix'' setup_vkd3d_proton install

{{Warning|VKD3D-Proton は DirectX 12 の DLL を上書きします。これは、オンラインマルチプレイヤーゲームではチートとみなされる場合があり、あなたのアカウントが '''BAN''' されてしまうかもしれません。自己責任で使用してください!}}

==== DXVK ====

[https://github.com/doitsujin/dxvk DXVK] は、DirectX 9、10、11 の Vulkan による実装です。ほとんどのゲームにおいて、こちらのほうが WineD3D ドライバよりもパフォーマンス及び互換性で勝っています。

DXVK を使うには、{{AUR|dxvk-mingw}} または {{AUR|dxvk-bin}} をインストールしてください。そして、以下のコマンドを実行し、prefix (デフォルトでは {{ic|~/.wine}}) で DXVK を有効化してください:

$ WINEPREFIX=''your-prefix'' setup_dxvk install

DXVK をデュアルグラフィックスの環境で使用する場合、Wine は専用の GPU を優先します。ノート PC では、省電力のためにこれを上書きできます:

$ VK_DRIVER_FILES=/usr/share/vulkan/icd.d/''your_driver''.json wine ''executable''

===== HDR サポート =====

[[Gamescope]] と一緒に使用する場合、DXVK (V2.1+) は HDR10 ディスプレイのサポートを提供します ([[AMDGPU]] ユーザのみ)。詳細は [[HDR モニターのサポート]] を参照してください。

==== Gallium Nine ====

Gallium ベースの mesa ドライバを使用する場合 (ほとんどの場合 AMD と Intel のカード)、DirectX 9 で優れたパフォーマンスを出すネイティブな [https://docs.mesa3d.org/gallium-nine.html Gallium Direct3D ドライバ]があります。このドライバは DXVK によりほとんど使われなくなりましたが、Vulkan のサポートがない場合に依然として便利である場合があります。DXVK と Gallium Nine のパフォーマンスは[https://www.supergoodcode.com/the-finale/#this-is-no-longer-a-zink-blog ほぼ同じである]はずです。

Gallium Nine を使うには {{Pkg|wine-nine}} をインストールしてください。これはスタンドアローンパッケージで、どの Wine バージョンとも併用できます。有効化されているか確かめるには {{ic|wine ninewinecfg}} を実行してください。

古い Intel graphics (4 から 7 世代: GMA 3000, GMA 4500, HD 2000-5000; 2006年-2014年) では、Mesa 21.2 以降 Crocus Gallium ドライバが i965 の代わりに使用されるはずです。Wine を実行する前に以下の環境変数を [[Export]] してください:

MESA_LOADER_DRIVER_OVERRIDE=crocus

=== Wine によるファイルの関連付けの解除 ===

デフォルトで、大量のフォーマットで Wine はデフォルトアプリケーションとして設定されます。Windows にしかないフォーマットもあり (例: {{ic|vbs}} や {{ic|chm}})、その場合 Wine で開けるようになるのは便利かもしれません。しかしながら、他のフォーマット (例: {{ic|gif}}, {{ic|jpeg}}, {{ic|txt}}, {{ic|js}}) が Wine の素っ気ない Internet Explorer やメモ帳で開かれるのは迷惑と感じることもあるでしょう。

Wine のファイルの関連付けは {{ic|~/.local/share/applications/}} にある {{ic|wine-extension-''extension''.desktop}} というファイルによって設定されます。関連付けを解除したい拡張子の名前が入っているファイルを削除してください。もしくは、Wine の関連付けを全て削除したい場合:

$ rm -f ~/.local/share/applications/wine-extension*.desktop
$ rm -f ~/.local/share/icons/hicolor/*/*/application-x-wine-extension*

古いキャッシュを削除:

$ rm -f ~/.local/share/applications/mimeinfo.cache
$ rm -f ~/.local/share/mime/packages/x-wine*
$ rm -f ~/.local/share/mime/application/x-wine-extension*

キャッシュをアップデート:

$ update-desktop-database ~/.local/share/applications
$ update-mime-database ~/.local/share/mime/

削除しても、アプリケーションによってファイルの関連付けが設定されたら、Wine はファイルの関連付けを作成し続けます。

=== Wine がファイルの関連付けをしないようにする ===

{{Note|以下の作業は、{{ic|/usr/share/wine/wine.inf}} を変更しない限り、ファイルの関連付けをアップデートさせたくない WINEPREFIX それぞれに対して行わなければなりません。}}

以下の方法は、ファイルの関連付けを作成することを防止しますが、XDG .desktop ファイルは保持します (メニューなどに表示されるかもしれません)。

winecfg を通して Wine がファイルの関連付けをしないように設定するには、Desktop Integration タブのチェックボックス "Manage File Associations" のチェックを解除する必要があります。[https://wiki.winehq.org/FAQ#How_can_I_prevent_Wine_from_changing_the_filetype_associations_on_my_system_or_adding_unwanted_menu_entries.2Fdesktop_links.3F Wine FAQ] を見てください。

レジストリを通して同じ変更を加えるには、以下に文字列 {{ic|Enable}} を {{ic|N}} という値で追加してください:

HKEY_CURRENT_USER\Software\Wine\FileOpenAssociations

''まず、{{ic|FileOpenAssociations}} キーを作成する必要があるかもしれません。''

この変更をコマンドラインを通して加えるには、以下のコマンドを実行してください:

$ wine reg add "HKEY_CURRENT_USER\Software\Wine\FileOpenAssociations" /v Enable /d N

新しく作成される WINEPREFIX に対してこの変更をデフォルトで加えるようにしたい場合、{{ic|/usr/share/wine/wine.inf}} を編集し、例えば以下の行を {{ic|[Services]}} セクションに追加してください:
HKCU,"Software\Wine\FileOpenAssociations","Enable",2,"N"

パッケージのアップグレードの際にこのファイルが上書きされないようにするには、pacman フックを作成して上記の変更が自動的に加えられるようにしてください:

{{hc|1=/etc/pacman.d/hooks/stop-wine-associations.hook|2=

[Trigger]
Operation = Install
Operation = Upgrade
Type = Path
Target = usr/share/wine/wine.inf

[Action]
Description = Stopping Wine from hijacking file associations...
When = PostTransaction
<nowiki>Exec = /bin/sh -c '/usr/bin/grep -q "HKCU,\"Software\\\Wine\\\FileOpenAssociations\",\"Enable\",2,\"N\"" /usr/share/wine/wine.inf || /usr/bin/sed -i "s/\[Services\]/\[Services\]\nHKCU,\"Software\\\Wine\\\FileOpenAssociations\",\"Enable\",2,\"N\"/g" /usr/share/wine/wine.inf'</nowiki>
}}

詳細は [[Pacman#フック]] を見てください。

=== Windows バイナリを暗黙的に Wine で実行する ===

{{pkg|wine}} パッケージは ''binfmt'' ファイルをインストールします。このファイルにより、Windows プログラムを直接実行できるようになります。例えば、{{ic|''./myprogram.exe''}} は、{{ic|wine ''./myprogram.exe''}} と入力した時と同じように振る舞います。デフォルトでサービスは起動時に開始されます。Wine をインストールした後に再起動していないのであれば、{{ic|systemd-binfmt.service}} を[[起動]]することで、すぐに使えるようになります。

{{Note|Windows バイナリが[[実行可能属性|実行可能]]であることを確認してください。さもないと、バイナリは実行されません。}}

=== 異なる解像度でのデュアルスクリーン ===

デュアルヘッドの設定でディスプレイの解像度が異なったときに問題が起きる場合はおそらく {{Pkg|lib32-libxrandr}} をインストールしていません。

{{Pkg|lib32-libxinerama}} をインストールすることでも wine のデュアルスクリーンの問題が解決することがあります (例えば、最右や最下のモニタでアプリケーションのボタンやメニューがクリックできなくなったり、アプリケーションのインターフェイスが再描画されなかったり、アプリケーションのエリアでマウスカーソルがドラッグの状態のまま固まったりします)。

=== 光学メディアを焼く ===

CD や DVD を焼くためには、{{ic|sg}} [[カーネルモジュール]]をロードする必要があります。

=== 光学メディアイメージの適切なマウント ===

一部のアプリケーションは光学メディアがドライブにあるかの確認をします。ほとんどはデータの確認だけなので、{{ic|winecfg}} で CD-ROM ドライブのパスを正しく設定すれば問題ありません。
しかし、アプリケーションによってはメディアの名前やシリアルナンバーを確認するので、イメージを特別なプロパティを使ってマウントする必要があります。

fuse ベースの仮想ドライブ (例えば Acetoneiso) など、仮想ドライブツールはこれらのメタデータを扱えないことがあります。[[CDemu]] は適切にこれを処理します。

=== ゲーム内に FPS オーバーレイを表示 ===

Wine には全てのグラフィカルアプリケーションで使える FPS モニター機能があります。環境変数 {{ic|1=WINEDEBUG=fps}} を設定してください。FPS は標準出力にアウトプットされます。{{pkg|xosd}} パッケージの ''osd_cat'' を使うことでウィンドウ上に FPS を表示することが可能です。ヘルパースクリプト [https://gist.github.com/anonymous/844aefd70bb50bf72b35 winefps.sh] を見てください。

=== Wine を別のユーザアカウントで実行する ===

{{Warning|これは適切なサンドボックス化方法ではなく、ファイルシステムのパーミッションによるホームディレクトリの保護しか行いません。サンドボックス化する必要がある場合は、[[firejail]] や [[bubblewrap]] のようなものを使用するべきです (これらには、rootful Xorg が必要であったり、音声の問題が発生したりといった欠点がありません)。}}

別のユーザーアカウントで Wine を実行することで、Windows アプリケーションからホームディレクトリにアクセスできてしまうという懸念を減らすことができます。

まず Wine 用の[[ユーザーアカウント]]を作成:

# useradd -m -s /bin/bash wineuser

他の TTY に切り替えて、通常通り X WM や DE を起動するか、このまま読み続けてください。

{{Note|以下の方法は Xorg の root を有効にしている場合にのみうまく行きます。メインのユーザで {{ic|xhost}} を実行する方法については [[Xorg#Rootless Xorg]] を見てください。}}

新しいユーザーアカウントを使って Wine アプリケーションを開けるようにするために、X サーバーのパーミッションリストに新しいユーザーを追加してください:

$ xhost +SI:localuser:wineuser

以下のコマンドを使って Wine を実行することができます ({{ic|env}} を使用して Wine の起動する環境を設定します):

$ sudo -u wineuser env HOME=/home/wineuser USER=wineuser USERNAME=wineuser LOGNAME=wineuser wine ''arguments''

以下のようにシェルスクリプトを使って Wine による Windows アプリケーションの実行を自動化できます:
{{hc|1=/usr/local/bin/runaswine|2=
#!/bin/sh
xhost +SI:localuser:wineuser
sudo -u wineuser env HOME=/home/wineuser USER=wineuser USERNAME=wineuser LOGNAME=wineuser wine "$@"}}

シェルスクリプトを保存したら、以下のようにして Wine アプリケーションを起動できます:

$ runaswine ''"C:\path\to\application.exe"''

Wine を実行するたびにパスワードが要求されないようにしたい場合、sudoers ファイルに次のエントリを追加してください: {{ic|1=''mainuser'' ALL=(wineuser) NOPASSWD: ALL}}。詳しくは [[Sudo#設定]]を参照。

{{ic|winecfg}} を Wine ユーザーで起動して、"Desktop Integration" タブから Wine ユーザーのホームディレクトリ以外のディレクトリのバインドを全て削除することを推奨します (Wine によって起動したプログラムが Wine ユーザーのホームディレクトリの外のファイルにアクセスできないようにするため)。

[[PulseAudio]] を使用している場合、Wine プログラムで音が鳴らなくなってしまいます。他のユーザーの PulseAudio デーモンに Wine ユーザーからアクセスできるようにする情報が [[PulseAudio/サンプル#複数のユーザーが同時に PulseAudio を使えるようにする]]にあります。

=== Temp ディレクトリを tmpfs 上に置く ===

Wine が物理ディスク上に一時ファイルを書き込まないようにするために、''tmpfs'' のような別の場所を使うことができます。Wine の一時ファイルのデフォルトのディレクトリを削除し、シンボリックリンクを作成してください:

$ rm -r ~/.wine/drive_c/users/$USER/Temp ~/.wine/drive_c/windows/temp
$ ln -s /tmp/ ~/.wine/drive_c/users/$USER/Temp
$ ln -s /tmp/ ~/.wine/drive_c/windows/temp

=== Mono/Gecko をインストールさせない ===

Gecko や Mono がシステムと Wine prefix のどちらにも存在しない場合、Wine はそれらをインターネットからダウンロードするか尋ねるダイアログを表示します。Gecko や Mono が必要ない場合、このダイアログを無効化できます: {{ic|WINEDLLOVERRIDES}} [[環境変数]]に {{ic|1=mscoree=d;mshtml=d}} を設定してください。

=== Vulkan ===

デフォルトの Wine Vulkan ICD ローダは、ほとんどのアプリケーションでうまく動作しますが、高度な機能はサポートしていません (例えば Vulkan レイヤー)。これらの機能を使うには、公式の Vulkan SDK をインストールしなければなりません。オリジナルの Vulkan パッチの作者の [https://github.com/roderickc/wine-vulkan GitHub ページ] のステップ 2 から 4 を見てください。

=== Wine のファイルバインディングを除去する ===

セキュリティ上の理由により、事前にインストールされている Wine バインディングを削除することは有用である場合があります。これにより、Windows アプリケーションはファイルマネージャやブラウザ (Firefox は EXE ファイルを直接 Wine で開くことができます) から直接起動できなくなります。
以下を {{ic|1= /etc/pacman.conf}} の {{ic|1= [options]}} セクションに追加してください:

NoExtract = usr/lib/binfmt.d/wine.conf
NoExtract = usr/share/applications/wine.desktop

=== Wine が自身のアプリケーションをデフォルトとして設定してしまう ===

Wine は、prefix を作成 (または更新) する度に、それに応じて Notepad や Winebrowser などのバンドルされたアプリをデフォルトのテキストエディタやウェブブラウザとして設定します。

この望ましくない挙動を回避する方法は、以下の[[環境変数]]を設定することです:

$ WINEDLLOVERRIDES=winemenubuilder.exe=d ...

=== WineASIO ===

Wine で専門的なオーディオサポートが必要な場合、{{Aur|wineasio}} を使うことができます。これは、Wine 用の ASIO インターフェイスを提供し、[[JACK]] で使用できます。

wineasio を使うためには、あなたのユーザアカウントを {{ic|realtime}} [[ユーザーとグループ#ユーザーグループ|ユーザーグループ]]に追加する必要があります。

次に、wineasio を wine prefix に登録する必要があります。必要に応じて32ビットバージョンや64ビットバージョンに登録してください:

$ regsvr32 /usr/lib32/wine/i386-windows/wineasio32.dll
$ wine64 regsvr32 /usr/lib/wine/x86_64-windows/wineasio64.dll

=== explorer.exe の起動を無効化する ===

X がインストールされていない状態でテキストモード ([https://www.winehq.org/docs/wineusr-guid%3Cbr%20/%3Ee/cui-programs Command User Interface]) の実行ファイルを実行すると、実行ファイルの起動中に以下のエラーが発生するかもしれません:

{{bc|0060:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
0060:err:winediag:nodrv_CreateWindow L"The explorer process failed to start."
0060:err:systray:initialize_systray Could not create tray window
}}

{{ic|wine}} はデフォルトで explorer.exe を起動することが原因です。{{ic|ps}} の出力を見ればわかる通り、{{ic|wineconsole}} ですら {{ic|explorer.exe /desktop}} を起動します。

以下のように環境変数を設定することで、systray も含めて explorer の起動を無効化することができます:

$ WINEDLLOVERRIDES="explorer.exe=d" wine program.exe

CUI プログラムによっては、services.exe も無効化することによって目盛り使用量を最小限にすることができるかもしれません:

$ WINEDLLOVERRIDES="explorer.exe,services.exe=d" wine program.exe

== トラブルシューティング ==

一般的なヒントは [https://wiki.winehq.org/Wine_User%27s_Guide#Troubleshooting_.2F_Reporting_bugs Wine User's Guide] と [https://wiki.winehq.org/FAQ Wine FAQ] (特に [https://wiki.winehq.org/FAQ#Troubleshooting Troubleshooting] セクション) を見てください。

また、特定のアプリケーションでの推奨事項は [https://appdb.winehq.org/ Wine AppDB] を見てください。

=== インストールの一般的な問題 ===

それぞれの [[#WINEPREFIX|Wine prefix]] には、インストールされているプログラムからレジストリに至るまで多くの永続的な状態があります。プログラムのインストールに関する問題のトラブルシューティングの第一歩として、隔離された prefix を作成するか、{{ic|rm -rf ~/.wine}} でデフォルトの prefix を削除してみるべきでしょう。後者のコマンドは、デフォルトの prefix に追加したプログラムと設定を全て削除します。

=== libc.so.6 のロードエラー ===

wine を実行すると以下のエラーが発生することがあります:

{{hc|$ wine cmd|
/usr/bin/wine: error while loading shared libraries: libc.so.6: cannot create shared object descriptor: Operation not permitted
}}

これは、{{ic|mmap2}} のシステムコールが失敗したことが原因です:

mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EPERM (Operation not permitted)

これは [https://bugzilla.kernel.org/show_bug.cgi?id=198355 Linux カーネルの既知のバグ]です。

[[sysctl]] の {{ic|vm.mmap_min_addr}} の値をデフォルトの {{ic|65536}} から変更することで、問題が解決するようです:

# sysctl -w vm.mmap_min_addr=32768

=== Xwayland の問題 ===

[[Xwayland]] で Wine を使用する場合、以下のような問題を避けるために winecfg の Graphics タブで "Emulating a virtual desktop" のオプションを有効化できます:

* チラつき
* 誤ったウィンドウの位置
* 誤ったマウスカーソルの位置とクリック
* キーボード検出

仮想デスクトップを無効化すると winecfg のウィンドウがマウスとキーボードに反応しなくなってしまう場合、以下のコマンドで明示的にどれかの仮想デスクトップ上で winecfg を起動することで、再び使えるようにできます:

$ wine explorer /desktop=name,800x600 winecfg

Wayland で GUI ウィンドウ (winecfg など) を起動すると、何も表示されずコンソールに以下のエラーが出力される場合:

{{hc|$ wine winecfg|
Authorization required, but no authorization protocol specified

008c:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
008c:err:winediag:nodrv_CreateWindow L"The explorer process failed to start."
008c:err:systray:initialize_systray Could not create tray window
}}

{{ic|DISPLAY}} 変数を {{ic|:1}} に設定してみてください:

$ DISPLAY=:1 wine winecfg

=== キーボード入力ができない ===

ウィンドウマネージャがフォーカスを切り替えないことにより発生することがあります。''winecfg'' の ''Graphics'' タブで、'Allow the window manager...' オプションを無効化してください。あるいは、ウィンドウモードを 'Emulate a virtual desktop' に設定してください。
* ''Window settings'' のオプションを全て切り替えて、''Apply'' をクリックし、そしてオプションを全て戻すと問題が解決するという人もいます。これがうまく行かない場合、上記の方法を試してください。

アプリケーションからフォーカスを移動させた後にキーボードが動作しなくなる場合、レジストリを編集してみてください:
* ''HKEY_CURRENT_USER\Software\Wine\X11 Driver'' に行き、文字列 ''UseTakeFocus'' を追加し、それを ''N'' にセットする。
* あるいは、[[#Winetricks|Winetricks]] を使って値をセットできます: {{bc|1=$ winetricks usetakefocus=n}}

=== アプリケーションが起動に失敗する ===

一部の古いゲームやアプリケーションは、[[Wikipedia:ja:カレントディレクトリ|カレントディレクトリ]]が実行ファイルの場所と同じであることを期待します。これらの実行ファイルを他の場所から実行すると、正しく起動しなくなってしまいます。このような問題を防ぐには、Wine を実行する前に {{ic|cd ''exeへのパス''}} を使ってください。

== 参照 ==

* [https://www.winehq.org/ Wine Homepage]
* [https://wiki.winehq.org/ Wine Wiki]
* [https://appdb.winehq.org/ Wine Application Database (AppDB)] - 特定のアプリケーションを動作させるための情報 (特定のアプリケーションの既知の問題、評価、ガイドなど)
* [https://forum.winehq.org/ Wine Forums] - あなたが FAQ と AppDB を見た''後''に質問するための素晴らしい場所
* [[Gentoo:Wine]]
* [https://www.darlinghq.org/ Darling] - MacOS ソフトウェア向けの Wine と似たプロジェクト
* [https://github.com/wineasio/wineasio WineASIO] - WineASIO プロジェクトの GitHub ページ。追加の情報あり。

{{TranslationStatus|Wine|2024-06-16|810069}}

Electron パッケージガイドライン

2025-05-06T11:51:28Z

Oech3: バージョンの先頭のvは最近は無い/* electron-builder と system electron の併用について */

[[Category:Arch パッケージガイドライン]]
[[en:Electron package guidelines]]
[[pt:Electron package guidelines]]
{{Package Guidelines}}

このドキュメントでは [[Electron]] の [[PKGBUILD]] を書く時の標準とガイドラインについて触れています。

== Electron システムを使う ==

Arch Linux には {{Pkg|electron}} と [https://archlinux.org/packages/?q=electron electron*] パッケージがあり、これらを使うことでシェルスクリプトのラッパーを介して Electron アプリケーションを実行できます:

{{bc|#!/bin/sh

exec electron /path/to/''appname''/ "$@"}}

{{ic|''appname''/}} ディレクトリあるいは {{ic|''appname''.asar}} という名前のファイルバンドルは {{ic|resources/app/}} フォルダ (または {{ic|resources/app.asar}}) などのビルド済み Electron アプリケーションとして存在します。他のファイルは全て Electron ランタイムのコピーであり、パッケージからは削除しても問題ありません。

=== コンパイル済みの拡張をシステムの Electron でビルド ===

一部の Electron アプリケーションは Electron ランタイムにリンクされたコンパイル済みのネイティブ拡張を含んでおり、適切なバージョンの Electron を使ってビルドする必要があります。npm/yarn は常にビルド済みのプライベートな Electron コピーでビルドしてしまうため、{{ic|package.json}} から Electron の依存関係にパッチをあてて、システムの Electron と同じバージョンを使うようにしてください。ビルドシステムは必要なビルド済みコピーをダウンロードして、ネイティブ拡張をコンパイルし、パッケージを作成するので、{{ic|package()}} で不要なファイルを削除します。

もしくは、{{ic|package.json}} から Electron の依存を削除して、npm の実行前に環境変数を設定することもできます:

export npm_config_target=$(cat /usr/lib/electron/version | tail -c +2)
export npm_config_arch=x64
export npm_config_target_arch=x64
export npm_config_disturl=https://atom.io/download/electron
export npm_config_runtime=electron
export npm_config_build_from_source=true
HOME="$srcdir/.electron-gyp" npm install

{{ic|HOME}} を {{ic|$srcdir}} のパスに設定することで、ビルド時に {{ic|HOME}} ディレクトリにファイルが作られなくなります。{{ic|.electron-gyp}} キャッシュを利用するコマンドのパスは調整してください。

詳しくは [https://www.electronjs.org/docs/latest/tutorial/using-native-node-modules#using-npm Electron docs] を参照。

=== electron-builder と system electron の併用について ===

多くのプロジェクトでは、Javascript ファイルと Electron バイナリのビルドとパッケージ化に '''electron-builder''' を使用しています。デフォルトでは、electron-builder はパッケージ管理ファイル (例:{{ic|package.json}}) で定義されている electron の全バージョンをダウンロードします。これは、electron バイナリを、システム electron が使うためで、一見、帯域幅を節約したくなりますが、それは望ましくありません。electron-builder は、Electron のカスタムパスとアプリケーションがパッケージされているバージョンをそれぞれ指定するために、{{ic|electronDist}} と {{ic|electronVersion}} のコンフィギュレーションを提供します。

electron-builder の設定ファイル(例:{{ic|electron-builder.json}})を探して、以下の設定を追加してください。

* {{Pkg|electron34}} の場合は {{ic|/usr/lib/electron34}} に設定してください。
* {{ic|electronVersion}} を {{ic|/usr/lib/electron/version}} の内容から、先頭の {{ic|v}}があれば、それを除いたものに変更します。

これを適用するパッケージ {{AUR|rocketchat-desktop}} {{AUR|ubports-installer-git}}

[https://www.electron.build/configuration/configuration electron-builder 設定]

また、CLI を使用して、以下のように設定を変更・追加することもできます。

./node_modules/.bin/electron-builder --linux --x64 --dir $dist -c.electronDist=$electronDist -c.electronVersion=$electronVer

これらのオプションをすべて指定しないと、動作しないので注意してください。

== アーキテクチャ ==

[[PKGBUILD#arch]] を見てください。

コンパイル済みのネイティブ拡張を含む Electron パッケージはアーキテクチャに依存します。他のパッケージはアーキテクチャに依存しません。

パッケージにビルド済みの Electron のコピーが含まれる場合、常にアーキテクチャに依存しています。

== ディレクトリ構造 ==

パッケージがアーキテクチャ依存の場合、{{ic|resources/app/}} ディレクトリを {{ic|/usr/lib/''appname''/}} にインストールしてください。非依存の場合は {{ic|/usr/share/''appname''/}} を使ってください。

パッケージにビルド済みの Electron のコピーを含む場合、全て {{ic|/opt/''appname''}} にコピーしてください。

Electron パッケージガイドライン

2025-05-06T11:39:46Z

Oech3: electron2をelectron34に変更/* electron-builder と system electron の併用について */

[[Category:Arch パッケージガイドライン]]
[[en:Electron package guidelines]]
[[pt:Electron package guidelines]]
{{Package Guidelines}}

このドキュメントでは [[Electron]] の [[PKGBUILD]] を書く時の標準とガイドラインについて触れています。

== Electron システムを使う ==

Arch Linux には {{Pkg|electron}} と [https://archlinux.org/packages/?q=electron electron*] パッケージがあり、これらを使うことでシェルスクリプトのラッパーを介して Electron アプリケーションを実行できます:

{{bc|#!/bin/sh

exec electron /path/to/''appname''/ "$@"}}

{{ic|''appname''/}} ディレクトリあるいは {{ic|''appname''.asar}} という名前のファイルバンドルは {{ic|resources/app/}} フォルダ (または {{ic|resources/app.asar}}) などのビルド済み Electron アプリケーションとして存在します。他のファイルは全て Electron ランタイムのコピーであり、パッケージからは削除しても問題ありません。

=== コンパイル済みの拡張をシステムの Electron でビルド ===

一部の Electron アプリケーションは Electron ランタイムにリンクされたコンパイル済みのネイティブ拡張を含んでおり、適切なバージョンの Electron を使ってビルドする必要があります。npm/yarn は常にビルド済みのプライベートな Electron コピーでビルドしてしまうため、{{ic|package.json}} から Electron の依存関係にパッチをあてて、システムの Electron と同じバージョンを使うようにしてください。ビルドシステムは必要なビルド済みコピーをダウンロードして、ネイティブ拡張をコンパイルし、パッケージを作成するので、{{ic|package()}} で不要なファイルを削除します。

もしくは、{{ic|package.json}} から Electron の依存を削除して、npm の実行前に環境変数を設定することもできます:

export npm_config_target=$(cat /usr/lib/electron/version | tail -c +2)
export npm_config_arch=x64
export npm_config_target_arch=x64
export npm_config_disturl=https://atom.io/download/electron
export npm_config_runtime=electron
export npm_config_build_from_source=true
HOME="$srcdir/.electron-gyp" npm install

{{ic|HOME}} を {{ic|$srcdir}} のパスに設定することで、ビルド時に {{ic|HOME}} ディレクトリにファイルが作られなくなります。{{ic|.electron-gyp}} キャッシュを利用するコマンドのパスは調整してください。

詳しくは [https://www.electronjs.org/docs/latest/tutorial/using-native-node-modules#using-npm Electron docs] を参照。

=== electron-builder と system electron の併用について ===

多くのプロジェクトでは、Javascript ファイルと Electron バイナリのビルドとパッケージ化に '''electron-builder''' を使用しています。デフォルトでは、electron-builder はパッケージ管理ファイル (例:{{ic|package.json}}) で定義されている electron の全バージョンをダウンロードします。これは、electron バイナリを、システム electron が使うためで、一見、帯域幅を節約したくなりますが、それは望ましくありません。electron-builder は、Electron のカスタムパスとアプリケーションがパッケージされているバージョンをそれぞれ指定するために、{{ic|electronDist}} と {{ic|electronVersion}} のコンフィギュレーションを提供します。

electron-builder の設定ファイル(例:{{ic|electron-builder.json}})を探して、以下の設定を追加してください。

* {{Pkg|electron34}} の場合は {{ic|/usr/lib/electron34}} に設定してください。
* {{ic|electronVersion}} を {{ic|/usr/lib/electron/version}} の内容から、先頭の {{ic|v}} を除いたものに変更します。

これを適用するパッケージ {{AUR|rocketchat-desktop}} {{AUR|ubports-installer-git}}

[https://www.electron.build/configuration/configuration electron-builder 設定]

また、CLI を使用して、以下のように設定を変更・追加することもできます。

./node_modules/.bin/electron-builder --linux --x64 --dir $dist -c.electronDist=$electronDist -c.electronVersion=$electronVer

これらのオプションをすべて指定しないと、動作しないので注意してください。

== アーキテクチャ ==

[[PKGBUILD#arch]] を見てください。

コンパイル済みのネイティブ拡張を含む Electron パッケージはアーキテクチャに依存します。他のパッケージはアーキテクチャに依存しません。

パッケージにビルド済みの Electron のコピーが含まれる場合、常にアーキテクチャに依存しています。

== ディレクトリ構造 ==

パッケージがアーキテクチャ依存の場合、{{ic|resources/app/}} ディレクトリを {{ic|/usr/lib/''appname''/}} にインストールしてください。非依存の場合は {{ic|/usr/share/''appname''/}} を使ってください。

パッケージにビルド済みの Electron のコピーを含む場合、全て {{ic|/opt/''appname''}} にコピーしてください。

NTFS

2025-04-28T19:09:05Z

Oech3: 古い記述と消えたAURパッケージを削除

[[Category:ファイルシステム]]
[[en:NTFS]]
[[ru:NTFS]]
[[zh-hans:NTFS]]
{{Related articles start}}
{{Related|ファイルシステム}}
{{Related|NTFS-3G}}
{{Related articles end}}

[[Wikipedia:NTFS|Wikipedia]] より:
:'''NTFS (New Technology File System)''' は、Microsoft が開発した独自のジャーナリングファイルシステムです。 Windows NT 3.1以降、これは WindowsNT ファミリのデフォルトのファイルシステムです。

[https://www.kernel.org/doc/html/latest/filesystems/ntfs3.html ntfs3] カーネルドライバーはファイルシステムの読み取りと書き込みをサポートしています。

{{Note|
* [[カーネル#公式サポートカーネル|公式サポートカーネル]]はすべて {{ic|1=CONFIG_NTFS3_FS=m}} でビルドされているため、これをサポートしています。又は、[[NTFS-3G]] FUSE ファイルシステムも使用できます。
* カーネルモジュールの作成者である Paragon Software は、NTFS3 用のユーザースペースユーティリティをまだリリースしていません。}}

== ヒントとテクニック ==

=== パフォーマンスの向上 ===

{{ic|prealloc}} {{man|8|mount}} オプションを有効にすると、並列書き込み操作の場合に断片化を減らすことができます (HDD の場合に最も役立ちます)

=== Windows で許可されていない名前の作成を防止する ===

NTFS 自体には使用する文字と名前に対する制限はありませんが、[https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions Windows には制限があります]

カーネルバージョン 6.2 以降、ntfs3 は {{ic|windows_names}} {{man|8|mount}} オプションをサポートします。互換性を厳密に維持するために使用します。

{{Note|[[udisks]] では、このオプションがデフォルトで有効になっています。}}

== 既知の課題 ==

=== マウントに必要な明示的なファイルシステムタイプ ===

{{ic|ntfs3}} をマウントにはファイルシステムタイプが必要です。

ファイルシステムをマウントするには、ファイルシステムタイプを {{ic|ntfs3}} と指定します。例えば、{{man|8|mount}} の {{ic|-t}}/{{ic|--types}} オプションを使用します。

# mount -t ntfs3 /dev/''sdxY'' ''/mnt''

== トラブルシューティング ==

=== unknown filesystem type 'ntfs' ===

NTFS を[[マウント]]する際に、以下のようなエラーが発生することがあります。

mount: ''/mnt'': unknown filesystem type 'ntfs'

[[NTFS#マウントに必要な明示的なファイルシステムタイプ|マウントに必要な明示的なファイルシステムタイプ]] を参照してください。

{{ic|ntfs}} パーティションのデフォルトドライバとして、{{ic|ntfs3}} を使用したい場合、このような [[udev]] ルールが役立ちます。

{{hc|/etc/udev/rules.d/ntfs3_by_default.rules|2=SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ntfs", ENV{ID_FS_TYPE}="ntfs3"}}

ただし、この方法は推奨されず、一部のサードパーティツールを混乱させるがあります。

=== パーティションがダーティとマークされているため、ntfs3 でマウントできない ===

正常な NTFS パーティション (つまり、NTFS-3G で正常にマウントされ、{{ic|ntfsfix --no-action}} がエラーを報告しないパーティション) をマウントしようとすると、次のエラーが発生する場合があります:

mount: ''/mnt'': wrong fs type, bad option, bad superblock on ''/dev/sdb1'', missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.

ntfs3 は、強制オプションを使用しないと、ボリュームがダーティとしてマークされているパーティションをマウントしません。{{ic|dmesg}} は次のように言って、状況の認識を明示的に支援します:

''sdb1'': volume is dirty and "force" flag is not set!

引数の {{ic|--clear-dirty}} を {{ic|ntfsfix}} に渡してクリーンアップしてみてください。[https://bbs.archlinux.org/viewtopic.php?id=271650]

== 参照 ==

* [https://docs.kernel.org/filesystems/ntfs3.html NTFS3 kernel documentation]
* [https://www.paragon-software.com/home/ntfs3-driver-faq/ NTFS3 Driver FAQ] – Paragon Software Group
* [https://openbenchmarking.org/result/2009092-NE-NTFSCOMPA56 NTFS3 performance comparison]

{{TranslationStatus|NTFS|2024-05-10|807012}}

NTFS

2025-04-28T18:16:44Z

Oech3: ntfsprogs-ntfs3を削除

[[Category:ファイルシステム]]
[[en:NTFS]]
[[ru:NTFS]]
[[zh-hans:NTFS]]
{{Related articles start}}
{{Related|ファイルシステム}}
{{Related|NTFS-3G}}
{{Related|Ufsd}}
{{Related articles end}}

[[Wikipedia:NTFS|Wikipedia]] より:
:'''NTFS (New Technology File System)''' は、Microsoft が開発した独自のジャーナリングファイルシステムです。 Windows NT 3.1以降、これは WindowsNT ファミリのデフォルトのファイルシステムです。

[https://www.kernel.org/doc/html/latest/filesystems/ntfs3.html ntfs3] カーネルドライバーはファイルシステムの読み取りと書き込みをサポートしています。

{{Note|
* バージョン 5.15 以降の[[カーネル#公式サポートカーネル|公式サポートカーネル]]はすべて {{ic|1=CONFIG_NTFS3_FS=m}} でビルドされているため、これをサポートしています。5.15 未満のカーネルでは、NTFS の読み取りと書き込みのサポートは [[NTFS-3G]] FUSE ファイルシステムによって提供されます。あるいは、{{pkg|ntfs3-dkms}} を使ってバックポートされた NTFS3 を使うこともできます。
* カーネルモジュールの作成者である Paragon Software は、NTFS3 用のユーザースペースユーティリティをまだリリースしていません。}}

== ヒントとテクニック ==

=== パフォーマンスの向上 ===

{{ic|prealloc}} {{man|8|mount}} オプションを有効にすると、並列書き込み操作の場合に断片化を減らすことができます (HDD の場合に最も役立ちます)

=== Windows で許可されていない名前の作成を防止する ===

NTFS 自体には使用する文字と名前に対する制限はありませんが、[https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions Windows には制限があります]

カーネルバージョン 6.2 以降、ntfs3 は {{ic|windows_names}} {{man|8|mount}} オプションをサポートします。互換性を厳密に維持するために使用します。

{{Note|[[udisks]] では、このオプションがデフォルトで有効になっています。}}

== 既知の課題 ==

=== マウントに必要な明示的なファイルシステムタイプ ===

{{ic|ntfs3}} をマウントにはファイルシステムタイプが必要です。

ファイルシステムをマウントするには、ファイルシステムタイプを {{ic|ntfs3}} と指定します。例えば、{{man|8|mount}} の {{ic|-t}}/{{ic|--types}} オプションを使用します。

# mount -t ntfs3 /dev/''sdxY'' ''/mnt''

== トラブルシューティング ==

=== unknown filesystem type 'ntfs' ===

NTFS を[[マウント]]する際に、以下のようなエラーが発生することがあります。

mount: ''/mnt'': unknown filesystem type 'ntfs'

[[NTFS#マウントに必要な明示的なファイルシステムタイプ|マウントに必要な明示的なファイルシステムタイプ]] を参照してください。

{{ic|ntfs}} パーティションのデフォルトドライバとして、{{ic|ntfs3}} を使用したい場合、このような [[udev]] ルールが役立ちます。

{{hc|/etc/udev/rules.d/ntfs3_by_default.rules|2=SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ntfs", ENV{ID_FS_TYPE}="ntfs3"}}

ただし、この方法は推奨されず、一部のサードパーティツールを混乱させるがあります。

=== パーティションがダーティとマークされているため、ntfs3 でマウントできない ===

正常な NTFS パーティション (つまり、NTFS-3G で正常にマウントされ、{{ic|ntfsfix --no-action}} がエラーを報告しないパーティション) をマウントしようとすると、次のエラーが発生する場合があります:

mount: ''/mnt'': wrong fs type, bad option, bad superblock on ''/dev/sdb1'', missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.

ntfs3 は、強制オプションを使用しないと、ボリュームがダーティとしてマークされているパーティションをマウントしません。{{ic|dmesg}} は次のように言って、状況の認識を明示的に支援します:

''sdb1'': volume is dirty and "force" flag is not set!

引数の {{ic|--clear-dirty}} を {{ic|ntfsfix}} に渡してクリーンアップしてみてください。[https://bbs.archlinux.org/viewtopic.php?id=271650]

== 参照 ==

* [https://docs.kernel.org/filesystems/ntfs3.html NTFS3 kernel documentation]
* [https://www.paragon-software.com/home/ntfs3-driver-faq/ NTFS3 Driver FAQ] – Paragon Software Group
* [https://openbenchmarking.org/result/2009092-NE-NTFSCOMPA56 NTFS3 performance comparison]

{{TranslationStatus|NTFS|2024-05-10|807012}}

セキュリティ

2025-04-27T11:57:33Z

Oech3: /* SUID ファイルと SGID ファイル */

[[Category:セキュリティ]]
[[Category:ファイルシステム]]
[[Category:ネットワーク]]
[[en:Security]]
[[fa:امنیت]]
[[ru:Security]]
[[zh-hans:Security]]
{{Related articles start}}
{{Related|PAM}}
{{Related|ケイパビリティ}}
{{Related|アプリケーション一覧/セキュリティ}}
{{Related|:カテゴリ:セキュリティ}}
{{Related articles end}}
この記事には、Arch Linux システムを[[Wikipedia:ja:ハードニング|ハードニング]]するための推奨事項とベストプラクティスを並べています。

== 概念 ==

* システムのセキュリティを厳重にしすぎると、使い物にならなくなることもある。セキュリティと利便性のバランスを取ることが重要だ。重要なのは、安全で ''かつ'' 使いやすいシステムを作ること。
* 最大の脅威は常にユーザー自身である。
* [[Wikipedia:ja:最小権限の原則|最小権限の原則]]: システムの各部分は、必要最小限の権限のみを持つべきであり、それ以上のアクセスは許可されるべきではない。
* 多層防御 (Defense in Depth): セキュリティは独立した複数の層で成り立つべきである。一つの層が突破されても、次の層が攻撃を食い止める仕組みが必要です。
* 少しだけ疑い深くなること。常に警戒すること。うますぎる話には注意すべきだ。それが本当である可能性は低いと思うこと。
* システムを100%安全にする方法はただ一つ。それはネットワークから切り離し、電源を切り、金庫に入れ、コンクリートで固め、二度と使用しないこと。
* 失敗を想定せよ。セキュリティが破られたときに備え、あらかじめ対応策を準備しておくこと。

==パスワード==
パスワードは安全な linux システムのかぎです。パスワードは[[ユーザーとグループ|ユーザーアカウント]], [[ディスク暗号化|暗号化されたファイルシステム]], [[SSH 鍵|SSH]]/[[GPG]] 鍵などを守ります。コンピュータを使用する人を信頼するのに使う主要な手段なので、安全なパスワードを選んでそれを保護するというのがセキュリティの大部分と言っても過言ではありません。

=== 安全なパスワードの選び方 ===

パスワードは、個人情報などから簡単に推測されないよう十分に複雑であり、また、ソーシャルエンジニアリングやブルートフォース攻撃などの手法で[[Wikipedia:Password cracking|クラック]]されないようにする必要があります。強力なパスワードの基本原則は、''長さ''と''ランダム性''に基づいています。暗号学では、パスワードの品質はその[[Wikipedia:Password strength#Entropy as a measure of password strength|エントロピー]]によって測られます。

安全でないパスワードには、以下のようなものが含まれます。また、以下のようなものを元に変更や置き換えを行った場合も同様に危険です。

* 個人を特定できる情報(例:ペットの名前、生年月日、市外局番、好きなビデオゲームなど)
* 単純な文字の置き換えを行った単語(例:{{ic|k1araj0hns0n}})最新の辞書攻撃ではこれらも簡単に解析可能
* 既存の "単語" や一般的な文字列の前後に数字・記号・文字を追加したもの(例:{{ic|DG091101%}})
* 一般的なフレーズや辞書にある単語を短く組み合わせたもの(例:{{ic|photocopyhauntbranchexpose}})文字の置き換えを行っても(例:{{ic|Ph0toc0pyh4uN7br@nch3xp*se}})、安全とは限らない(ただし、後述の "Diceware" を利用した場合は例外あり)
* [[Wikipedia:List of the most common passwords|最も一般的なパスワード]]のいずれか

最も安全なパスワードは、十分に長く(長いほど良い)ランダムなソースから生成されたものです。長いパスワードを使用することが重要です。[https://www.theregister.com/2019/02/14/password_length 弱いハッシュアルゴリズムを使用すると、8文字のパスワードハッシュはわずか数時間で解読可能] です。

{{Pkg|pwgen}} や {{AUR|apg}} のようなツールを使用すると、ランダムなパスワードを生成できます。しかし、これらのパスワードは覚えにくいことがあります。覚えやすくするための1つの方法は、長いパスワードを生成し、最初は最低限の安全な文字数だけを暗記し、完全な文字列を一時的に書き留めることです。時間をかけて入力する文字数を増やしていけば、最終的にはパスワードが筋肉の記憶として定着し、完全に覚える必要がなくなります。この方法は難易度が高いものの、辞書攻撃や "知的" ブルートフォース攻撃(単語の組み合わせや文字の置き換えを考慮する攻撃)に対して非常に強力です。

パスワード管理とは別に、{{Pkg|keepassxc}} はパスワード/パスフレーズの生成機能を提供します。GUI でカスタマイズ可能なパスワード生成機能があり、辞書ベースのパスフレーズもサポートされています。

パスワードを覚えるための1つの方法として、**記憶術(ニーモニック)**を利用することが挙げられます。
例えば、"the girl is walking down the rainy street" というフレーズは、以下のようなパスワードに変換できます。簡単な例:{{ic|t6!WdtR5}} より複雑な例:{{ic|t&6!RrlW@dtR,57}}
この方法は、パスワードを覚えやすくすることができますが、英単語の最初の文字には偏りがあることに注意が必要です([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]] を参照)

また、ランダムに生成したパスワードを紙に書いて安全な場所に保管するという方法も有効です。例えば、財布、カバン、金庫などに保管するのがよいでしょう。ほとんどの人は、デジタルセキュリティよりも物理的な貴重品の保護に関しては理解しやすいため、この方法は現実的です。

さらに、記憶術とランダム生成を組み合わせる方法も効果的です。例えば、長くランダムに生成したパスワードを[[パスワードマネージャ]]に保存し、それをマスターパスワードで管理する方法です。マスターパスワードは記憶し、絶対に保存しないようにします。この方法では、パスワードマネージャーがインストールされているシステムでのみパスワードにアクセスできるようになり、状況によっては不便にもなりますが、セキュリティ強化の側面もあります。一部のパスワードマネージャーにはスマートフォンアプリもあり、手入力が必要な場合にパスワードを表示することができます(この場合、完全にランダムなものではなく、タイピングしやすいが安全なパスワードを使うことも検討できます)ただし、マスターパスワードを忘れるとすべてのパスワードにアクセスできなくなるため、単一障害点になり得ることに注意が必要です。
また、一部のパスワードマネージャーは、保存するパスワードを暗号化するのではなく、マスターパスワードとサービス名から計算する方式を採用しており、新しいシステムでもデータ同期なしで使用できます。

覚えやすく、それでいて強力なパスワードの作成方法として、無関係な単語を複数組み合わせたパスフレーズを使うという方法もあります。この方法では、十分に長いフレーズを使用することで、辞書単語を使うことによるエントロピーの損失を補うことができます。この手法のエントロピーのトレードオフについては、[https://xkcd.com/936/ xkcdのコミック] に示されています。この方法の安全性は、選択可能な単語の集合が大きい(数千語以上)ことと、5〜7語以上のランダムな単語を選択することによって保証されます。攻撃者が選択可能な単語の集合と、使用する単語数を知っていたとしても、(選択可能な単語数) の (選択する単語数) 乗の通りのパスフレーズが生成可能であり、安全性が確保されます。詳細については [https://www.rempe.us/diceware/ Diceware] を参照してください。

さらに詳しい情報については、[https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] や [[Wikipedia:Password strength]] も参考になります。

=== パスワードの管理 ===

強力なパスワードを選んだら、それを安全に保管することが重要です。[[Wikipedia:Keylogger|キーロガー]] (ソフトウェアおよびハードウェア)、スクリーンロガー、[[Wikipedia:Social engineering (security)|ソーシャルエンジニアリング]]、[[Wikipedia:Shoulder surfing (computer security)|ショルダースーフィング]]に注意し、パスワードの使い回しを避けて、セキュリティの低いサーバーから不要な情報が漏れないようにしましょう。[[アプリケーション一覧/セキュリティ#パスワードマネージャ|パスワードマネージャ]]を使用すると、大量の複雑なパスワードを管理できます。パスワードマネージャーからアプリケーションに保存されたパスワードをコピー&ペーストして使用する場合は、毎回コピーした内容をクリアし、ログに保存されないようにしてください(例:プレーンテキストのターミナルコマンドにペーストしないようにし、{{ic|.bash_history}} などのファイルに保存されないようにします)ブラウザ拡張として実装されたパスワードマネージャは、[https://www.spookjs.com サイドチャネル攻撃]に脆弱である可能性があります。これを回避するためには、別のアプリケーションとして実行されるパスワードマネージャーを使用することが推奨されます。

原則として、強力なパスワードを覚えにくいからといって、セキュリティが低いパスワードを選んではいけません。パスワードはバランスを取る必要があります。強力なマスターパスワードと鍵で守られた暗号化された安全なパスワードデータベースを持つ方が、多くの似たような弱いパスワードを使うよりも優れています。パスワードを紙に書いて保管することも、[https://www.schneier.com/blog/archives/2005/06/write_down_your.html] で示されているように、ソフトウェアの脆弱性を避けつつ物理的なセキュリティを確保できるため、非常に効果的です。

パスフレーズの強度のもう一つの側面は、それが他の場所から簡単に回復できないことです。

ディスク暗号化のパスフレーズをログインパスワードと同じに使用する場合(例えば、ログイン時に暗号化されたパーティションやフォルダを自動マウントする場合)、{{ic|/etc/shadow}} が暗号化されたパーティションに保存されるか、または強力な鍵導出関数 (i.e. yescrypt/argon2 や sha512 を PBKDF2 で使用、md5 や低回数の PBKDF2 は避ける) を使用して保存されたパスワードハッシュを使うようにしてください (詳細については [[SHA hashes#SHA パスワードハッシュ|SHA パスワードハッシュ]] を参照してください)

{{Tip|Arch Linux は [https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのハッシュアルゴリズム]を yescrypt に変更しました。もしデフォルトをカスタマイズしていない場合は、{{ic|passwd}} を実行してパスワード変更を行うなどして下さい。}}

パスワードデータベースをバックアップする場合、そのコピーが他のパスフレーズで保護されていないことを確認してください。例えば、暗号化されたドライブや認証されたリモートストレージサービスなどです。もしそのような保護が施されている場合、必要なときにアクセスできなくなります。役立つ方法としては、データベースがバックアップされているドライブやアカウントをマスターパスワードの簡単な暗号学的ハッシュで保護することです。バックアップ場所のリストを保持してください。もしもマスターパスワードが漏洩したと疑われる場合、その場所すべてでパスワードを即座に変更し、マスターパスワードから導出された鍵で保護されたすべてのバックアップと場所も変更する必要があります。

データベースをセキュアにバージョン管理するのは非常に複雑な場合があります。もしその方法を選択するなら、すべてのデータベースバージョンでマスターパスワードを更新する手段を持っている必要があります。マスターパスワードが漏洩したときにそれを即座に知るのは難しいことがあります。他の人がパスワードを発見するリスクを減らすために、定期的にパスワードを変更することを選ぶかもしれません。もしデータベースのコピーの管理が失われたと感じた場合、そのコピーがブルートフォース攻撃によってマスターパスワードを解読される前に、そのデータベース内のすべてのパスワードを変更する必要があります。

=== パスワードのハッシュ ===

ハッシュは一方向の関数です。つまり、入力を計算せずにそのハッシュを解読することは不可能になるように設計されています (例:MD5、SHA)

パスワードハッシュ関数は、ユーザー入力 (パスワード) を計算せずに解読することが不可能になるように設計されています(例:bcrypt)[[Wikipedia:Key derivation function|鍵導出関数]] (KDF; 例:yescrypt、scrypt、PBKDF2) は、入力 (マスターキーやパスワード) から秘密鍵 (例:AESキー、パスワードハッシュ) を導出するために設計された暗号アルゴリズムです。したがって、KDF はパスワードハッシュ関数としても使用できる複数の用途に対応します。

デフォルトでは、Arch Linux はユーザーパスワードをルート専用の読み取り可能な {{ic|/etc/shadow}} ファイルにハッシュ化して保存します。これは、他のユーザーのパラメータが保存される世界に読み取り可能な {{ic|/etc/passwd}} ファイルから分離されています。詳細は [[ユーザーとグループ#ユーザーデータベース]] を参照してください。また、[[#root の制限]] も参照してください。

パスワードは '''passwd''' コマンドを使用して設定され、このコマンドはシステムの暗号化関数でパスワードを[[Wikipedia:Key stretching|ストレッチ]]し、その後 {{ic|/etc/shadow}} に保存されます。パスワードは[[Wikipedia:Salt (cryptography)|ソルト]]も施され、[[Wikipedia:Rainbow table|レインボーテーブル]]攻撃に対して防御されます。詳細は[https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils Linux でパスワードがどのように保存されているか(Shadow ユーティリティを使ったハッシュの理解)]を参照してください。

パスワードハッシュは定義されたフォーマットに従って保存されるため、新たな ''passwd'' コマンドの実行に対してメソッドとパラメータを設定することができます。したがって、{{ic|/etc/shadow}} ファイルに保存された個々のハッシュは、システムでサポートされているハッシュ関数の異種混合になる可能性があります。

フォーマット、ハッシュメソッド、およびパラメータに関する詳細は、{{man|5|crypt}} を参照してください。

{{ic|/etc/login.defs}} ファイルでは、[https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのパスワードハッシュメソッド]{{ic|ENCRYPT_METHOD YESCRYPT}} とそのパラメータ {{ic|YESCRYPT_COST_FACTOR}} が設定されます。

例えば、デフォルトの {{ic|YESCRYPT_COST_FACTOR}} パラメータを増加させると、パスワードからハッシュを導き出すために必要な計算時間が対数的に増加します。これは、システムがユーザーのログインを認証する際や、第三者がパスワードの秘密を取得しようとする場合にも適用されます。

これに対して、SHA-512 ハッシュ関数の計算時間は、パラメータにより線形的に影響されます。以前の Arch のデフォルトについては [[SHA パスワードハッシュ]] を参照してください。yescrypt アルゴリズムは内部で SHA-256、HMAC、およびPBKDF2 を使用してパスワードハッシュを計算することに注意してください。主な理由は、これらの広く使用され、テストされた関数の良い特性を組み合わせ、攻撃への耐性を強化することです。例えば、SHA の多用途性が原因で、この関数のハードウェアサポートが提供され、SHA ハッシュの計算性能が著しく向上したため、パスワードハッシュ関数としての使用が次第に時代遅れになりつつあります。

=== pam_cracklib を用いた強力なパスワードの強制 ===

''pam_pwquality'' は、[[Wikipedia:Dictionary attack|辞書攻撃]]に対する保護を提供し、システム全体で強制できるパスワードポリシーを設定するのに役立ちます。これは ''pam_cracklib'' をベースにしており、そのオプションとの後方互換性があります。

{{Pkg|libpwquality}} パッケージを[[インストール]]してください。

{{Warning|デフォルトでは、''root'' アカウントはこのポリシーの影響を受けません。}}

{{Note|
* ''root'' アカウントを使用すると、設定したパスワードポリシーをバイパスするユーザーパスワードを設定できます。これは一時的なパスワードを設定する際に便利です。
* 現在のパスワードに関するセキュリティガイドライン(例:NISTなど)では、特別な文字を強制することは推奨されていません。なぜなら、それらはしばしば予測可能な変更を引き起こすだけだからです。
}}

例えば、以下のポリシーを強制したい場合:

* エラーが発生した場合にパスワードを2回入力する (retry オプション)
* 最小長10文字 (minlen オプション)
* 新しいパスワードを入力する際、古いパスワードとは少なくとも6文字異なること (difok オプション)
* 最低1桁の数字 (dcredit オプション)
* 最低1つの大文字 (ucredit オプション)
* 最低1つの小文字 (lcredit オプション)
* 最低1つのその他の文字 (ocredit オプション)
* "myservice" および "mydomain" という単語を含めない
* root にもこのポリシーを強制する

{{ic|/etc/pam.d/passwd}}ファイルを以下のように編集します:

{{bc|1=
#%PAM-1.0
password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root
password required pam_unix.so use_authtok sha512 shadow
}}

{{ic|password required pam_unix.so use_authtok}} は、''pam_unix'' モジュールに対してパスワードの入力を促さず、代わりに ''pam_pwquality'' で提供されたものを使用するように指示します。

詳細については、{{man|8|pam_pwquality}} および {{man|8|pam_unix}} のマニュアルページを参照してください。

== CPU ==

=== マイクロコード ===

CPU のマイクロコードに対する重要なセキュリティ更新プログラムをインストールする方法については、[[マイクロコード]] を参照してください。

=== ハードウェアの脆弱性 ===

CPU の中には、ハードウェアの脆弱性を含んでいるものがあります。これらの脆弱性の一覧と、特定の使用シナリオに合わせてこれらの脆弱性を緩和するためにカーネルをカスタマイズするのに役立つ緩和策の選択ガイドについては、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/ kernel documentation on hardware vulnerabilities] を参照してください。

既知の脆弱性の影響を受けているかどうかを確認するには、以下を実行してください。

$ grep -r . /sys/devices/system/cpu/vulnerabilities/

ほとんどの場合、カーネルとマイクロコードを更新することで、脆弱性を軽減することができます。

==== 同時マルチスレッディング (ハイパースレッディング) ====

[https://ja.wikipedia.org/wiki/%E5%90%8C%E6%99%82%E3%83%9E%E3%83%AB%E3%83%81%E3%82%B9%E3%83%AC%E3%83%83%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0 同時マルチスレッディング]] (SMT) は、インテル CPU のハイパースレッディングとも呼ばれ、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html L1 Terminal Fault] および [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html Microarchitectural Data Sampling] 脆弱性の原因となる可能性のあるハードウェア機能です。Linux カーネルとマイクロコードのアップデートには、既知の脆弱性に対する緩和策が含まれていますが、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html#virtualization-with-untrusted-guests 信頼できない仮想化ゲストが存在する場合、特定の CPU で SMT を無効にしたほうが良い場合があります。]

SMT は、システムのファームウェアで無効にできることがよくあります。詳細については、マザーボードまたはシステムのドキュメントを参照してください。また、以下の [[カーネルパラメータ]] を追加することで、カーネルで SMT を無効にすることができます。

l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force

== メモリ ==

===ハード化された malloc ===

[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened_malloc}}, {{AUR|hardened-malloc-git}}) は [https://ja.wikipedia.org/wiki/GNU_C%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA glibc] の malloc() をハード化した代替品です。元々は Android の [[Wikipedia:Bionic (software)|Bionic]] と [https://ja.wikipedia.org/wiki/Musl musl] に組み込むために開発されましたが、 x86_64 アーキテクチャの標準 Linux ディストリビューションのサポートにも組み込みました。

hardened_malloc はまだ glibc に統合されていませんが(支援とプルリクエストは歓迎します)、LD_PRELOAD と一緒に簡単に使用することができます。これまでのテストでは、 {{ic|/etc/ld.so.preload}} でグローバルに有効にすると、一握りのアプリケーションにしか問題を起こしません。例えば、{{ic|getrandom}} が標準のホワイトリストにないため、{{ic|seccomp}} 環境フラグが無効でないと {{ic|man}} は正常に動作しませんが、これはシステムコールを追加して再構築すれば簡単に修正可能です。hardened_malloc は性能上のコストがあるので、どの実装を使うかは攻撃対象領域と性能上の必要性に基づいてケースバイケースで決めるとよいでしょう。

スタンドアロンで試すには、hardened-malloc-preload ラッパースクリプトを使用するか、適切なプリロード値でアプリケーションを手動で開始します。

LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox

[[Firejail]] の正しい使い方は、その wiki ページにあります。また、hardened_malloc の設定可能なビルドオプションは、githubレポで見つけることができます。

== ストレージ ==

===ディスク暗号化===

[[ディスク暗号化]]、特に [[#パスワード|強力なパスフレーズ]] を使用したフルディスク暗号化は、物理的な回復からデータを守る唯一の方法です。これにより、コンピュータの電源がオフになっている場合や、対象のディスクがアンマウントされている場合にデータの機密性が保たれます。

ただし、コンピュータの電源が入っており、ドライブがマウントされている場合、そのデータは暗号化されていないドライブと同様に脆弱です。そのため、データパーティションがもう必要なくなったら、できるだけ早くアンマウントすることが最良の実践です。

また、[[Trusted Platform Module#LUKS による保存データの暗号化|TPMにキーを保存してドライブを暗号化]] することもできますが、過去に [https://tpm.fail 脆弱性] があり、キーは [https://pulsesecurity.co.nz/articles/TPM-sniffing TPMバススニッフィング攻撃] によって抽出される可能性があります。

[[dm-crypt]] のような特定のプログラムは、ユーザーが仮想ボリュームとしてループファイルを暗号化できるようにします。これは、システムの特定の部分だけを安全に保護する必要がある場合、フルディスク暗号化の合理的な代替手段です。

[[ディスク暗号化]] の記事で比較されているブロックデバイスやファイルシステムベースの暗号化方法は、物理メディア上のデータ保護には有効ですが、リモートシステム(例えば [[保存データ暗号化#クラウドストレージの最適化|クラウドストレージ]])に保存されたデータを保護するためには使用できません。そのため、個々のファイル暗号化が役立つ場合もあります。

ファイルを暗号化するためのいくつかの方法は次の通りです:

* 一部の [[アーカイブと圧縮|アーカイブおよび圧縮]] ツールは基本的な暗号化も提供します。例としては、[[7-Zip]] ({{ic|-p}} フラグ)、{{Pkg|zip}} ({{ic|-e}}フラグ) があります。これらのツールはクロスプラットフォームの互換性のためにカスタムアルゴリズムを使用している場合があるため、特別な注意を払って使用するべきです。[https://math.ucr.edu/~mike/zipattacks.pdf]
* [[GnuPG]] を使用してファイルを [[GnuPG#Encrypt and decrypt|暗号化]] できます。
* {{Pkg|age}} は、シンプルで使いやすいファイル暗号化ツールです。複数の受信者をサポートしており、SSH キーを使用した暗号化もサポートしているため、安全なファイル共有に役立ちます。

=== ファイルシステム ===

現在カーネルは {{ic|fs.protected_hardlinks}} や {{ic|fs.protected_symlinks}} sysctl スイッチが有効になっていればハードリンクやシンボリックリンクに関するセキュリティの問題を解決するので、world-writable なディレクトリを分離させるセキュリティ的な利点はもはや存在しません。

それでもディスク容量が消耗したときのダメージを低減させる荒っぽい方法として world-writable なディレクトリを含むパーティションが分割されることがあります。しかしながら、サービスを落とすには {{ic|/var}} や {{ic|/tmp}} などのパーティションを一杯にするだけで十分です。この問題の対処についてはもっと柔軟性のある方法が存在します (クォータなど)、またファイルシステムによっては関連する機能を持っていることがあります (btrfs はサブボリュームにクォータを設定できます)。

====マウントオプション====

最小特権の原則に従い、ファイルシステムは可能な限り制限の厳しいマウントオプションを使用してマウントするべきです(機能を失わない範囲で)

関連するマウントオプションは以下の通りです:

* {{ic|nodev}}: ファイルシステム上のキャラクタデバイスやブロックデバイスを解釈しない。
* {{ic|nosuid}}: set-user-identifier や set-group-identifier ビットを無効にする。
* {{ic|noexec}}: マウントされたファイルシステム上のバイナリを直接実行できないようにする。
** {{ic|/home}} に {{ic|noexec}} を設定すると、実行可能なスクリプトが禁止され、[[Wine]]、[[Steam]]、PyCharm、[[.NET]] などが動作しなくなります。
*** Wine は Windows バイナリの実行に {{ic|exec}} フラグを必要としません。ただし、Wine 自体を {{ic|/home}} にインストールする場合は必要です。
*** [[Steam]] を動作させるには、{{ic|/home/user/.local/share/Steam}} を [[fstab]] で {{ic|exec}} としてマウントできます。以下の設定を追加してください: {{bc|/home/user/.local/share/Steam /home/user/.local/share/Steam none defaults,bind,user,exec,nofail 0 0}}
** 一部のパッケージ(例:{{Pkg|nvidia-dkms}} のビルド)では、{{ic|/var}} に {{ic|exec}} が必要な場合があります。

データ用のファイルシステムは、常に {{ic|nodev}}、{{ic|nosuid}}、{{ic|noexec}} を指定してマウントするべきです。

マウントを検討すべきファイルシステム:

* {{ic|/var}}
* {{ic|/home}}
* {{ic|/dev/shm}}
* {{ic|/tmp}}
* {{ic|/boot}}

{{Tip|[[systemd#GPT パーティションの自動マウント|GPT パーティションの自動マウント]] を使用する場合、ESP および XBOOTLDR パーティションは [https://github.com/systemd/systemd-stable/commit/49804cfb71d3a79f433096e4cfb5616980171336 常に {{ic|noexec,nosuid,nodev}} で強化] されます。}}

==== スナップショット ====

ファイルシステムのスナップショットを利用する場合(例えば [[Btrfs]]、[[LVM]]、[[ZFS]] など)、スナップショットがユーザーが削除したと期待している機密情報を保持する可能性があることを理解することが重要です。特に、[[Snapper]] のような自動スナップショットツールを設定している場合、定期的またはシステムイベントに応じてスナップショットが作成されるため、この問題が発生しやすくなります。

以下は、{{ic|/home/}} 内の機密情報がスナップショットに残存する例です:

* 削除されたファイルやディレクトリ: ファイルシステム上から削除されたとしても、古いスナップショット内には残存している可能性があります。これは通常想定される動作ですが、{{ic|.local/share/Trash/}}、{{ic|.history}} などのファイルやディレクトリを保持する必要があるかどうかを検討すべきです。
* 一時ファイルやキャッシュ: アプリケーションによって生成された一時ファイルやキャッシュデータもスナップショットに含まれる可能性があります。例えば、暗号化されたディレクトリ内のファイルを開くと、サムネイル({{ic|.cache/thumbnails}})や作業用のコピーが作成され、それらがスナップショットに含まれる可能性があります。同様に、ブラウザの履歴({{ic|.mozilla/}}、{{ic|.config/chromium/}} など)も、削除される前にスナップショットに記録されている場合があります。

対応可能であれば、これらのディレクトリをスナップショットの対象から完全に除外することを検討してください。例えば、[[Btrfs]] を使用している場合、{{ic|.cache/}}、{{ic|.config/}}、{{ic|.local/}}、{{ic|.var/}} など、用途に応じたディレクトリをサブボリュームとして作成することで、スナップショットの影響を受けにくくできます。

{{Note|{{ic|.local/share/Trash}} を別のサブボリュームに移動すると、場合によっては [[GNOME/Files]] などでゴミ箱の機能が正常に動作しなくなる可能性があります。}}

===ファイルシステムのパーミッション===

デフォルトの [[パーミッション]] では、ほとんどのファイルが読み取り可能になっていますが、これを変更することで、{{ic|http}} ユーザーや {{ic|nobody}} ユーザーなどの非 root アカウントに侵入した攻撃者から貴重な情報を隠すことができます。[[chmod]] を使用して、グループやその他のユーザーからすべてのアクセス権を削除できます。

# chmod go-r ''path_to_hide''

{{Warning|この設定を広範囲に適用しないでください。1つの設定ファイルごとに適用し、非表示にする価値があるか、プログラムの動作に影響しないかを確認してください。グループが必要な場合は、{{ic|g}} をコマンドから削除するか、既に実行してしまった場合は {{ic|chmod g+r path}} で再度許可を追加する必要があるかもしれません。}}

考慮すべきパスの例:

* {{ic|/boot}}: [[パーティショニング#/boot|ブートディレクトリ]]、[[vmlinuz]] や [[initramfs]] image、または [[ユニファイドカーネルイメージ]] が含まれる場合があります。なお、[[systemd# GPT パーティションの自動マウント]] を使用する場合、デフォルトで安全なパーミッションが適用されます。
* {{ic|/etc/nftables.conf}}: [[nftables]] の設定ファイル({{Pkg|nftables}} および {{Pkg|iptables-nft}} に適用)
* {{ic|/etc/iptables}}: レガシーな [[iptables]] の設定ファイル({{Pkg|iptables}} に適用)

また、新しく作成されるファイルのセキュリティを向上させるために、デフォルトの [[umask]] 値 {{ic|0022}} を変更することも可能です。[https://apps.nsa.gov/iaarchive/library/ia-guidance/security-configuration/operating-systems/guide-to-the-secure-configuration-of-red-hat-enterprise.cfm NSA RHEL5 Security Guide] では最大限のセキュリティを確保するために、{{ic|0077}} を推奨しており、これにより所有者以外のユーザーが新しいファイルを読み取れなくなります。変更方法については [[Umask#マスクの値を設定]] を参照してください。

さらに、[[sudo]] を使用する場合、[[Sudo#Permissive umask|デフォルトの root umask]] を適用するよう設定することを検討してください。

=== SUID ファイルと SGID ファイル ===

[[Wikipedia:ja:Setuid|Setuid]] ビットや Setgid ビットが設定されたファイルには注意しましょう。このようなファイルの例としては、以下があります。

* [[PAM|unix_chkpwd]]
* chage, expiry, gpasswd, groupmems, [[passwd]], sg, ({{Pkg|shadow}})
* [[FUSE|fusermount3]], fusermount
* pkexec, polkit-agent-helper-1[https://github.com/polkit-org/polkit/pull/501] ([[polkit]])
* [[OpenSSH|ssh-keysign]]
* chfn, chsh, mount, newgrp, umount, wall, write ({{Pkg|util-linux}})
* [[sudo]], {{Pkg|sudo-rs}}, [[doas]], [[su]], su-rs, [[Kerberos|ksu]]
* [[firejail]]
* [[Dbus|dbus-daemon-launch-helper]]
* [[Chromium|chromium-sandbox]]
* [[Xorg|Xorg.wrap]]

このような実行ファイルの主なリスクとして、特権昇格の脆弱性があります。例えば [[Wikipedia:Setuid#Security impact]] を参照してください。[https://www.cvedetails.com/vulnerability-list/vendor_id-16224/product_id-36412/Calibre-ebook-Calibre.html][https://www.cvedetails.com/product/32625/Sudo-Project-Sudo.html?vendor_id=15714][https://www.cvedetails.com/vulnerability-list/vendor_id-16191/Firejail-Project.html]

SUID ビットが設定されているが root によって所有されていないファイル、または SGID ビットが設定されているファイルは、''典型的には''潜在的なリスクがより小さいですが、理論上、そのようなファイルに脆弱性が存在している場合は、依然として損害を与える可能性があります。通常、代わりに[[ケイパビリティ]]を割り当てることによって、Setuid や Setgid の使用を回避することが可能です。

{{Tip|SUID/SGID 実行ファイルを含むパッケージを最新に保って、脆弱性からシステムを守ることが肝心です。}}

SUID ビットか SGID ビットを持つファイルを {{ic|/usr/bin}} から探すには:

$ find /usr/bin -perm "/u=s,g=s"

== ユーザー設定 ==

=== root アカウントを日常的に使用しない ===

最小特権の原則に従い、root ユーザーを日常的に使用しないようにしてください。システムを使用する各人に非特権ユーザーアカウントを作成するか。一時的な特権アクセスには、必要に応じて [[sudo]] を使用する。

=== ログイン失敗後の遅延時間の設定 ===

以下の行を {{ic|/etc/pam.d/system-login}} に追加し、ログインに失敗した際に最低4秒の遅延を追加します。

{{hc|/etc/pam.d/system-login|2=
auth optional pam_faildelay.so delay=4000000
}}

{{ic|4000000}} は遅延させる時間をマイクロ秒単位で指定します。

===3回ログインを失敗したユーザーをロックアウトする===

{{Pkg|pambase}} 20200721.1-2 の時点では、デフォルトで {{ic|pam_faillock.so}} が有効になっており、15分間に3回ログインに失敗すると10分間ユーザをロックアウトします ({{Bug|67644}} を参照してください) このロックアウトはパスワード認証 (例:ログインと ''sudo'') にのみ適用され、SSH 経由の公開鍵認証はそのまま利用可能です。完全なサービス拒否を防ぐために、このロックアウトは root では無効になっています。

ユーザーをロック解除するには、次のようにします。

$ faillock --reset --user ''username''

デフォルトでは、ロック機構は {{ic|/run/faillock/}} にあるユーザーごとのファイルです。ディレクトリの所有者は root ですが、ファイルの所有者はユーザーなので、 {{ic|faillock}} コマンドはファイルを空にするだけで、root は必要ありません。

モジュール {{ic|pam_faillock.so}} は、ファイル {{ic|1=/etc/security/faillock.conf}} で設定することが可能です。ロックアウトのパラメータです。

* {{ic|unlock_time}} - ロックアウト時間 (秒単位、デフォルトは10分)
* {{ic|fail_interval}} - ロックアウトに失敗するとロックアウトされる時間 (秒単位、デフォルトは15分)
* {{ic|deny}} - ロックアウトするまでに何回ログインに失敗するか (デフォルトは 3)

{{Note|{{ic|1=deny = 0}} はロックアウトを無効化します}}

デフォルトでは、すべてのユーザーロックは再起動後に失われます。攻撃者がマシンをリブートできるのであれば、ロックは持続させた方が安全です。ロックを持続させるには、{{ic|1=/etc/security/faillock.conf}} の {{ic|dir}} パラメータを {{ic|/var/lib/faillock}} に変更する必要があります。

変更を反映させるために再起動する必要はありません。root アカウントのロックアウトを有効にする、集中ログイン (LDAP など) を無効にするなど、さらなる設定オプションについては {{man|5|faillock.conf}} を参照してください。

=== プロセスの数を制限する ===

信頼できないユーザーが大量に存在するシステムでは、一度に実行できるプロセスの数を制限して、[[Wikipedia:ja:Fork爆弾|フォーク爆弾]]などのサービス拒否攻撃を予防することが重要です。ユーザーやグループごとに実行できるプロセスの数は {{ic|/etc/security/limits.conf}} で定義することができ、デフォルトでは空になっています。以下の値をファイルに追加すると、実行できるプロセスが100個までに制限されます。{{ic|prlimit}} コマンドを使って一時的に上げられる最大数も200個までに制限します。ユーザーが普段実行するプロセスの数や、管理するハードウェアにあわせて適切な値に変更してください。

* soft nproc 100
* hard nproc 200

=== Wayland を使用する ===

[[Xorg]] よりも [[Wayland]] を使用することをお勧めします。Xorg の設計は現代のセキュリティ慣行より古く、多くの人が [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 は安全でないと考えています] 例えば、Xorg のアプリケーションは非アクティブな状態でもキーストロークを記録することがあります。

もし Xorg を実行しなければならないなら、[[Xorg#Rootless_Xorg|root での実行を避ける]]ことが推奨されます。Wayland 内では、XWayland 互換レイヤーは自動的に root レス Xorg を使用します。

== root の制限 ==
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。

=== su の代わりに sudo を使う ===
[[Su#セキュリティ|色々な理由]]から特権アクセスには [[su]] よりも [[sudo]] を使うほうが好ましいとされます。

* 通常の権限しか持たないユーザーが実行した特権コマンドのログを保持します。
* root アクセスを必要とする各ユーザーに root ユーザーのパスワードを与える必要がありません。
* 完全な root ターミナルは作成されないため、{{ic|sudo}} は root アクセスが必要ないコマンドを偶発的に ''root'' で実行してしまうことを防止します。これは[[Wikipedia:ja:最小権限の原則|最小権限の原則]]と合っています。
* 一つのコマンドを実行するためだけに完全な root アクセスを与える代わりに、ユーザーごとに個々のプログラムを有効にすることができます。例えば、ユーザー ''alice'' に特定のプログラムへのアクセス権限を与えるには:

# visudo

{{hc|/etc/sudoers|
alice ALL = NOPASSWD: /path/to/program}}

また、全てのユーザーに個別のコマンドを許可することも可能です。通常ユーザーでサーバーから Samba 共有をマウントするには:

%users ALL=/sbin/mount.cifs,/sbin/umount.cifs

これによって users グループのメンバーである全てのユーザーが全てのマシン (ALL) から {{ic|/sbin/mount.cifs}} や {{ic|/sbin/umount.cifs}} コマンドを実行できるようになります。

{{Tip|{{ic|visudo}} で {{ic|vi}} の代わりに {{ic|nano}} を使うには:

{{hc|/etc/sudoers|
2=Defaults editor=/usr/bin/rnano
}}
{{ic|1=# EDITOR=nano visudo}} のエクスポートは何にでも {{ic|EDITOR}} として使うことができるためにセキュリティリスクとされています。
}}

==== sudo を使ってファイルを編集する ====
root で {{ic|vim}} などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:

export SUDO_EDITOR=rvim

ファイルの編集には {{ic|sudoedit filename}} または {{ic|sudo -e filename}} を使って下さい。自動的に {{ic|rvim}} によって {{ic|filename}} が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。

=== root ログインの制限 ===
[[sudo]] を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。[[sudo]] を使える状態のまま root を無効化したい場合、{{ic|passwd -l root}} を使用します。

==== 特定のユーザーだけに許可を与える ====
[[Wikipedia:Pluggable authentication module|PAM]] の {{ic|pam_wheel.so}} は {{ic|wheel}} グループに入っているユーザーだけに {{ic|su}} を使用したログインを許可します。{{ic|/etc/pam.d/su}} と {{ic|/etc/pam.d/su-l}} の両方を編集して次の行をアンコメントしてください:
{{bc|<nowiki>
# Uncomment the following line to require a user to be in the "wheel" group.
auth required pam_wheel.so use_uid
</nowiki>}}
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。

==== ssh ログインを拒否する ====
ローカルユーザーの root ログインを拒否したくない場合でも、[[SSH#root ログインを拒否する|SSH による root ログインを拒否]]するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。

==== access.conf で許容されるログインの組み合わせを指定する ====

誰かが [[PAM]] でログインしようとすると、 {{ic|/etc/security/access.conf}} がそのログインプロパティに一致する最初の組み合わせをチェックします。そして、その組み合わせのルールに基づいて、試行が失敗するか成功するかが決まります。

+:root:LOCAL
-:root:ALL

特定のグループやユーザーに対してルールを設定することができます。この例では、ユーザー archie は、wheel および adm グループに属するすべてのユーザーと同様に、ローカルでのログインを許可されています。それ以外のログインは拒否されます。

+:archie:LOCAL
+:(wheel):LOCAL
+:(adm):LOCAL
-:ALL:ALL

詳しくは {{man|5|access.conf}} で確認してください。

==強制アクセス制御==

[[Wikipedia:ja:強制アクセス制御|強制アクセス制御]] (Mandatory Access Control, MAC) は Arch やほとんどの Linux ディストリビューションで使われている[[Wikipedia:ja:任意アクセス制御|任意アクセス制御]] (Discretionary Access Control, DAC) とは大きく異なるタイプのセキュリティポリシーです。原則的に MAC ではシステムに影響を与えるプログラムの行動は全てセキュリティルールセットによってチェックを受けます。このルールセットは、DAC とは対照的に、ユーザーが変更することは不可能です。実装方法は色々と異なるタイプが存在しますが、強制アクセス制御を使うことで実質的にコンピュータのセキュリティを著しく向上させることになります。

===パス名 MAC===
パス名ベースのアクセス制御は指定されたファイルのパスに基づいてパーミッションを与えるというシンプルな形式のアクセス制御です。この形式のアクセス制御の欠点としてはファイルが移動されてもパーミッションはファイルと一緒に付いていかないということが挙げられます。プラス面となるのは、パス名ベースの MAC はラベルベースの MAC と異なり、幅広いファイルシステムに実装できることです。

*[[AppArmor]] は [[Wikipedia:ja:カノニカル|Canonical]] によって開発されている MAC 実装で SELinux に比べて"簡単"になっています。
*[[TOMOYO Linux|Tomoyo]] はもうひとつのシンプルで、使いやすい強制アクセス制御を提供するシステムです。利用と実装の両面でシンプルになるように設計されており、依存するライブラリがとても少なくなっています。

===ラベル MAC===
ラベルベースのアクセス制御ではファイルの拡張属性を使ってセキュリティパーミッションを管理します。このシステムはセキュリティの機能においてパス名ベースの MAC よりも間違いなく柔軟性が高い一方、拡張属性をサポートしているファイルシステムでしか動作しません。

*[[SELinux]] は、Linux セキュリティを向上させる [[Wikipedia:ja:アメリカ国家安全保障局|NSA]] プロジェクトに基づいており、システムユーザーやロールとは完全に独立して MAC を実装しています。成長してオリジナルの設定が変わっていくシステムのコントロールを簡単に維持できる、極めて強固なマルチレベル MAC ポリシー実装を提供します。

=== アクセス制御リスト ===
[[アクセス制御リスト]] (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。

== カーネルの堅牢化 ==

=== カーネルの自己防衛機能/脆弱性攻撃対策 ===

{{pkg|linux-hardened}} パッケージは、[https://github.com/anthraxx/linux-hardened 基本的なカーネル堅牢化パッチセット]と、{{pkg|linux}} パッケージよりもセキュリティに重点を置いたコンパイル時設定オプションを使用します。カスタムビルドでは、セキュリティ寄りのデフォルトとは異なる、セキュリティと性能の妥協点を選択することができます。

しかし、このカーネルを使うといくつかのパッケージが動かなくなることに注意する必要があります。例えば

* {{AUR|skypeforlinux-preview-bin}}
* {{AUR|skypeforlinux-stable-bin}}
* {{pkg|throttled}}

[[NVIDIA]] などのアウトオブツリードライバを使用している場合、その [[DKMS]] パッケージに切り替える必要があるかもしれません。

==== ユーザー空間 ASLR の比較 ====

{{pkg|linux-hardened}} パッケージは、アドレス空間配置ランダム化の改善された実装をユーザ空間のプロセスに対して提供します。{{pkg|paxtest}} コマンドを使うことで、提供されるエントロピーの推定値を得ることができます:

===== 64 ビットプロセス =====

{{hc|linux-hardened 5.4.21.a-1-hardened|
Anonymous mapping randomization test : 32 quality bits (guessed)
Heap randomization test (ET_EXEC) : 40 quality bits (guessed)
Heap randomization test (PIE) : 40 quality bits (guessed)
Main executable randomization (ET_EXEC) : 32 quality bits (guessed)
Main executable randomization (PIE) : 32 quality bits (guessed)
Shared library randomization test : 32 quality bits (guessed)
VDSO randomization test : 32 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)
Randomization under memory exhaustion @~0: 32 bits (guessed)
Randomization under memory exhaustion @0 : 32 bits (guessed)
}}

{{hc|linux 5.5.5-arch1-1|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 20 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 29 bits (guessed)
Randomization under memory exhaustion @0 : 29 bits (guessed)
}}

{{hc|linux-lts 4.19.101-1-lts|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 19 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 28 bits (guessed)
Randomization under memory exhaustion @0 : 28 bits (guessed)
}}

===== 32 ビットプロセス (x86_64 カーネル上) =====

{{hc|linux-hardened|
Anonymous mapping randomization test : 16 quality bits (guessed)
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)
Heap randomization test (PIE) : 27 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 18 quality bits (guessed)
Shared library randomization test : 16 quality bits (guessed)
VDSO randomization test : 16 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)
Randomization under memory exhaustion @~0: 18 bits (guessed)
Randomization under memory exhaustion @0 : 18 bits (guessed)
}}

{{hc|linux|
Anonymous mapping randomization test : 8 quality bits (guessed)
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)
Heap randomization test (PIE) : 13 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 8 quality bits (guessed)
Shared library randomization test : 8 quality bits (guessed)
VDSO randomization test : 8 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)
Randomization under memory exhaustion @~0: No randomization
Randomization under memory exhaustion @0 : No randomization
}}

=== proc ファイルシステム内のカーネルポインタへのアクセスを制限する ===

{{ic|kernel.kptr_restrict}} を 1 に設定すると、{{ic|CAP_SYSLOG}} を持たない通常ユーザから {{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが秘匿され、カーネルのエクスプロイトで動的にアドレス/シンボルを解決することが困難になります。これは、事前にコンパイルされた Arch Linux カーネルではあまり意味がありません。周到な攻撃者はカーネルパッケージをダウンロードして、そこから手動でシンボルを取得することができるからです。しかしながら、自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし、一部の {{Pkg|perf}} コマンドの機能が、root 以外のユーザによって使用されば場合に破壊されます (しかし、いずれにせよ多くの {{Pkg|perf}} コマンドは root アクセスを必要とします)。詳細は {{Bug|34323}} を参照してください。

{{ic|kernel.kptr_restrict}} を 2 に設定すると、{{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが権限に依らず隠されます。

{{hc|/etc/sysctl.d/51-kptr-restrict.conf|2=
kernel.kptr_restrict = 1
}}

{{Note|{{pkg|linux-hardened}} はデフォルトで {{ic|0}} ではなく {{ic|1=kptr_restrict=2}} を設定します。}}

=== BPF の堅牢化 ===

BPF は、実行時にカーネル内のバイトコードを動的にロードして実行するために使用されるシステムです。ネットワーク (XDP, tc など)、トレース (kprobes, uprobes, tracepoints など)、セキュリティ (seccomp など) など、多くの Linux カーネルサブシステムで使用されています。また、高度なネットワークセキュリティ、パフォーマンスプロファイリング、ダイナミックトレースにも有効です。

BPF はもともと [[Wikipedia:ja:Berkeley Packet Filter|Berkeley Packet Filter]] の頭文字をとったもので、オリジナルの古典的な BPF は BSD 用のパケットキャプチャツールに使われていたためです。これは最終的に拡張 BPF (eBPF) に発展し、その後まもなくただの BPF (頭字語ではありません) に改名されました。BPFはパケットフィルタリングツールの実装に使われることがありますが、 iptables や netfilter のようなパケットフィルタリングツールと混同しないでください。

BPF のコードは解釈されるか、[[Wikipedia:ja:実行時コンパイラ|Just-In-Time (JIT) コンパイラ]]を使ってコンパイルされるかのどちらかです。Arch のカーネルは {{ic|CONFIG_BPF_JIT_ALWAYS_ON}} でビルドされており、BPF インタープリタを無効にして全ての BPF を JIT コンパイラでコンパイルするよう強制しています。これにより、攻撃者が BPF を使って SPECTRE 型の脆弱性を悪用した特権昇格攻撃をすることが難しくなります。詳しくは、[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290af86629b25ffd1ed6232c4e9107da031705cb CONFIG_BPF_JIT_ALWAYS_ON を導入したカーネルパッチ]を参照してください。

カーネルは JIT コンパイルされた BPF に対して、パフォーマンスと多くの BPF プログラムをトレース・デバッグする能力を犠牲にして、ある種の JIT スプレー攻撃を軽減するための堅牢化機能を備えています。この機能は、{{ic|net.core.bpf_jit_harden}} を {{ic|1}} (非特権コードの堅牢化を有効化する) か {{ic|2}} (全てのコードの堅牢化を有効化する) に設定することで有効化できます。

詳しくは、[https://docs.kernel.org/admin-guide/sysctl/net.html カーネルドキュメント] の {{ic|net.core.bpf_*}} 設定を参照してください。

{{Tip|
* {{Pkg|linux-hardened}} では、デフォルトで {{ic|1=net.core.bpf_jit_harden=2}} が設定されており、{{ic|0}} ではありません。
* デフォルトでは、BPF プログラムは非特権ユーザでも実行可能です。この挙動を変更するには {{ic|1=kernel.unprivileged_bpf_disabled=1}} を設定してください [https://access.redhat.com/security/cve/cve-2021-33624]。
}}

=== ptrace スコープ ===

{{man|2|ptrace}} システムコールは、あるプロセス ("tracer") が他のプロセス ("tracee") の実行を監視、制御し、tracee のメモリとレジスタを検査、変更するための手段を提供します。通常、{{ic|ptrace}} は ''gdb'' や ''strace''、''perf''、''reptyr'' などのデバッグツールによって使用されます。しかし、他のプロセスからデータを読んだり、他のプロセスの制御を奪ったりする手段を悪意のあるプロセスにも提供してしまいます。

Arch では、{{ic|kernel.yama.ptrace_scope}} [[カーネルパラメータ]]を提供する [https://docs.kernel.org/admin-guide/LSM/Yama.html Yama LSM] がデフォルトで有効化されています。このパラメータはデフォルトで {{ic|1}} (制限) に設定されており、{{ic|CAP_SYS_PTRACE}} [[ケイパビリティ]]も特権も持たない tracer が制限されたスコープ外で {{ic|ptrace}} コールを実行できないようにしています。これは、古典的なパーミッションと比べてセキュリティ上大きな改善です。このモジュールが無いと、同じユーザとして実行されているプロセスを隔てるものがなくなってしまいます ({{man|7|pid_namespaces}} などの他のセキュリティレイヤーがない場合)。

{{Note|デフォルトでは、[[sudo]] を使うなどして、{{ic|ptrace}} を必要とするツールを特権プロセスとして実行することができます。}}

デバッグツールを使う必要がない場合は、システムを堅牢化するために {{ic|kernel.yama.ptrace_scope}} を {{ic|2}} (管理者限定) や {{ic|3}} ({{ic|ptrace}} を禁止) に設定することを検討してください。

=== hidepid ===

{{Warning|
* これは、サンドボックスと [[Xorg]] 内で実行するアプリケーションなど、特定のアプリケーションで問題を発生させる場合があります (回避策を見てください)。
* {{Pkg|systemd}} > 237.64-1 を使用している場合、これは [[D-Bus]]、[[Polkit]]、[[PulseAudio]]、そして [[bluetooth]] で問題を発生させます。
}}

カーネルには、{{ic|proc}} ファイルシステムを {{ic|1=hidepid=}} オプションと {{ic|1=gid=}} オプションを使ってマウントすることで、他のユーザのプロセス (通常、{{ic|/proc}} でアクセス可能) を非特権ユーザから秘匿する機能があります。これらのマウントオプションは https://docs.kernel.org/filesystems/proc.html でドキュメント化されています。

これにより、侵入者が動作中のプロセスの情報 (特権で動作しているデーモンがあるか、他のユーザが機密情報を扱うプログラムを実行しているか、他のユーザがプログラムを実行しているか) を得る作業を複雑化し、ユーザが特定のプログラムを実行しているかどうかを知るのを不可能にし (ただし、そのプログラムがそれ自体の挙動で存在を他者に知られることがないとする)、さらに、貧弱に書かれたプログラムが機密情報をプログラム引数を介して渡したとしてもローカルの盗聴者から守られます。

{{ic|proc}} [[ユーザーとグループ#システムグループ#グループ]] ({{Pkg|filesystem}} パッケージによって提供されています) は、他のユーザのプロセス情報を得ることのできるユーザのホワイトリストとして機能します。ユーザやサービスが自身以外の {{ic|/proc/<pid>}} ディレクトリにアクセスする必要がある場合、そのユーザまたはサービスを[[ユーザーとグループ#グループ管理|proc グループに追加してください]]。

例えば、プロセスの情報を {{ic|proc}} グループに属さない他のユーザから隠すには:

{{hc|/etc/fstab|2=
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
}}

ユーザのセッションを正しく動作させるために、''systemd-logind'' を例外として追加する必要があります:

{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=
[Service]
SupplementaryGroups=proc
}}

=== モジュールのロードを制限する ===

デフォルトの Arch カーネルは {{ic|CONFIG_MODULE_SIG_ALL}} が有効で、{{Pkg|linux}} パッケージの一部としてビルドされた全てのカーネルモジュールに署名します。これにより、カーネルは有効なキーで署名されたモジュールだけをロードするように制限できます。実際、これはローカルでコンパイルされた、もしくは {{Pkg|virtualbox-host-modules-arch}} などのパッケージによって提供された、ツリー外のモジュールは全てロードできないことを意味します。

カーネルモジュールの読み込みは {{ic|1=module.sig_enforce=1}} [[カーネルパラメータ]]を設定することで制限することができます。詳細は[https://docs.kernel.org/admin-guide/module-signing.html カーネルドキュメント]で見られます。

=== kexec を無効にする ===

Kexec は、現在実行中のカーネルを置き換えることを可能にします。

{{hc|/etc/sysctl.d/51-kexec-restrict.conf|2=
kernel.kexec_load_disabled = 1
}}

{{Tip|kexec は {{pkg|linux-hardened}} でデフォルトで無効になっています。}}

=== カーネルロックダウンモード ===

Linux 5.4 から、オプションの[https://mjg59.dreamwidth.org/55105.html ロックダウン機能]がカーネルに[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d 追加されました]。これは、UID 0 (root) とカーネルの間の境界を強化することを目的としています。この機能を有効にすると、ハードウェアやカーネルへの低レベルなアクセスに依存している一部のアプリケーションは動作しなくなる可能性があります。

ロックダウンを使用するには、LSM が初期化され、ロックダウンモードが設定されている必要があります。

[[カーネル#公式サポートカーネル|公式にサポートされているカーネル]]は全て LSM を初期化しますが、ロックダウンモードを強制しません。

{{Tip|有効化されている LSM は {{ic|cat /sys/kernel/security/lsm}} を実行することで確認することができます。}}

ロックダウンには2つの動作モードがあります:

* {{ic|integrity}}: ユーザーランドが実行中のカーネルを変更できるカーネル機能 (kexec、bpf) は無効化されます。
* {{ic|confidentiality}}: ユーザーランドがカーネルから機密情報を抽出するためのカーネルの機能も無効化されます。

特定の脅威モデルで指示がない限り、{{ic|integrity}} を使用することが推奨されます。

実行時にカーネルのロックダウンを有効にするには、以下を実行してください:

# echo ''mode'' > /sys/kernel/security/lockdown

起動時にカーネルのロックダウンを有効にするには、{{ic|1=lockdown=''mode''}} [[カーネルパラメータ]]を使用してください:

{{Note|
* カーネルロックダウンを実行時に無効化することはできません。
* カーネルロックダウンは、[[ハイバネート]]を無効化します。
}}

{{man|7|kernel_lockdown}} も参照してください。

=== Linux Kernel Runtime Guard (LKRG) ===

[https://www.openwall.com/lkrg/ LKRG] ({{AUR|lkrg-dkms}}) は、カーネルの整合性チェックとエクスプロイト行為の検出を行うカーネルモジュールです。

== アプリケーションのサンドボックス化 ==

こちらも参照 [[Wikipedia:ja:サンドボックス (セキュリティ)]]

{{Note|ユーザー名前空間の設定項目 {{ic|CONFIG_USER_NS}} は、現在 {{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}}、および {{Pkg|linux-hardened}} で有効になっています。これが無効だと、一部のアプリケーションで特定のサンドボックス機能が利用できなくなる可能性があります。}}

{{Warning|非特権ユーザー名前空間の使用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) は、{{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}} でデフォルトで有効になっています。これにより、ローカル特権昇格の攻撃対象が大幅に拡大します([https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction AppArmorのWiki] および {{Bug|36969}} を参照。}}

これを軽減するためには、次のいずれかを行ってください:

* 安全なデフォルトを持つ {{Pkg|linux-hardened}} カーネルを使用する、または
* {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] を {{ic|0}} に設定する。

これにより、[[Zoom Meetings|Zoom]] や {{pkg|nsjail}} などのアプリケーションが動作しなくなる場合があることに注意してください。また、システムに {{pkg|bubblewrap}} がインストールされている場合は、{{pkg|bubblewrap-suid}} に置き換える必要があります。詳細は [[Bubblewrap#インストール]] を参照してください。

=== Firejail ===

[[Firejail]] は、アプリケーションやサーバーをサンドボックス化するための使いやすいツールです。元々はブラウザやインターネット向けアプリケーションのために作成されましたが、現在では多くのアプリケーションに対応しています。さまざまな機能を備えたサンドボックス環境を構築するために、suid バイナリとしてインストールされ、ブラックリストとホワイトリストに基づいてターゲットアプリケーションのサンドボックス化された実行環境を構築します。

=== bubblewrap ===

[[bubblewrap]] は、[[Flatpak]] などの非特権コンテナツール向けに開発されたサンドボックスアプリケーションで、Firejail よりもリソース消費と複雑さが大幅に小さいです。ファイルパスのホワイトリスト機能は欠けていますが、bubblewrap はバインドマウントのほか、ユーザー/IPC/PID/ ネットワーク /cgroup 名前空間の作成をサポートしており、シンプルなものから複雑なサンドボックスまで対応可能です。

[[Bubblejail]] サンドボックスは [[bubblewrap]] を基にしており、リソース指向の権限モデルと、権限を調整するためのグラフィカルインターフェースを提供します。

=== chroot ===

手動で [[chroot]] してサンドボックス化されたプロセス環境を作成できます。しかし、これは他のサンドボックス技術に比べて非常に制限されています。そのサンドボックス化の範囲はファイルパスの隔離に限られています。

=== Linux Containers ===

[[Linux Containers]] は、他のオプション([[#完全な仮想化オプション|完全な仮想化オプション]] を除く) よりも多くの隔離が必要な場合に適した選択肢です。LXC は、既存のカーネルの上で擬似 chroot 内で実行され、独自の仮想ハードウェアを持っています。

=== 完全な仮想化オプション ===

[[VirtualBox]]、[[KVM]]、[[Xen]]、または [https://www.qubes-os.org/ Qubes OS](Xen ベース)などの完全仮想化オプションを使用することで、リスクの高いアプリケーションを実行したり、危険なウェブサイトを閲覧したりする場合に、隔離とセキュリティを強化することができます。

==ネットワークとファイアウォール==

===ファイアウォール===

標準の Arch カーネルは [[Wikipedia:Netfilter|Netfilter]] の [[iptables]] および [[nftables]] を使用できますが、これらのサービスはデフォルトで [[有効化]] されていません。システム上で実行されているサービスを保護するために、何らかの形のファイアウォールを設定することを強く推奨します。多くのリソース(ArchWiki など)では、どのサービスを保護するべきかが明示的に記載されていないため、ファイアウォールを有効にすることは良い予防措置となります。

* 一般的な情報については [[iptables]] および [[nftables]] を参照してください。
* iptables ファイアウォールの設定方法については [[シンプルなステートフルファイアウォール]] を参照してください。
* netfilter の設定方法については [[ファイアウォール]] を参照してください。
* Bluetack などの IP アドレスリストをブロックするには [[Ipset]] を参照してください。
* {{Pkg|opensnitch}} は、アプリケーション、ポート、ホストなどによる設定可能なルールをサポートする、構成可能なインバウンドおよびアウトバウンドファイアウォールです。

==== ポートを開く ====

一部のサービスは、開かれたネットワークポートでインバウンドトラフィックを待ち受けます。これらのサービスは、必要最低限のアドレスとインターフェースにのみバインドすることが重要です。リモート攻撃者が [https://samy.pl/slipstream/ ネットワークプロトコルの欠陥を悪用して公開されたサービスにアクセスする] 可能性があります。これは、[https://nvd.nist.gov/vuln/detail/CVE-2019-13450 localhost にバインドされたプロセス] にも発生することがあります。

一般的に、サービスがローカルシステムのみでアクセス可能であれば、非ループバックアドレス(例えば {{ic|0.0.0.0/0}})ではなく、Unix ドメインソケット({{man|7|unix}})や {{ic|localhost}} のようなループバックアドレスにバインドするべきです。

サービスがネットワーク越しに他のシステムからアクセス可能である必要がある場合、厳格な [[ファイアウォール]] ルールでアクセスを制御し、可能な限り認証、認可、暗号化を構成することが重要です。

現在のすべてのオープンポートをリストするには、{{ic|ss -l}} を使用できます。すべてのリスニング中のプロセスとその数値的な TCP および UDP ポート番号を表示するには:

# ss -lpntu

その他のオプションについては、{{man|8|ss}}を参照してください。

===カーネルパラメータ===
ネットワークに影響を与えるカーネルパラメータは [[sysctl]] を使って設定できます。設定方法は [[sysctl#TCP/IP スタックの防御]] を見て下さい。

===SSH===
[[SSH 鍵#パスワードログインの無効化|SSH 鍵を必要]]としない [[Secure Shell]] を使うのは避けましょう。これは[[Wikipedia:ja:総当たり攻撃|総当たり攻撃]]を防ぎます。また、[[Fail2ban]] や [[Sshguard]] はログを監視して [[iptables|iptables ルール]]を書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。

二段階認証によって認証を強化することができます。[[Google Authenticator]] はワンタイムパスコード (OTP) を使用する二段階認証方式を提供します。

[[Secure Shell#root ログインを拒否する|root ログインを拒否する]]のは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。

===DNS===

[[DNSSEC]] や [[DNSCrypt]] を見て下さい。

=== プロキシ ===

プロキシはアプリケーションとネットワークの間に挟まる追加レイヤーとして使われ、信頼できないソースからのデータをサニタイズします。少ない権限でプロキシを動作させることで、エンドユーザー権限で複雑なアプリケーションを実行するよりも攻撃対象を小さくすることができます。

例えば {{Pkg|glibc}} の中に実装されている DNS リゾルバを考えてみてください。(root で実行することもある) アプリケーションにリンクされている DNS リゾルバにバグが存在した場合、リモートコード実行につながる危険があります。[[dnsmasq]] などの DNS キャッシュサーバーをインストールしてプロキシとして使うことで問題を防ぐことが可能です [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]。

=== SSL 証明書の管理 ===

サーバーサイドの SSL 証明書の管理については [[OpenSSL]] や [[Network Security Services]] (NSS) を参照してください。また、関連する [[Let’s Encrypt]] プロジェクトも見てください。

デフォルトのインターネット SSL 証明書のトラストチェーンは {{Pkg|ca-certificates}} パッケージによって提供されています。Arch はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: {{AUR|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) に依存しています。

デフォルトの証明書を変えたいと思うことがあるかもしれません。例えば、[http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ ニュース] を読んで証明書を信頼しないようにしたい場合 (ソースのプロバイダーによって無効になるのを待てない場合)、Arch のインフラを使うことで簡単に設定できます:
# {{ic|.crt}} 形式の証明書を入手してください (例: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; 既存のルート認証局の場合、システム内にあるはずです)。
# {{ic|/etc/ca-certificates/trust-source/blacklist/}} にコピーしてください。
# root で ''update-ca-trust'' を実行してください。

お好きなブラウザを開いて'''信頼できない'''サイトとして表示されれば、ブラックリストが上手く機能しています。

== 物理セキュリティ ==

{{Note|リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。}}

十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで''実用的で''高いレベルのセキュリティを得ることができます。

攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [http://www.breaknenter.org/projects/inception/]。これを防ぐためにできることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識がなく実行されることはほとんどありません。

[[#ディスク暗号化|ディスク暗号化]]はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。

===BIOS をロックダウンする===

BIOS にパスワードを追加することによってリムーバブルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。

=== ブートローダー ===

[[Arch ブートプロセス#ブートローダー|ブートローダー]] を保護することは非常に重要です。保護されていないブートローダは、例えば {{ic|1=init=/bin/sh}} を設定することでログインの制限を回避することができます。[[カーネルパラメータ]] でシェルに直接ブートするようにします。

==== Syslinux ====

Syslinux は[[Syslinux#セキュリティ|ブートローダーのパスワード保護]]をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。

==== GRUB ====

[[GRUB]] はブートローダのパスワードもサポートしています。詳しくは [[GRUB/ヒントとテクニック#GRUB メニューのパスワード保護|GRUB メニューのパスワード保護]] を参照してください。[[GRUB/ヒントとテクニック# GRUB メニューのパスワード保護|暗号化 /boot]] もサポートしていますが、これはブートローダコードの一部だけを暗号化しないままにしています。GRUB の設定、[[カーネル]]、[[initramfs]] は暗号化されています。

==== systemd-boot ====

[[systemd-boot]] は [[#セキュアブート]] が有効な場合、カーネルパラメータの編集を無効にします。代わりの方法として、[[systemd-boot#パスワードで保護されたカーネルパラメータエディタ]] を参照して下さい、より伝統的なパスワードベースのオプションを使用できます。

=== セキュアブート ===

[[セキュアブート]] は [[UEFI]] の機能で、コンピュータが起動するファイルの認証を可能にするものです。これは、起動パーティション内のファイルを置き換えるような、いくつかの [https://ja.wikipedia.org/wiki/%E6%82%AA%E6%84%8F%E3%81%82%E3%82%8B%E3%83%A1%E3%82%A4%E3%83%89%E6%94%BB%E6%92%83 悪意あるメイド攻撃] を防止するのに役立つ。通常、コンピュータにはベンダー (OEM) によって登録されたキーが付属しています。しかし、これを取り外して、コンピュータを「セットアップモード」にし、ユーザーが自分のキーを登録・管理できるようにすることができます。

セキュアブートのページでは、[https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Implementing_Secure_Boot using your own keys] によってセキュアブートを設定する方法を案内しています。

=== トラステッドプラットフォームモジュール(TPM) ===

[[Trusted Platform Module|TPM]] は、暗号鍵が埋め込まれたハードウェア・マイクロプロセッサです。これは、最近のほとんどのコンピュータの基本的な信頼性の根源を形成し、ブートチェーンのエンドツーエンドの検証を可能にします。内部スマートカードとして使用したり、コンピュータ上で動作するファームウェアを証明したり、改ざん防止とブルートフォース耐性のあるストアにユーザーがシークレットに挿入することができます。

=== リムーバブルフラッシュドライブ上のブートパーティション ===

ブートパーティションをフラッシュドライブに置き、それがないとシステムが起動しないようにする、というのはよくあるアイデアです。このアイデアの支持者はしばしば [[セキュリティ#ディスク暗号化|ディスク暗号化]] を併用し、ブートパーティションに置かれた [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USBdetached encryption headers] を使っている人もいます。

この方法は [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USB encrypting /boot] と統合することも可能です。

=== 自動ログアウト ===
[[Bash]] または [[Zsh]] を使っている場合、{{ic|TMOUT}} によってタイムアウトによるシェルからの自動ログアウトを設定できます。

例えば、以下は仮想コンソールから自動でログアウトします (X11 のターミナルエミュレータからはログアウトしません):

{{hc|/etc/profile.d/shell-timeout.sh|<nowiki>
TMOUT="$(( 60*10 ))";
[ -z "$DISPLAY" ] && export TMOUT;
case $( /usr/bin/tty ) in
/dev/tty[0-9]*) export TMOUT;;
esac
</nowiki>}}

(X のコンソールも含めて) 全ての Bash/Zsh プロンプトでタイムアウトさせたい場合は、次を使って下さい:

$ export TMOUT="$(( 60*10 ))";

シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや {{ic|TMOUT}} をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。

=== 不正なUSBデバイスから保護する ===

[[Usbguard]] は、デバイスの属性に基づく基本的なホワイトリストおよびブラックリスト機能を実装することで、不正な USB デバイス (別名 [https://ja.wikipedia.org/wiki/BadUSB BadUSB], [https://github.com/samyk/poisontap PoisonTap] または [https://lanturtle.com/ LanTurtle]) からコンピューターを保護できるソフトウェアフレームワークです。

=== 揮発性データの収集 ===

電源が入っているコンピュータは、[https://fedvte.usalearning.gov/courses/CSI/course/videos/pdf/CSI_D01_S05_T01_STEP.pdf volatile data collection] に対して脆弱である可能性があります。コンピュータの電源を入れる必要がない時や、コンピュータの物理的な安全性が一時的に損なわれる場合(例:セキュリティチェックポイントを通過する時)には、コンピュータの電源を完全に切ることがベストプラクティスです。

== パッケージ ==

=== パッケージの認証 ===
パッケージの署名が適正に使われていないと [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview パッケージマネージャへの攻撃] が考えられ、さらに [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html 適切な署名システム] を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは [[Pacman-key]] を見て下さい。

=== アップグレード ===

定期的に [[システムメンテナンス#システムのアップグレード|システムのアップグレード]] を行うことが重要です。

=== 脆弱性アラートの確認 ===

National Vulnerability Database が提供する Common Vulnerabilities and Exposure (CVE) Security Alert の更新を購読し、[https://nvd.nist.gov/download.cfm NVD Download webpage] で見つけてください。[https://security.archlinux.org/ Arch Linux Security Tracker] は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットを表形式でまとめた、特に有用なリソースです。ツール {{Pkg|arch-audit}} は実行中のシステムに影響を与える脆弱性をチェックするために使われます。グラフィカルなシステムトレイである {{Pkg|arch-audit-gtk}} も使うことができます。[https://wiki.archlinux.org/title/Arch_Security_Team Arch Security Team]も参照してください。

特にメインレポジトリや AUR 以外の手段でソフトウェアをインストールしている場合は、あなたが使っているソフトウェアのリリース通知を購読することも検討すべきです。いくつかのソフトウェアには、セキュリティに関する通知を受け取るために購読できるメーリングリストがあります。ソースコードホスティングサイトはしばしば新しいリリースの RSS フィードを提供しています。

=== パッケージの再ビルド ===

攻撃対象領域を減らす手段として、パッケージをリビルドし、不要な関数や機能を削除することができます。例えば、{{Pkg|bzip2}} は [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189] を回避するために {{ic|bzip2recover}} を使わずにリビルドすることが可能です。カスタムハードニングフラグは、手動またはラッパーを介して適用することもできます。

{| class="wikitable"
! フラグ !! 目的
|-
| -D_FORTIFY_SOURCE=2 || ランタイムバッファオーバーフローの検出
|-
| -D_GLIBCXX_ASSERTIONS || C++ の文字列とコンテナのランタイム境界チェック
|-
| -fasynchronous-unwind-tables || バックトレースの信頼性向上
|-
| -fexceptions || テーブルベースのスレッドキャンセルを有効にする
|-
| -fpie -Wl,-pie || 実行可能ファイルに対する完全な ASLR
|-
| -fpic -shared || 共有ライブラリのテキスト再配置を行わない
|-
| -fplugin=annobin || ハードニング品質管理用データの作成
|-
| -fstack-clash-protection || スタックオーバーフロー検出の信頼性向上
|-
| -fstack-protector or -fstack-protector-all || スタックスマッシュプロテクター
|-
| -fstack-protector-strong || 同様に
|-
| -g || デバッグ情報を生成する
|-
| -grecord-gcc-switches || デバッグ情報にコンパイラのフラグを格納する
|-
| -mcet -fcf-protection || 制御フローの完全性保護
|-
| -O2 || 推奨される最適化
|-
| -pipe || 一時ファイルを回避し、ビルドを高速化します。
|-
| -Wall || 推奨されるコンパイラの警告
|-
| -Werror=format-security || 安全でない可能性のあるフォーマット文字列の引数を拒否する
|-
| -Werror=implicit-function-declaration || 関数プロトタイプの欠落を却下する
|-
| -Wl,-z,defs || アンダーリンクの検出と拒否
|-
| -Wl,-z,now || 遅延バインディングを無効にする
|-
| -Wl,-z,relro || 移設後の読み出し専用セグメント
|}

* [https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/ Flags and info ソース]

== 参照 ==

* [https://security.archlinux.org/ Arch Linux セキュリティトラッカー]
* ArchWiki のセキュリティアプリケーションのリスト: [[アプリケーション一覧/セキュリティ]]
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux ワークステーションのセキュリティチェックリスト]
* [https://www.privacytools.io/ privacytools.io Privacy Resources]
* [https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/index.html Red Hat Enterprise Linux 7 セキュリティガイド]
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Debian 安全化マニュアル (PDF)]
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]

文字コード

2025-04-24T01:39:06Z

Oech3: CP932,bsdunzip/* 不正なアーカイブエンコーディング */

[[Category:ローカリゼーション]]
[[en:Character encoding]]
{{Related articles start}}
{{Related|ロケール}}
{{Related|インプットメソッド}}
{{Related articles end}}

[[Wikipedia:ja:文字コード|文字コード]]は、バイトを読み取り可能な文字に解釈するプロセスです。[[Wikipedia:UTF-8|UTF-8]] は 2009 年以降主要なエンコーディングとなっており、事実上の標準として推進されています[https://utf8everywhere.org/]。

== UTF-8 ==

=== ターミナル ===

ほとんどのターミナルはデフォルトで UTF-8 を使用しています。しかし、一部のターミナル (例: {{Pkg|gnome-terminal}}, {{Pkg|rxvt-unicode}}) は UTF-8 ロケールから起動する必要があります。そのためには、ロケールの文字コード部分を {{ic|.UTF-8}} に設定し、セッションを再読み込みしてください。設定方法については、[[ロケール#ロケールの設定]] を参照してください。

* [[xterm]] - 引数 {{ic|-u8}} を指定して実行するか、リソース設定で {{ic|xterm*utf8: 2}} を指定してください。

=== ユニコード文字の挿入 ===

[[アプリケーション一覧/ユーティリティ#テキスト入力]]を参照してください。
* [[LibreOffice]] には、''挿入 > 特殊文字'' に組み込みのキャラクターマップがあり、文字ブロック、16 進、10 進エンコーディングが表示されます。
* [[Xorg/キーボード設定#コンポーズキーの設定|Compose キー]]: XCompose を設定して特殊文字を挿入することができます。
* [[Xorg/キーボード設定#AltGr の設定|AltGr]]: を設定して、追加のキーボードレベルにアクセスし、[[Wikipedia:Zwnj|ZWNJ]] や [[Wikipedia:Right-to-left mark|RTL マーク]] などの Unicode 制御文字を含む追加の文字を入力できます。
* [[Vim]]: 挿入モードで {{ic|Ctrl+v}} {{ic|u''XXXX''}} を使用します。ここで、{{ic|''XXXX''}} は16進数の [[Wikipedia:Code point#In Unicode|コードポイント]] です。

== URL エンコード ==

URI は US-ASCII 文字のみを受け入れ、非 ASCII 文字をエンコードするために[[Wikipedia:percent-encoding|パーセントエンコーディング]]を使用します。これにより、非常に長く、人間が読みづらい URI になることがあります。

Firefox では、{{ic|browser.urlbar.decodeURLsOnCopy}} フラグを {{ic|about:config}} で有効にするか、URL の先頭にスペースを挿入してからそのスペースを含めて選択し、コピーすることでデコードされた URL をコピーすることができます。ただし、この方法は Chromium では機能せず、同等のフラグもありません。代わりに、URL の末尾から {{ic|https://}} の部分を超えたところまで選択してコピーすることもできます。

コマンドラインで使用する場合、{{pkg|python-urllib3}} を使用して標準入力からエンコードされた URL を翻訳できます。

$ python3 -c "import sys; from urllib.parse import unquote; print(unquote(sys.stdin.read().strip()))"

== トラブルシューティング ==
エンコーディングの問題は、通常、異なるエンコーディングで通信している二つのプログラムが原因で発生します。通常、片方が UTF-8 を使用していないため、[[Wikipedia:mojibake|文字化け]] が発生します。

{{Warning|ロケールのコードセットを {{ic|.UTF-8}} に設定することが強く推奨されます。そうしないと、UTF-8 から非 Unicode エンコーディングへの変換で情報が失われる可能性があります。}}

=== 不正なアーカイブエンコーディング ===

古いバージョンの Windows (XP、Vista、7) では、エクスプローラーが特定のロケールで ZIP アーカイブを作成する際に異なるエンコーディングを使用します。正しく展開するには、ターゲットエンコーディングを指定して ''unzip -O'' か、 {{Pkg|libarchive}}の''bsdunzip -O''を使用します。例として、CP936 は古いバージョンの中国語のWindows で一般的なエンコーディングです。

$ unzip -O CP936 ''file.zip''

必要な文字セットが不明な場合は、{{ic|-l}} フラグを追加して抽出せずにドライランを行います:

$ unzip -lO SJIS ''file.zip''

日本語版の Windows はかつてZIP アーカイブを CP932 (Shift-JISではありません) でエンコードしていました:

$ unzip -O CP932 ''file.zip''

中国語版の Windows は ZIP アーカイブを ''gbk'' でエンコードします:

$ unzip -O gbk ''file''.zip

あるいは、ターゲットエンコーディングを自動検出するために {{AUR|unzip-natspec}} を使用します。

=== 不正なファイル名エンコーディング ===

{{Pkg|convmv}} を使用してエンコーディング変換を行います:

$ convmv -f ''SOURCE_ENCODING'' -t UTF-8 --notest --nosmart file

{{ic|--notest}} は移動せずにドライランを行うために使用されます。元のエンコーディングを {{ic|-f}} (例: 中国語の場合は {{ic|GBK}}) を使って特定した後、それを削除して移動操作を行います。なお、{{ic|--smart}} は既に UTF8 エンコードされている場合、変換をスキップします。サポートされているエンコーディングを確認するには {{ic|convmv --list}} を使用します。

=== 不正なファイルエンコーディング ===

{{ic|iconv}} コマンドを使用して形式を変換します。例えば:

$ iconv -f ''SOURCE_ENCODING'' -t UTF-8 -o new-file origin-file

{{ic|-f}} は元のエンコーディングを指定し、{{ic|-t}} は出力エンコーディングを指定します。サポートされているエンコーディングをすべて照会するには {{ic|iconv -l}} を、出力ファイルを指定するには {{ic|-o}} を使用します。

==== Vim ====

ロケールが UTF-8 の場合、他の文字エンコードされたファイルを開くと文字化けすることがあります。''vimrc'' に以下のような行を追加してフォールバックを設定できます:

set fileencodings=utf8,cp936,gb18030,big5

または、{{ic|1=:set fileencoding=ansi}} を明示的に設定することもできます。Vim は ''iconv'' を介して自動的に変換を行います。{{ic|:h charset-conversion}} を参照してください。

=== 不正な MP3 ID3 タグエンコーディング ===
MP3 ファイルのタグを変更するには、{{Pkg|python-mutagen}} または {{Pkg|mp3unicode}} を使用して変換します:

$ mid3iconv -e ''SOURCE_ENCODING'' XXX.mp3

ファイルの変更を望まない場合は、メディアプレーヤーの動作を調整できます。[[GStreamer]] をバックエンドとして使用するプレーヤー（例: [[Rhythmbox]] や totem）では、[[環境変数]]を設定します:

export GST_ID3_TAG_ENCODING=GBK:UTF-8:GB18030
export GST_ID3V2_TAG_ENCODING=GBK:UTF-8:GB18030

Beep メディアプレーヤーでは、{{ic|preferences > plugins > media > title >}} で MPEG Audio プラグインを選択し、{{ic|Disable ID3v2 and Convert non-UTF8 ID3 tags to UTF8}} にチェックを入れ、適切なエンコーディングを選択します。

Quod Libet プレーヤーはタグ編集と ID3v2 エンコーディングの設定をサポートしています。{{ic|~/.quodlibet/config}} に設定できます:

{{hc|~/.quodlibet/config|2=
...
id3encoding = gbk
...
}}

{{Note|Quod Libet はデフォルトで utf8 エンコーディングをサポートしています。}}

=== 不正なマウントエンコーディング ===

一般的に、マウントされた文字セットはロケールとは異なりますが、[[fstab]] を修正することで設定できます。ロケールが utf8 の場合は、以下のように行を修正します:

{{hc|/etc/fstab|2=
...
/dev/sdxx /media/win ntfs defaults,iocharset=utf8 0 0
}}

ロケールが GBK の場合は、以下のようにすべきです:

{{hc|/etc/fstab|2=
...
/dev/sdxx /media/win ntfs defaults,iocharset=cp936 0 0
...
}}

=== 不正な Samba エンコーディング ===

Arch を [[Samba]] サーバーとして使用する場合、{{ic|/etc/samba/smb.conf}} に次の行を追加することで、Windows クライアントの文字化けの問題を解決できます:

{{hc|/etc/samba/smb.conf|2=
...
unix charset=gb2312
...
}}

=== 不正な FTP エンコーディング ===

UTF8 ロケールを使用している場合、非 Unicode エンコードされたサーバーからダウンロードしたファイル名が文字化けすることがあります。lftp では、{{ic|.lftp/rc}} に次の設定を行います:

{{hc|.lftp/rc|
...
set ftp:charset "gbk"
set file:charset "UTF-8"
...
}}

gftp では、{{ic|.gftp/gftprc}} に次の設定を行うことができます:

{{hc|.gftp/gftprc|2=
...
remote_charsets=gb2312
...
}}

ただし、ダウンロードしたファイル名が依然として文字化けしている場合は、パッチを適用してコンパイルする必要があります。パッチのアドレスは: https://www.teatime.com.tw/%7Etommy/linux/gftp_remote_charsets.patch です。

{{TranslationStatus|Character encoding|2024-08-17|814093}}

Advanced Linux Sound Architecture

2025-04-23T17:19:30Z

Oech3: hintを追加/* ハードウェアを直接割り当てる */

[[Category:サウンド]]
[[cs:Advanced Linux Sound Architecture]]
[[de:Alsa]]
[[en:Advanced Linux Sound Architecture]]
[[es:Advanced Linux Sound Architecture]]
[[fa:ALSA]]
[[fr:Alsa]]
[[he:Advanced Linux Sound Architecture]]
[[it:Advanced Linux Sound Architecture]]
[[nl:Advanced Linux Sound Architecture]]
[[pt:Advanced Linux Sound Architecture]]
[[ru:Advanced Linux Sound Architecture]]
[[sk:Advanced Linux Sound Architecture]]
[[th:Advanced Linux Sound Architecture]]
[[tr:Gelişmiş_ses_mimarisi_(ALSA)]]
[[zh-hans:Advanced Linux Sound Architecture]]
{{Related articles start}}
{{Related|Advanced Linux Sound Architecture/設定例}}
{{Related|Advanced Linux Sound Architecture/トラブルシューティング}}
{{Related|サウンドシステム}}
{{Related|PC スピーカーのビープ音の無効化}}
{{Related|PulseAudio}}
{{Related|Open Sound System}}
{{Related articles end}}
[[Wikipedia:ja:Advanced Linux Sound Architecture|Advanced Linux Sound Architecture]] ('''ALSA''') は、サウンドカードのデバイスドライバを提供する Open Sound System (OSSv3) を置き換えるために開発された Linux カーネルコンポーネントです。デバイスドライバの他に、'''ALSA''' は、カーネルドライバと直接やりとりせずに高レベルの API を使ってドライバ機能を使いたいという開発者のために、ユーザ空間のライブラリも提供しています。

==インストール==

ALSA はデフォルトの Arch カーネルにモジュールセットとして含まれているので、インストールは不要です。

起動時に自動で [[udev]] があなたのハードウェアを調べて、オーディオカード用の適切なカーネルモジュールをロードします。したがって、サウンドはすでに鳴らせるはずです。ただ、デフォルトでは全てのチャンネルはミュートにされています。[[#チャンネルのミュートを解除する|チャンネルのミュートを解除]]してください。

=== ユーザー権限 ===

通常、ローカルユーザーは音楽を再生したり、ミキサーレベルを変更する権限があります。

リモートユーザーが ALSA を使用できるようにするには、ユーザーを {{ic|audio}} グループに[[ユーザーとグループ#グループ管理|追加]]する必要があります。

{{Note|1={{ic|audio}} グループに含まれているユーザーは直接デバイスにアクセスできるので、アプリケーションから排他的にアウトプットしたり（ソフトウェアミキシングが破壊されます）、高速ユーザー切り替えや multiseat を破壊してしまうおそれがあります。よって、特に必要がないのならばユーザーを {{ic|audio}} グループに追加することは'''推奨されません'''[https://wiki.ubuntu.com/Audio/TheAudioGroup]。}}

===ALSA ユーティリティ===

{{Pkg|alsa-utils}} パッケージを[[インストール]]してください、サウンドデバイスをコンソールや端末から設定するための {{ic|alsamixer}} ユーザー空間ツールが含まれています。また、[[#高品質なリサンプリング|高品質なリサンプリング]]や[[#アップ・ダウンミキシング|アップ・ダウンミキシング]]などの高度な機能を使いたい場合は {{Pkg|alsa-plugins}} パッケージをインストールしてください。

===OSS との互換性===

{{Note|{{ic|/dev/dsp}} や {{ic|/dev/snd/seq}} が存在しないとアプリケーションがエラーを吐く場合は以下の設定が必要です。}}

ALSA には [[OSS]] のコールに介入して ALSA を使うようにさせる機能があります。このエミュレーションレイヤーは {{ic|/dev/dsp}} を開いて音声データを直接書き込むような古いアプリケーションで有用です。OSS やエミュレーションライブラリがないと、{{ic|/dev/dsp}} が見つからずにアプリケーションは音声を鳴らすことができません。

OSS アプリケーションに dmix (ソフトウェアミキシング) を扱わせたい場合は {{Pkg|alsa-oss}} パッケージをインストールして {{ic|snd-seq-oss}}, {{ic|snd-pcm-oss}}, {{ic|snd-mixer-oss}} [[カーネルモジュール]]をロードして OSS エミュレーションモジュールを有効にしてください。

=== PulseAudio との互換性 ===

{{AUR|apulse}} を使うことで [[PulseAudio]] にしか対応していないアプリケーションで ALSA を利用することができます。使用方法は {{ic|$ apulse ''yourapplication''}} とアプリケーションを起動するだけです。

===ALSA と systemd===
{{pkg|alsa-utils}} パッケージには、それぞれ起動時とシャットダウン時に動くように設定された {{ic|alsa-restore.service}} と {{ic|alsa-state.service}} が含まれています。

自動的にインストールされ有効化されるため、特に設定は必要ありません。{{ic|systemctl}} を使うことでステータスを確認できます。

{{Note|1=ALSA は設定を {{ic|/var/lib/alsa/asound.state}} に保存します。}}

=== ALSA ファームウェア ===

{{Pkg|alsa-firmware}} パッケージには特定のサウンドカードを使うのに必要なファームウェアが含まれています (例: Creative SB0400 Audigy2)。

==チャンネルのミュートを解除する==

現在のバージョンでは ALSA をインストールしたあと全てのチャンネルは'''デフォルトでミュートされています'''。手動でチャンネルをアンミュートする必要があります。

===amixer を使ってミュートを解除===

コマンドラインで {{ic|amixer}} を使うことでサウンドカードのマスターボリュームのミュートを解除できます:

$ amixer sset Master unmute

===alsamixer を使ってミュートを解除===

{{ic|alsamixer}} ncurses UI を使えば簡単にミュートを解除できます:

$ alsamixer

{{ic|alsamixer}} の、チャンネルの下の {{ic|MM}} ラベルはそのチャンネルがミュートになっていることを示しています。{{ic|00}} はミュートが解除されていることを示しています。

{{ic|←}} や {{ic|→}} キーを押して {{ic|Master}} や {{ic|PCM}} チャンネルに移動して {{ic|m}} キーを押してミュートを解除してください。{{ic|↑}} キーを押してボリュームを上げて値を {{ic|0}} dB ゲインにしてください。ゲインは左上の {{ic|項目:}} の隣に表示されます。

{{Note|ゲインを大きくしすぎると音にノイズが混じります。}}

=== 5.1/7.1 サウンドのミュートの解除 ===

5.1 または 7.1 サラウンドを鳴らしたいときは Front, Surround, Center, LFE (サブウーファー), Side などの他のチャンネルも同じようにミュートを解除してください（これらのチャンネル名は Intel HD Audio のものです、チャンネル名はハードウェアによって変わっているかもしれません）。

{{Note|ミュートを解除しただけではステレオ音源は自動でアップミキシングされません。[[#アップ・ダウンミキシング]] を見て下さい。}}

=== マイクの有効化 ===

マイクロフォンを有効にするには、Capture タブに {{ic|F4}} で切り替えてチャンネルを {{ic|Space}} で有効にしてください。マイクが使えない時は [[Advanced Linux Sound Architecture/トラブルシューティング#マイクロフォン]] を見て下さい。

=== テスト ===

次に、音が鳴るかテストしてみましょう:

$ speaker-test -c 2

{{ic|-c}} はスピーカーによって変えて下さい。例えば 7.1 では {{ic|-c 8}} を使います:

$ speaker-test -c 8

間違ったデバイスから音が出力される場合、{{ic|-D}} 引数を使って手動でデバイスを指定してみてください:

$ speaker-test -D default:PCH -c 8

{{ic|-D}} では PCM チャンネルの名前を値として指定できます。以下のコマンドで確認することができます:

{{hc|<nowiki>$ aplay -L | grep :CARD</nowiki>|2=
default:CARD=PCH # 'default:PCH' is the PCM channel name for -D
sysdefault:CARD=PCH
front:CARD=PCH,DEV=0
surround21:CARD=PCH,DEV=0
surround40:CARD=PCH,DEV=0
surround41:CARD=PCH,DEV=0
surround50:CARD=PCH,DEV=0
surround51:CARD=PCH,DEV=0
surround71:CARD=PCH,DEV=0
}}

音が出ない場合、[[#設定]]や [[Advanced Linux Sound Architecture/トラブルシューティング]]に進んで問題を解決してください。

===ノート===

* カードによってはアナログサウンドを聞くためにはデジタル出力をミュートする必要があります。Soundblaster Audigy LS では IEC958 チャンネルをミュートしてください。
* マシンによっては (Thinkpad T61 など)、Speaker チャンネルのミュートを解除する必要があります。
* マシンによっては (Dell E6400 など)、同じく {{ic|Front}} や {{ic|Headphone}} チャンネルのミュートを解除する必要があります。
* 再起動するとボリューム調整が元に戻ってしまう場合、root で alsamixer を実行してみて下さい。

==設定==

システムの設定ファイルは {{ic|/etc/asound.conf}} で、ユーザー別の設定ファイルは {{ic|~/.asoundrc}} です。

===デフォルトサウンドカードの設定===

起動毎にサウンドカードの順番が変わってしまうときは、{{ic|/etc/modprobe.d}} 内の {{ic|.conf}} で終わるファイル (例: {{ic|/etc/modprobe.d/alsa-base.conf}}) に順番を明記することができます。
例えば、mia サウンドカードを #0 にしたい場合は:

{{hc|/etc/modprobe.d/alsa-base.conf|2=<nowiki>
options snd slots=snd_mia,snd_hda_intel
options snd_mia index=0
options snd_hda_intel index=1
</nowiki>}}

{{ic|<nowiki>$ cat /proc/asound/modules</nowiki>}} を使ってロードされているサウンドモジュールとその順番を取得してください。{{ic|<nowiki>$ lsmod | grep snd</nowiki>}} を使ってデバイス・モジュールのリストを取得してください。この設定では {{ic|snd_mia}} を使うサウンドカードと {{ic|snd_hda_intel}} を使うサウンドカード (例: オンボード) を一枚づつ挿していると仮定しています。

index を {{ic|-2}} にすることで ALSA にカードを優先的に使わせないようにすることも可能です。Linux Mint や Ubuntu などのディストリビューションでは以下の設定を使うことで USB やその他の"一般的でない"ドライバに index {{ic|0}} を与えないようにしています:

{{hc|/etc/modprobe.d/alsa-base.conf|2=
options bt87x index=-2
options cx88_alsa index=-2
options saa7134-alsa index=-2
options snd-atiixp-modem index=-2
options snd-intel8x0m index=-2
options snd-via82xx-modem index=-2
options snd-usb-audio index=-2
options snd-usb-caiaq index=-2
options snd-usb-ua101 index=-2
options snd-usb-us122l index=-2
options snd-usb-usx2y index=-2
options snd-pcsp index=-2
options snd-usb-audio index=-2
}}

変更を反映させるには再起動する必要があります。

==== 環境変数を使ってデフォルト PCM を選択する ====

設定ファイルで、以下を追加してください:
pcm.!default {
type plug
slave.pcm {
@func getenv
vars [ ALSAPCM ]
default "hw:Audigy2"
}
}

default の行はあなたのカードの名前に置き換える必要があります (ここでは {{ic|Audigy2}} を例にしています)。{{ic|aplay -l}} で名前を取得することができ '''surround51''' のように PCM を使うことも可能です。ただしマイクロフォンを使う必要がある場合は full-duplex PCM をデフォルトにすると良いでしょう。

これで環境変数 {{ic|ALSAPCM}} を変更することでサウンドカードを選択できるようになります。カードを選択できない全てのプログラムで問題なく使えます。
例えば、'''mix51to20''' という名前の downmix PCM を書いたときは {{ic|mplayer}} を {{ic|ALSAPCM=mix51to20 mplayer example_6_channel.wav}} で使うことができます。

==== ハードウェアを直接割り当てる ====

{{Warning|この設定では他のアプリケーションからデバイスが使用不可能になります。この方法は、デジタル出力や音楽サーバーに捧げる場合など、わざとそうした場合にのみ推奨されます。サウンドサーバーや[[Advanced_Linux_Sound_Architecture#ミキシング|ミキシング]]無しの設定は[[Chromium]]等の幾つかのアプリケーションでサポートされていません。}}

まずデフォルトに設定したいカード・デバイスの id を {{ic|aplay -l}} で見つける必要があります:

{{hc|$ aplay -l|2=
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: CONEXANT Analog [CONEXANT Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: Conexant Digital [Conexant Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: JamLab [JamLab], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: Audio [Altec Lansing XT1 - USB Audio], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
}}

例えば、このリストの最後のエントリはカード ID 2,カード名 Audio でデバイス ID 0 です。このカードをデフォルトにするには、システム全体のファイル {{ic|/etc/asound.conf}} かユーザー定義ファイル {{ic|~/.asoundrc}} のどちらかを使ってください。ファイルが存在しないときは作成する必要があります。そして以下のオプションを適切なカード・デバイス id を使って挿入して下さい。

{{bc|
pcm.!default {
type hw
card Audio #又はcard 2
hint
show on #幾つかのアプリケーションで必要
}
}

ctl.!default {
type hw
card Audio
}

pcm.dmixer {
type dmix
ipc_key 2048
slave {
pcm "hw:Audio"
}
}
pcm.dsnooper {
type dsnoop
ipc_key 2048
slave {
pcm "hw:Audio"
}
}
}}

カードIDではなくカード名の使用をおすすめします。デバイスの順番に依存しないためです。

{{ic|pcm.dmixer}}と{{ic|pcm.dsnooper}}は[[Advanced_Linux_Sound_Architecture#ミキシング|ミキシング]]が必要なアプリケーションの為の予備です。
{{Accuracy|General method to select alsa device should be introduced such as environment value.}}
例えば、{{ic|1=chromium -alsa-output-device=pcm.dmixer -alsa-input-device=pcm.dsnooper}}でChromiumがミキシングを使えるようになります。

{{Note|Asus U32U シリーズではカードの pcm と ctl の両方を 1 に設定する必要があります。}}

'pcm' オプションは音声の再生で使われるカード・デバイスに影響を与え、'ctl' オプションは alsamixer などのコントロールユーティリティで使われるカードに影響を与えます。

アプリケーション (mplayer など) を（再）起動すれば変更はすぐ適用されます。また、''aplay'' などのコマンドを使ってテストすることが可能です。

$ aplay -D default:PCH ''your_favourite_sound.wav''

asound 設定に関するエラーが表示される場合は、[http://www.alsa-project.org/main/index.php/Asoundrc#The_default_plugin 上流のドキュメント] を確認して設定ファイルフォーマットの変更を確認してください。

===サウンドモジュールがロードされていることを確かめる===

udev が正しくサウンドカードを検知しているかチェックするには次のコマンドを実行してください:

{{hc|<nowiki>$ lsmod | grep '^snd' | column -t</nowiki>|<nowiki>
snd_hda_codec_hdmi 22378 4
snd_hda_codec_realtek 294191 1
snd_hda_intel 21738 1
snd_hda_codec 73739 3 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel
snd_hwdep 6134 1 snd_hda_codec
snd_pcm 71032 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_timer 18992 1 snd_pcm
snd 55132 9 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer
snd_page_alloc 7017 2 snd_hda_intel,snd_pcm
</nowiki>}}

出力が上と同じようになっていれば、サウンドドライバが首尾よく自動検出されています。
{{Note|{{ic|udev>=171}} から、OSS エミュレーションモジュール ({{ic|snd_seq_oss, snd_pcm_oss, snd_mixer_oss}}) はデフォルトではロードされないようになりました: 必要ならば[[カーネルモジュール#ロード|手動でロードしてください]]。}}

{{ic|/dev/snd/}} ディレクトリにデバイスファイルがあるか調べてもいいかもしれません:

{{hc|$ ls -l /dev/snd|2=<nowiki>
total 0
crw-rw---- 1 root audio 116, 0 Apr 8 14:17 controlC0
crw-rw---- 1 root audio 116, 32 Apr 8 14:17 controlC1
crw-rw---- 1 root audio 116, 24 Apr 8 14:17 pcmC0D0c
crw-rw---- 1 root audio 116, 16 Apr 8 14:17 pcmC0D0p
crw-rw---- 1 root audio 116, 25 Apr 8 14:17 pcmC0D1c
crw-rw---- 1 root audio 116, 56 Apr 8 14:17 pcmC1D0c
crw-rw---- 1 root audio 116, 48 Apr 8 14:17 pcmC1D0p
crw-rw---- 1 root audio 116, 1 Apr 8 14:17 seq
crw-rw---- 1 root audio 116, 33 Apr 8 14:17 timer
</nowiki>}}

{{Note|IRC やフォーラムで助けを求める時は、上記のコマンドの出力を貼って下さい。}}

とにかく '''controlC0''' や '''pcmC0D0p''' のようなデバイスがあれば、サウンドモジュールが正しくロードされていることを示しています。

そうなってないのなら、あなたのサウンドモジュールは正しく検出されていません。これを解決するには、手動でモジュールのロードを試して下さい:

* サウンドカードのモジュールを確認します: [http://www.alsa-project.org/main/index.php/Matrix:Main ALSA Soundcard Matrix] モジュールには名前の前に 'snd-' が付きます (例: {{ic|snd-via82xx}})。
* [[カーネルモジュール#ロード|モジュールをロードします]]。
* {{ic|/dev/snd}} の中のデバイスファイルを確認したり（上述）、{{ic|alsamixer}} や {{ic|amixer}} に変化がないか調べて下さい。
* {{ic|snd-NAME-OF-MODULE}} と {{ic|snd-pcm-oss}} を[[カーネルモジュール#ロード|起動時にロード]]するよう設定して下さい。

===S/PDIF 出力===

[[wikipedia:ja:S/PDIF|S/PDIF]] はコンピュータとオーディオアンプを接続するときにしばしば使われるデジタルオーディオインターフェイスです (5.1/7.1 サラウンドのホームシアターなど)。
{{note|サウンドカードによっては以下の瀬底でアナログ出力が無効になることがあります (例: Sound Blaster Audigy 2)。}}
使用している[[シェル]]にあわせて、シェルの設定ファイルに以下の行を追加してください:
amixer -c 0 cset name='IEC958 Playback Switch' on

カードのデジタル出力の名前は以下のコマンドで確認できます:
$ amixer scontrols

===イコライザー===

====AlsaEqual を使う (UI あり)====

{{AUR|alsaequal}} パッケージをインストールしてください。

パッケージをインストールした後、以下を ALSA 設定ファイル ({{ic|~/.asoundrc}} か {{ic|/etc/asound.conf}}) に挿入してください:

ctl.equal {
type equal;
}

pcm.plugequal {
type equal;
# Modify the line below if you do not
# want to use sound card 0.
#slave.pcm "plughw:0,0";
#by default we want to play from more sources at time:
slave.pcm "plug:dmix";
}
#pcm.equal {
# If you do not want the equalizer to be your
# default soundcard comment the following
# line and uncomment the above line. (You can
# choose it as the output device by addressing
# it with specific apps,eg mpg123 -a equal 06.Back_In_Black.mp3)
pcm.!default {
type plug;
slave.pcm plugequal;
}

x86_64 環境で {{Pkg|lib32-flashplugin}}{{Broken package link|{{aur-mirror|lib32-flashplugin}}}} を使用している場合、上記の設定では flash で音が鳴りません。以下の設定で flash の音を有効にできますが、{{ic|pcm "hw:0,0"}} の行でサウンドカードを手動で指定する必要があります (利用可能なサウンドカードとカードのデバイス番号は {{ic|aplay -l}} で確認できます):

{{hc|/etc/asound.conf|2=
pcm.dmixer {
type dmix
ipc_key 2048
slave {
pcm "hw:0,0"
buffer_size 16384
}
}

ctl.equal {
type equal;
}

pcm.equalizer {
type equal
slave.pcm "plug:dmixer"
}

pcm.!default {
type plug
slave.pcm equalizer
}
}}

次のコマンドを使ってイコライザーを変更することができます:
$ alsamixer -D equal

設定ファイルはユーザーごとに違うので注意してください。{{ic|~/.alsaequal.bin}}　に保存されます。
AlsaEqual を異なるユーザーの [[Music Player Daemon|mpd]] などのソフトウェアで使いたいときは、次を実行することで設定できます:
# su mpd -c 'alsamixer -D equal'
もしくは、ユーザーの home にある {{ic|.alsaequal.bin}} のシンボリックリンクを作って下さい。

=====AlsaEqual の管理=====

{{AUR|alsaequal-mgr}} パッケージをインストールしてください。

通常通りイコライザーを設定してください:
$ alsamixer -D equal

状態に満足したら、名前を付けて保存してください (例: "foo"):
$ alsaequal-mgr save foo

イコライザーの状態 "foo" は次のコマンドで戻すことができます:
$ alsaequal-mgr load foo

ゲームや映画、音楽のジャンル別、VoIP アプリなどそれぞれに合わせてイコライザーの状態を作成し、必要なときにリロードできます。

オプションの詳細は [https://xyne.archlinux.ca/projects/alsaequal-mgr/ project page] を見て下さい。

====mbeq を使う====

{{Note|この方法では ladspa プラグインを使う必要があります。サウンドを再生する際に CPU の使用量が多めです。さらに、ステレオサウンドを念頭に置いて作成されています (例: ヘッドフォン)。}}

{{Pkg|alsa-plugins}}, {{Pkg|ladspa}}, {{Pkg|swh-plugins}} パッケージをインストールしてください。

まだ {{ic|~/.asoundrc}} か {{ic|/etc/asound.conf}} ファイルを作成していない場合は、どちらかを作成して以下を挿入して下さい:

{{hc|/etc/asound.conf|2=<nowiki>pcm.eq {
type ladspa

# The output from the EQ can either go direct to a hardware device
# (if you have a hardware mixer, e.g. SBLive/Audigy) or it can go
# to the software mixer shown here.
#slave.pcm "plughw:0,0"
slave.pcm "plug:dmix"

# Sometimes you may need to specify the path to the plugins,
# especially if you have just installed them. Once you have logged
# out/restarted this should not be necessary, but if you get errors
# about being unable to find plugins, try uncommenting this.
#path "/usr/lib/ladspa"

plugins [
{
label mbeq
id 1197
input {
#this setting is here by example, edit to your own taste
#bands: 50hz, 100hz, 156hz, 220hz, 311hz, 440hz, 622hz, 880hz, 1250hz, 1750hz, 25000hz,
#50000hz, 10000hz, 20000hz
controls [ -5 -5 -5 -5 -5 -10 -20 -15 -10 -10 -10 -10 -10 -3 -2 ]
}
}
]
}

# Redirect the default device to go via the EQ - you may want to do
# this last, once you are sure everything is working. Otherwise all
# your audio programs will break/crash if something has gone wrong.

pcm.!default {
type plug
slave.pcm "eq"
}

# Redirect the OSS emulation through the EQ too (when programs are running through "aoss")

pcm.dsp0 {
type plug
slave.pcm "eq"
}
</nowiki>}}

==高品質なリサンプリング==

ソフトウェアミキシングが有効になっていると、ALSA は全てを同じ周波数 (デフォルトで 48000) にリサンプリングします。dmix はサウンドの品質を落としてしまう低品質リサンプリングアルゴリズムを使っています。

{{pkg|alsa-plugins}} と {{pkg|libsamplerate}} をインストールして下さい。

デフォルトの変換器を libsamplerate に変更します:

{{hc|/etc/asound.conf|defaults.pcm.rate_converter "samplerate_best"}}

または:

{{hc|~/.asoundrc|defaults.pcm.rate_converter "samplerate_best"}}

'''samplerate_best''' は最高のサウンド品質を提供しますが、リアルタイムサンプリングをするには CPU サイクルが大量に必要になるので使うにはそこそこの CPU が必須です。また、dmix の設定で buffer_size を基本の 4096 から 8192 か 16384 に調整する必要もあるかもしれません。他のアルゴリズム ('''samplerate''' など) も利用できますがデフォルトのリサンプラーに比べておそらくあまり改善はないでしょう。

{{Warning|環境によっては、samplerate_best を有効にすると flashplayer でサウンドが出力されなくなるという問題が発生します。}}

==アップ・ダウンミキシング==

===アップミキシング===

音楽などのステレオ音源を 5.1 や 7.1 サウンドシステムをフルに使って再生するには、アップミキシングを使う必要があります。黎明期ではこれをするのはとても難しいものでした。ですが現在では簡単にアップミキシングができるプラグインがあります。{{Pkg|alsa-plugins}} に含まれている {{ic|upmix}} プラグインを使います。

それから以下を ALSA 設定ファイル ({{ic|/etc/asound.conf}} か {{ic|~/.asoundrc}}) に追加してください:
pcm.upmix71 {
type upmix
slave.pcm "surround71"
delay 15
channels 8
}

上の例は 7.1 のものですが 5.1 や 4.0 にも簡単に変えられます。

設定をするとアップミキシングに使う新しい pcm が加わります。全てのサウンド音源をこの pcm に通したい時は、次のようにデフォルトとして追加してください:

pcm.!default "plug:upmix71"

このプラグインは使うにあたって特に設定を変える必要はありません。
プラグインが動作しないときは、以下のようにしてアップミキシングする PCM のための dmixer を自分で設定してください:
pcm.dmix6 {
type asym
playback.pcm {
type dmix
ipc_key 567829
slave {
pcm "hw:0,0"
channels 6
}
}
}

そして "surround71" のかわりに "dmix6" を使って下さい。
音がスキップしたり歪むときは、buffer_size を増やす (例: 32768) か [[#高品質なリサンプリング|高品質リサンプラー]]を使ってください。

===ダウンミキシング===
5.1 サウンドの映画をステレオシステムで視聴するときなど、音源をステレオにダウンミキシングしたい場合、{{Pkg|alsa-plugins}} に含まれている {{ic|vdownmix}} プラグインを使って下さい。

設定ファイルに以下を追加して下さい:

pcm.!surround51 {
type vdownmix
slave.pcm "default"
}
pcm.!surround40 {
type vdownmix
slave.pcm "default"
}

{{Note|1=これだけではダウンミキシングが動作しないかもしれません、[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541786] を参照してください。その場合、{{ic|pcm.!default "plug:surround51"}} か {{ic|pcm.!default "plug:surround40"}} を追加する必要があります。{{ic|vdownmix}} プラグはひとつだけ使うことができます; 7.1 チャンネルのときは、上の設定の代わりに {{ic|surround71}} を使って下さい。{{ic|vdownmix}} と {{ic|dmix}} の両方を動かす設定例が[https://bbs.archlinux.org/viewtopic.php?id=167275 ここ]にあります。}}

==ミキシング==

ミキシングを使うことで複数のアプリケーションが同時に音を出力することが可能になります。外付けのサウンドカードはほとんどの場合ハードウェアミキシングをサポートしており、可能であればデフォルトで有効にされます。内蔵のマザーボードに載っているサウンドカード (Intel HD Audio など) は基本的にハードウェアミキシングをサポートしていません。そのようなカードでは、dmix という名前の ALSA プラグインを使ってソフトウェアミキシングを利用します。この機能はハードウェアミキシングが使えない場合に自動で有効にされます。

===手動で dmix を有効にする===

{{Note|ALSA 1.0.9rc2 以上ではアナログサウンドに dmix を設定する必要はありません。ハードウェアミキシングをサポートしていないサウンドカードのために Dmix はデフォルトで有効にされています。}}

ソフトウェアミキシングが動作しない場合は、あなたの home フォルダに以下の内容で .asoundrc ファイルを作成してください。

pcm.dsp {
type plug
slave.pcm "dmix"
}

これでソフトウェアミキシングが有効になり複数のアプリケーションがサウンドカードを使えるようになるはずです。使えない場合は、{{ic|/etc/asound.conf}} の中身を全て上のように置き換えてみて下さい。

S/PDIF などのデジタル音声出力をするために、ALSA パッケージは依然として dmix をデフォルトで有効にしていません。そのため、上の dmix 設定は S/PDIF デバイスで dmix を有効にするために使うことはできません。

一般的な問題と解決方法は [[Advanced Linux Sound Architecture/トラブルシューティング]] を見て下さい。

===ハードウェアミキシング===

====サポート====

ハードウェアでミキシングをサポートしているオーディオチップセットを持っている場合、設定は必要ありません。ほとんど全てのオンボード・オーディオチップセットはハードウェアミキシングをサポートしていないので、ソフトウェアでミキシングする必要があります（上述）。ハードウェアミキシングをサポートしているサウンドカードは少なく、Linux でサポートされているサウンドカードは以下になります:

* Creative SoundBlaster Live! (5.1 モデル)
* Creative SoundBlaster Audigy (複数)
* Creative SoundBlaster Audidy 2 (ZS モデル)
* Creative SoundBlaster Audigy 4 (Pro モデル)

{{Note|
* 上記のカードのローエンド版 (Audigy SE, Audigy 2 NX, SoundBlaster Live! 24bit, SoundBlaster Live! 7.1) は別のチップを使っているためハードウェアミキシングに対応していません。
* オンボードの VIA8237 チップは4ストリームのハードウェアミキシングに対応していますが、マザーボードによってはそれが3ストリームになったり (4番目のストリームが音を出さない) あるいは使えないこともあります。動作したとしても、他の方法と比べて音質は劣ります。}}

====フィックス====

64-bit Arch で Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02) を使っている場合、Enemy Territory でサウンドを鳴らすには以下を実行して下さい:
echo "et.x86 0 0 direct" > /proc/asound/card0/pcm0p/oss
echo "et.x86 0 0 disable" > /proc/asound/card0/pcm0c/oss

== ヒントとテクニック ==

=== USB サウンドカードのホットプラグ ===

USB サウンドカードが挿入されたときに、自動的に第一のアウトプットデバイスにするために、以下の udev ルールを使うことができます (例: 以下の2行を {{ic|/etc/udev/rules.d/00-local.rules}} に追加して再起動する)。

{{bc|1=KERNEL=="pcmC[D0-9cp]*", ACTION=="add", PROGRAM="/bin/sh -c 'K=%k; K=$${K#pcmC}; K=$${K%%D*}; echo defaults.ctl.card $$K > /etc/asound.conf; echo defaults.pcm.card $$K >>/etc/asound.conf'"
KERNEL=="pcmC[D0-9cp]*", ACTION=="remove", PROGRAM="/bin/sh -c 'echo defaults.ctl.card 0 > /etc/asound.conf; echo defaults.pcm.card 0 >>/etc/asound.conf'"}}

=== 同時出力 ===

ミニジャックで接続した外付けスピーカーと内蔵のスピーカーで同時に音楽を再生したい場合、{{ic|alsamixer}} や {{ic|amixer}} を使うことで ''Auto-Mute'' のミュートを解除してください:
$ amixer sset "Auto-Mute" unmute

そして ''Headphones''', ''Speaker'', '''Bass Speaker'' など他の必要なアイテムのミュートを解除してください。
{{Note|(ミニジャック) ヘッドフォンコネクタで接続した場合に音が割れる場合、[[Advanced Linux Sound Architecture/トラブルシューティング#ミニジャック (ヘッドフォンコネクタ) で音が割れる]]を見て下さい。}}

=== キーボードのボリュームコントロール ===

以下のコマンドをボリュームキーにマッピングしてください: {{ic|XF86AudioRaiseVolume}}, {{ic|XF86AudioLowerVolume}}, {{ic|XF86AudioMute}}

ボリュームを上げるには:
amixer set Master 5%+

ボリュームを下げるには:
amixer set Master 5%-

==トラブルシューティング==
[[Advanced Linux Sound Architecture/トラブルシューティング]]を見て下さい。

==設定例==

[[Advanced Linux Sound Architecture/設定例]]を見て下さい。

==参照==
* [http://www.alsa-project.org/ ALSA wiki]
* [http://www.alsa-project.org/main/index.php/Asoundrc Asoundrc]
* [http://alsa.opensrc.org/ 非公式 ALSA wiki]
* [https://www.mjmwired.net/kernel/Documentation/sound/alsa/ALSA-Configuration.txt 高度な ALSA モジュール設定]
* [https://bbs.archlinux.org/viewtopic.php?id=36815 HOWTO: compile driver from svn]
* [http://www.volkerschatz.com/noise/alsa.html A close look at ALSA: ALSA concept introduction]
* [http://www.sabi.co.uk/Notes/linuxSoundALSA.html Linux ALSA sound notes]

Discord

2025-04-23T13:52:08Z

Oech3: /* 純粋な ALSA 環境でボイスチャットができない */

[[Category:インスタントメッセージ]]
[[en:Discord]]
[[ru:Discord]]
[[tr:Discord]]
[[zh-hans:Discord]]
{{Related articles start}}
{{Related|Slack}}
{{Related articles end}}
Discord はプロプライエタリで、クロスプラットフォームの、オールインワンなボイス・テキストチャットアプリケーションです。多くのオープンソースコミュニティが[https://discord.com/open-source 公式の Discord サーバ]を持っています。Discord は、Web ブラウザで使うこともできますし、([https://github.com/electron/electron Electron] で作成されている) デスクトップアプリケーションから使うこともできます。

== インストール ==

以下のパッケージのうちどれかを使って Discord のデスクトップアプリケーションをインストールできます:

=== グラフィカルなクライアント ===

==== 公式アプリケーション ====

* 安定版: {{Pkg|discord}}
* テスト版: {{AUR|discord-ptb}}
* Nightly 版: {{AUR|discord-canary}}

==== システムの electron を使用する公式クライアント ====

セキュリティ向上と潜在的なパフォーマンス向上のために、システムで提供される {{Pkg|electron}} を使用する公式クライアント:

* 安定版: {{AUR|discord_arch_electron}}
* Nightly 版: {{AUR|discord-canary-electron-bin}}

または、[[Flatpak]] で Discord を入手することもできます。この方法は、システムのライブラリに関連するいくつかの問題を解決することがあり、一部のケースでパフォーマンスが向上します。しかし、Rich Presence を有効化するには追加の作業が必要となります。[[#Flatpak 版で Rich Presence を有効化する]] を参照してください。

$ flatpak install discord

==== サードパーティのクライアント ====

{{Warning|サードパーティのクライアントや、Discord クライアントを改造する非公式のパッケージやアプリケーションの使用は、[https://discord.com/terms DISCORDサービス利用規約]違反となり、あなたのアカウントが Ban される場合があります [https://github.com/Bios-Marcel/cordless#i-am-closing-down-the-cordless-project]。そのようなパッケージを使用する際は、あなたがすべての責任を負うことになります。バージョンの古いクライアントや放棄されたクライアントの使用は避けてください。Discord の API のアンチスパムシステムに引っかかり、その結果あなたのアカウントが Ban される可能性があるからです。}}

* {{App|Abaddon|C++/gtkmm で作成された、音声サポート付きの代替 Discord クライアント。|https://github.com/uowuo/abaddon|{{AUR|abaddon}}}}
* {{App|discord-screenaudio|Linux での音声付きストリーミングをサポートするカスタム discord クライアント。|https://github.com/maltejur/discord-screenaudio|{{AUR|discord-screenaudio}}}}
* {{App|Dissent|Go で書かれた GTK4 Discord クライアント。|https://github.com/diamondburned/dissent|{{AUR|dissent-git}}}}
* {{App|[[Ripcord]]|Slack と Discord のようなグループ中心型サービスのための、Qt toolkit 上に構築された、軽量のプロプライエタリなデスクトップチャットクライアント。|https://cancel.fm/ripcord/|{{AUR|ripcord}}}}
* {{App|WebCord|Discord ウェブクライアントのラッパ。プライバシーを向上し、Wayland 上でのスクリーン共有を可能にします。|https://github.com/SpacingBat3/WebCord|{{AUR|webcord}}}}
* {{App|VenCord|Discord の起動前に全体をロードする Discord クライアント mod。Discord をより高速に、より安定化させることを目的としています。|https://github.com/Vendicated/Vencord|{{AUR|vencord-installer-bin}}}}
* {{App|ArmCord|軽量に保ちつつ Discord のエクスペリエンスを向上させるために設計されたカスタムクライアント。|https://github.com/ArmCord/ArmCord|{{AUR|armcord-bin}}}}
* {{App|Vesktop|Vesktop は、より高速な Discord エクスペリエンスを提供するたに作られたクロスプラットホームのデスクトップアプリです。音声付きのスクリーンキャストをサポートしています。|https://github.com/Vencord/Vesktop|{{AUR|vesktop-bin}}}}

=== コマンドラインのクライアント ===

CLI ベースのサードパーティ製クライアントが AUR 上に多数存在しています (GitHub 上にもパッケージングされていないものが存在します)。しかし、それらのうち殆どは非推奨となっているか壊れています。[https://github.com/ayntgl/discordo discordo] はメンテナンスされており、さらに AUR 上に {{AUR|discordo-git}} としてパッケージングされています。

=== チャットクライアントプラグイン ===

* {{App|purple-discord|[[Pidgin]] などの {{Pkg|libpurple}} ベースのメッセンジャーのための Discord プラグイン。|https://github.com/EionRobb/purple-discord|{{AUR|purple-discord-git}}}}
* {{App|bitlbee-discord|[[Bitlbee]] のための Discord プラグイン。|https://github.com/sm00th/bitlbee-discord|{{AUR|bitlbee-discord-git}}}}
* {{App|weechat-discord|[[WeeChat]] のための Discord プラグイン。|https://github.com/terminal-discord/weechat-discord|{{AUR|weechat-discord-git}}}}

=== カスタム CSS & プラグイン ===

* {{App|BetterDiscord|CSS とプラグインを使えるように Discord を改造するプロジェクトです。|https://betterdiscord.app/|{{AUR|betterdiscord-installer}}}}
* {{App|Discocss|Discord クライアントにカスタムの CSS をインジェクトできるシンプルなスクリプトです。{{AUR|discord-ptb}} と {{AUR|discord-canary}} のバージョンに CSS をインジェクトするには、{{ic|discord}} フォルダ内の記述をすべて使用するバージョンに置き換えてください。|https://github.com/mlvzk/discocss|{{AUR|discocss-git}}}}
* {{App|Replugged|Powercord のフォーク。軽量の Discord クライアント MOD。シンプリシティとパフォーマンスにフォーカスを置いています。|https://github.com/replugged-org/replugged|{{AUR|replugged-electron-git}}}}
* {{App|VenCord|Discord の起動前に全てを読み込む Discord クライアント MOD です。Discord をより高速化かつ安定させることを目的としています。|https://github.com/Vendicated/Vencord|{{AUR|vencord-installer-bin}}}}

=== オーバーレイ ===

Linux クライントでは、Discord はゲーム内オーバーレイをサポートしていません。{{AUR|discover-overlay}} は、オープンソースの GTK アプリケーションで、そのような機能を提供します。Discover は X11 や wlroots 環境で機能します。

=== ユーティリティ ===

* {{App|[[Chuncord]]|Webhook を使って Discord CDN にファイルを部分毎にアップロードするコマンドラインツールです。|https://git.lemonsh.moe/lemon/chuncord|{{AUR|chuncord}}}}

== ヒントとテクニック ==

=== GNOME のトップバーアイコン ===

GNOME のトップバーにアイコンを配置したい場合、[https://extensions.gnome.org/extension/615/appindicator-support/ 拡張機能 AppIndicator and KStatusNotifierItem Support] と {{Pkg|libappindicator-gtk3}} をインストールしてください。

=== リポジトリでまだ利用できないアップデートを Discord が要求してくる ===

Discord は、利用可能なアップデートがある場合、起動を拒否し、''"Must be your lucky day, there's a new update!"'' と表示されます。アップデート後のバージョンがまだ公式リポジトリ内で利用できない場合、[[Arch build system]] を使ってアップデート後のパッケージをビルド、インストールできます。

アップデートのチェックを無効化するには、以下を {{ic|~/.config/discord/settings.json}} に追加してください:

{{hc|~/.config/discord/settings.json|
"SKIP_HOST_UPDATE": true
}}

JSON の要件上、{{ic|WINDOW_BOUNDS}} オブジェクトの後にコンマを追加する必要があることに注意してください。つまり:

{{bc|1=
{
"IS_MAXIMIZED": true,
"IS_MINIMIZED": false,
"WINDOW_BOUNDS": {
"x": 2240,
"y": 219,
"width": 1280,
"height": 720
},
"SKIP_HOST_UPDATE": true
}
}}

=== Discord を最小化した状態で起動する ===

{{ic|--start-minimized}} 引数を使えば、最小化した状態で Discord を起動できます。

=== マイクのノイズを抑制する ===

Discord にはノイズ抑制が組み込まれており、[https://krisp.ai/ Krisp] が提供する標準オプションと AI を利用したオプションの両方があります。[[PipeWire# Noise suppression for voice]] に従って、PipeWire に独自のノイズ抑制を提供することもできます。

=== 音声と一緒に画面共有する ===

{{Out of date|1=Discord の意図は、最終的には PipeWire でネイティブな音声共有を提供することです。 [https://www.reddit.com/r/discordapp/comments/yerhzq/comment/iu14uja/?utm_source=reddit&utm_medium=web2x&context=3]}}

音声と一緒に画面共有することは、[https://support.discord.com/hc/en-us/community/posts/360050971374-Linux-Screen-Share-Sound-Support Linux ではサポートされていません]。代替策としては:

* PulseAudio については、次のとおりです。[[PulseAudio/サンプル#選択したオーディオソースの再マッピング]] 共有するプログラムの ''モニター'' ソースを取得します。これは、ブラウザーで実行されている Discord の別のインスタンスの入力として使用できます。

もう 1 つの方法は、オーディオをマイクでミックスするのではなく、Discord ストリームにオーディオをフィードするように改造されたクライアントを使用することです:

* PipeWire の場合、オーディオスクリーン共有を使用する最も簡単な方法は、{{AUR|discord-screenaudio}} を使用することです。

{{Warning|改造されたクライアントは Discord の利用規約に違反しています。詳細については、[[#インストール]] を参照してください。}}

=== Web RPC 拡張機能 ===

Discord rich presence の選択されたウェブアクティビティを表示するための拡張機能がいくつか存在します:

* {{AUR|PreMiD}} と適切なブラウザ[https://premid.app/downloads#ext-downloads 拡張機能]。
* {{AUR|discord-rpc-extension-bin}} と [https://github.com/lolamtisch/Discord-RPC-Extension/blob/master/docs/extensions.md PreWrap または Mal-sync] ブラウザ拡張機能。

=== 開発者ツールを有効化する ===

{{Warning|開発者ツールの ''コンソール'' にペーストされるコードは、あなたの認証情報を盗み、あなたの Discord アカウントを危険に晒す能力があります。あなたが何をしようとしているかを理解していないならば、この機能を有効化しないでください。}}

最近のアップデートで、安全上の理由により Discord 上の開発者ツールがデフォルトで無効化されました。開発者ツールを再び有効化するには、以下を {{ic|~/.config/discord/settings.json}} に追加してください:

"DANGEROUS_ENABLE_DEVTOOLS_ONLY_ENABLE_IF_YOU_KNOW_WHAT_YOURE_DOING": true

=== テキスト-トゥ-スピーチを有効化する ===

デフォルトでは、テキスト-トゥ-スピーチは Discord クライアントで無効化されています。しかし、{{ic|--enable-speech-dispatcher}} フラグを使うことで有効化できます。この機能は、スピーチを出力するために {{Pkg|speech-dispatcher}} デーモンを使用します。

== トラブルシューティング ==

=== ギルドをスクロールするときにラグい ===

ギルドをスクロールするときにラグやカクつきが発生する場合、ハードウェアアクセラレーションが正しく動作していることを確認してください。[[Chromium]] ベースのブラウザで {{ic|chrome://gpu}} を開くことで、確認することができます。ハードウェアアクセラレーションが動作していない場合、[[Chromium#ハードウェアビデオアクセラレーション]] の内容を確認し、いくつか追加のオプションを付けて Discord を実行してみてください:

$ discord --ignore-gpu-blocklist --disable-features=UseOzonePlatform --enable-features=VaapiVideoDecoder --use-gl=desktop --enable-gpu-rasterization --enable-zero-copy

=== 音声通話時に音が割れる ===

音声通話時に音声が割れる場合、[[PulseAudio/トラブルシューティング#バッファアンダーランのトラブルシューティング (音ズレ、音飛び、音割れ)]] の記事の手順を試してみてください。

=== Wayland での画面共有 ===

バージョン 0.0.17 現在、[https://support.discord.com/hc/en-us/articles/360040816151-Go-Live-and-Screen-Share 画面共有]機能は [[Wayland]] 上では動作しません ({{ic|1=/usr/bin/discord --enable-features=UseOzonePlatform --ozone-platform=wayland}} を使って Wayland のための [https://chromium.googlesource.com/chromium/src.git/+/HEAD/docs/ozone_overview.md Ozone] を有効化していたとしてもです)。[https://www.reddit.com/r/swaywm/comments/p2xgon/cant_run_discord_on_wayland/ この Reddit 投稿] と [https://support.discord.com/hc/en-us/community/posts/360047644231-Native-Wayland-Support?page=2#comments Discord バグレポート] を見てください。

可能な回避策は以下のとおりです:

* Firefox など、画面共有をサポートするブラウザ内で Discord を使う。ブラウザは、共有すべきウィンドウまたは画面を選択するネイティブなダイアログを表示します。
* XwaylandVideoBridge。[[Wayland#X11 アプリケーションで Wayland ウィンドウをスクリーンキャストする]] を参照。
* 仮想カメラを使う。[[Open Broadcaster Software#仮想カメラ出力]] と [[スクリーンキャプチャ#仮想 Web カメラのビデオフィードを使う]] を参照。
* [[#サードパーティのクライアント|サードパーティのクライアント]]を使う (Discord の利用規約に注意し、自己責任で使用してください):
** {{AUR|webcord}} は Wayland における画面共有を完全にサポートしています。しかし、ウェブバージョンの Discord をバンドルしているため、rich presence といった機能が不足しています。
** [https://github.com/Vencord/Vesktop Vesktop]。{{AUR|vesktop-bin}} でインストールできます。

=== Flatpak 版で Rich Presence を有効化する ===

Discord の [[Flatpak]] 版は、そのままでは Rich Presence が動作しません。動作させるには、{{ic|$XDG_RUNTIME_DIR/discord-ipc-0}} から {{ic|$XDG_RUNTIME_DIR/app/com.discordapp.Discord/discord-ipc-0}} へのシンボリックリンクを作成する必要があります。現在のユーザセッションでそのシンボリックリンクを作成するには、以下を実行してください:

$ ln -sf {app/com.discordapp.Discord,$XDG_RUNTIME_DIR}/discord-ipc-0

[[systemd-tmpfiles]] を使うことで、このシンボリックリンクを自動的に作成できます。{{ic|~/.config/user-tmpfiles.d/}} 内に拡張子 ''.conf'' のファイルを作成し、以下の行を追加してください:

L %t/discord-ipc-0 - - - - app/com.discordapp.Discord/discord-ipc-0

=== 長時間通話すると Discord が応答しなくなる===

長時間の通話により Discord が応答しなくなる場合、{{ic|--no-sandbox}} 引数を試してみてください。以下を [[.bashrc]] に追加したり、シェルのエイリアスファイルを追加したりすることもできます:

alias discord='discord --no-sandbox'

=== ping やメッセージを受け取ったときに Discord がフリーズする ===

通知をトリガーするようなメッセージ (ping、DM、通知を ON にしているサーバなど) によってクライアントがフリーズしてしまう場合、クライアントは[[デスクトップ通知#Libnotify|通知サーバ]]を見つけられなかったということです。通知サーバをインストールせずにこの問題を修正するには、''通知'' の ''デスクトップ通知を有効にする'' を無効化してください。

=== 通知音が PipeWire で鳴らない ===

[[PipeWire#Discord から通知音が鳴らない]] を見てください。

=== 絵文字が正しく描画されない ===

絵文字の描画の問題が発生する場合 (例えば、絵文字が四角として描画されるなど)、{{AUR|discord-canary-electron-bin}} には任意の依存パッケージとして適切なフォントがあります。{{AUR|ttf-symbola}}、{{Pkg|noto-fonts-cjk}}、{{Pkg|noto-fonts-emoji}} をインストールする必要があります。

絵文字をチャネル名に表示させるには {{AUR|ttf-twemoji}} が必要です。{{ic|75-twemoji.conf}} を {{ic|/etc/fonts/conf.d/}} へインストールしてください。デフォルトでは、このようにインストールされません。

=== リンクをクリックしても Web ブラウザが開かない ===

リンクをクリックしてもデフォルトの Web ブラウザでタブが開かない場合、任意の依存パッケージである {{Pkg|xdg-utils}} をインストールする必要があります。

=== KDE Plasma のシステムトレイの Discord アイコンがぼやける ===

{{Pkg|libappindicator-gtk3}} をインストールし {{Pkg|libappindicator-gtk2}} を置き換えることで、この問題の修正を試みることができます ({{Pkg|libappindicator-gtk2}} はこの問題を引き起こすことが知られています)。

=== Discord が systemd journal に大量のメッセージを送信する ===

Discord が [[journal]] に以下のようなフォーマットのメッセージを大量に作成してしまう場合があります:

(device_info_linux.cc:45): ''NumberOfDevices''

この汚染を引き起こすログを無効化するには、「ユーザ設定」に行き、「音声・ビデオ」を選択し、スクリーンの下までスクロールし、「デバッグログ」を無効化してください。

=== 純粋な ALSA 環境でボイスチャットができない ===

Discord のデスクトップアプリケーションは、ボイスチャットを [[PulseAudio]] に依存しており、[[ALSA]] で直接実行できません。[[Advanced Linux Sound Architecture#PulseAudio との互換性|apulse]] を回避策として使用することは、この場合非推奨です。''PulseAudio'' または ''Pipewire'' なしで Discord のボイスチャットを使用する場合は、[[アプリケーション一覧/インターネット#Blink ベース|Chromium ベースの Web ブラウザー]] から Discord の Web クライアントにアクセスします。あるいは、Chromium ベースのラッパーとして、[[#Third-party clients|Webcord]] は純粋な ALSA 環境で動作します。[[Chromium#サウンドサーバー無しだと音が出ない]]も見てください。

このルートを選択した場合、ミュートを解除できない、つまりマイクへのアクセス許可を得られない場合は、{{ic|~/.asoundrc}} で [[Advanced Linux Sound Architecture/トラブルシューティング#デフォルトのマイク・キャプチャデバイスの設定|デフォルトのマイク・キャプチャデバイスの設定]] します。また、Discord で、''ユーザー設定'' > ''音声とビデオ'' > ''入力デバイス'' に移動し、''デフォルト'' が選択されていることを確認します。

=== 通知バッジが表示されない ===

Discord はタスクバーアイコンに未読のメンション数を示すバッジを表示することができます。バッジが表示されない場合は、{{AUR|libunity}} パッケージがインストールされていることを確認してください、この機能を動作させるのに必要です。

=== NVIDIA プロプライエタリドライバで Wayland を起動すると黒い画面が表示される ===

Wayland 上の Discord は VA-API サポートを必要としますが、NVIDIA のプロプライエタリドライバにはありません。{{Pkg|libva-nvidia-driver}} などの変換レイヤーを使用して、VA-API サポートを得られます。

{{Note|{{Pkg|libva-vdpau-driver}} は、NVIDIA ドライバシリーズ 530 のリグレッションが原因で動作しない場合があります。}}

=== エモートが四角に文字化けする ===

エモートを正しく表示させるには、[[フォント#絵文字と記号|絵文字]]を含むフォントパッケージをインストールする必要があります。

{{TranslationStatus|Discord|2024-04-04|805198}}

Chromium

2025-04-23T13:22:47Z

Oech3: dsnooperを追加/* サウンドサーバー無しだと音が出ない */

[[Category:ウェブブラウザ]]
[[Category:Google]]
[[de:Chromium]]
[[en:Chromium]]
[[zh-hans:Chromium]]
{{Related articles start}}
{{Related|ブラウザ拡張機能}}
{{Related|Firefox}}
{{Related|Vivaldi}}
{{Related articles end}}

[[Wikipedia:ja:Chromium|Chromium]] は、[[Wikipedia:ja:Blink (レンダリングエンジン)|Blink]] レンダリングエンジンをベースとした、オープンソースなグラフィカルウェブブラウザです。プロプライエタリな Google Chrome ブラウザの基礎となっています。

Chromium と Google Chrome との違いについては [https://chromium.googlesource.com/chromium/src/+/master/docs/chromium_browser_vs_google_chrome.md このページ] を見てください。さらに:

* 同期は Chromium 89 以上 (2021-03-02) で利用できません。[https://archlinux.org/news/chromium-losing-sync-support-in-early-march/]

{{Note|同期は、[https://gist.github.com/foutrelis/14e339596b89813aa9c37fd1b4e5d9d5 Chrome の OAuth2 認証情報を使用する]か、[https://www.chromium.org/developers/how-tos/api-keys 自分の認証情報を取得する]ことで一時的に利用可能にできますが、免責事項に注意し、この方法を長期的な解決策と考えないでください。
長期的な解決策としては、ブックマークの同期するための [https://www.xbrowsersync.org xbrowsersync] に移行することを検討してください。}}

他の Chromium ベースのブラウザは [[アプリケーション一覧/インターネット#Blink ベース]] を見てください。

== インストール ==

Chromium を[[インストール]]できるパッケージがいくつか存在します:

* {{Pkg|chromium}} — 安定版
* {{AUR|chromium-dev}} — 開発版
* {{AUR|chromium-snapshot-bin}} — nightly ビルド

Google Chrome のパッケージは:

* {{AUR|google-chrome}} — 安定版
* {{AUR|google-chrome-beta}} — ベータ版
* {{AUR|google-chrome-dev}} — 開発版
* {{AUR|google-chrome-canary}} — カナリアリリース

{{Note|[https://www.chromium.org/Home/chromium-privacy Chromium プライバシーページ]によると(日本語訳):「Chromium のソースコードをコンパイルすることで利用可能になる Google と通信する機能は、[https://www.google.com/policies/privacy/ Google プライバシーポリシー]に従います。」Google サービスとの統合をすべて避けたい人向けに[[アプリケーション一覧/インターネット#プライバシー重視の chromium 派生版|プライバシー重視の Chromium 派生版]]があります。}}

== 設定 ==

=== デフォルトアプリケーション ===

Chromium をデフォルトのブラウザに設定したり、ダウンロードしたファイルを開くときに Chromium がどのアプリケーションを起動するかを変更したりするには、[[デフォルトアプリケーション]] を見てください。

=== 証明書 ===

Chromium は証明書の管理に [[Network Security Services]] を使っています。{{ic|chrome://settings/certificates}} で証明書を管理できます。

=== フラグを永続化する ===

{{Note|{{ic|chromium-flags.conf}} ファイルとそれに付随するカスタムランチャースクリプトは、Arch Linux の様々な Chromium パッケージに固有のものです。Google Chrome に対しては、代わりに {{ic|chrome-flags.conf}} (開発版やベータ版の場合は {{ic|chrome-''チャネル名''-flags.conf}}) を使用してください。}}

フラグは、{{ic|$HOME/.config/}} 内 ({{ic|$XDG_CONFIG_HOME}} 環境変数を設定した場合は、その環境変数が示すディレクトリの中) の {{ic|chromium-flags.conf}} ファイルに記述することができます。グローバルに設定したい場合は、{{ic|/etc/}} 内に配置できます。

特別な構文は使用されず、フラグはターミナルに書き込まれるのと同じように定義されます。

* 引数は空白で分割され、シェルの引用符の規則が適用されますが、それ以上の解析は実行されません。
* ファイル中のどこかが不適切に引用符によって囲まれている場合、致命的なエラーが発生します。
* フラグは読みやすくするために個別の行に分けることができますが、これは必須ではありません。
* ハッシュ記号 (#) で始まる行は読み飛ばされます。(これは Chromium のランチャースクリプトでのみサポートされており、Google Chrome を使用している場合は動作しません。)

以下は、フラグ {{ic|--start-maximized --incognito}} を定義している {{ic|chromium-flags.conf}} ファイルの例です:

{{hc|~/.config/chromium-flags.conf|
# この行は無視されます。
--start-maximized
--incognito
}}

=== GPU アクセラレーションを強制する ===

少なくとも Chromium 110 から、ほとんどのシステムに対して GPU アクセラレーションがデフォルトで有効化されています。あなたのシステム構成が[https://chromium.googlesource.com/chromium/src/gpu/+/master/config/software_rendering_list.json ブラックリスト]と合致する場合、以下のフラグを[[#フラグを永続化する|永続的な設定]]に[[追加]]する必要があります:

{{Warning|レンダリングブラックリストを無効化すると、ホストのクラッシュなどの不安定な挙動を引き起こすかもしれません。詳細については {{ic|chrome://gpu}} にあるバグレポートを見てください。}}

{{hc|~/.config/chromium-flags.conf|
--ignore-gpu-blocklist
--enable-zero-copy
}}

=== ハードウェアビデオアクセラレーション ===

{{Note|1=<nowiki/>
* この機能に対する Chromium や Arch Linux からの公式サポートはありません [https://chromium.googlesource.com/chromium/src/+/master/docs/gpu/vaapi.md#vaapi-on-linux]。しかし、公式リポジトリの {{Pkg|chromium}} は VA-API サポートありでコンパイルされており、[https://bbs.archlinux.org/viewtopic.php?id=244031 専用のフォーラムスレッド]で助けを求めることができます。
* Chromium バージョン 122 から、追加の [[VA-API]] のパッケージはもはや必要なくなりました。公式リポジトリの {{Pkg|chromium}} パッケージでネイティブな Wayland バックエンドを使用している場合、VA-API は動作します。
* AMD GPU デバイス上では、VA-API は[https://crbug.com/1445074 そのままでは動作しません]。動作させるには mesa >= 24.1 が必要であり、[https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26165 Vulkan を有効化する]必要があります。これによって、X11/XWayland で WebGL の問題が発生する場合があります。[[#ネイティブ Wayland サポート|ネイティブ Wayland サポートでの]] Vulkan はバージョン 125.0.6422.141-1 から動作します。
}}

{{Note|1=<nowiki/>
{{ic|chromium-flags.conf}} の適切なフラグの組み合わせを見つけようとしているのであれば、このファイルには {{ic|--enable-features}} や {{ic|--disable-features}} で始まる行はそれぞれ多くとも1行しか含むことができないことに注意してください。複数の機能はコンマで繋げることができます。
}}

{{ic|1=vainfo}} ([[ハードウェアビデオアクセラレーション#VA-API の確認]] を参照) の出力を見て VA-API のサポートがあることを確認した場合は、ひとまず以下のフラグだけで試してみてください:

{{hc|~/.config/chromium-flags.conf|2=
--enable-features=AcceleratedVideoDecodeLinuxGL
}}

{{Note|バージョン 131 より前の Chromium では、上記のフラグではなく {{ic|1=--enable-features=VaapiVideoDecodeLinuxGL}} を使用する必要があります。}}

それ以外の場合は、以下も読んでください。

Chromium でアクセラレートされた'''エン'''コードを有効化するには:

* {{ic|AcceleratedVideoEncoder}} を features に追加してください (例: {{ic|1=--enable-features=AcceleratedVideoDecodeLinuxGL,AcceleratedVideoEncoder}})。詳細は、[https://github.com/chromium/chromium/blob/main/docs/gpu/vaapi.md#vaapi-on-linux] と [https://issues.chromium.org/issues/40225939#comment54] を読んでください。

VA-API サポートを有効にするには:

* 使用中のビデオカード用の適切な VA-API ドライバをインストールしてください。そして、VA-API が有効化されて正常に動作していることを確認してください。[[ハードウェアビデオアクセラレーション]]を見てください。プロプライエタリな NVIDIA サポートは、{{Pkg|libva-nvidia-driver}} をインストールする必要があります。
* {{ic|1=--enable-features=VaapiVideoDecoder}} オプションを設定してください。ANGLE GL レンダラーと {{Pkg|libva-intel-driver}} を使用している場合は、これで十分です。
* ANGLE を使用すると、{{Pkg|intel-media-driver}} が使用されている場合、Chromium は古い i965 ドライバを強制的に使用し失敗します。回避策として、[[ハードウェアビデオアクセラレーション#VA-API の設定|VA-API を手動で設定]]してください。詳細については [https://github.com/intel/media-driver/issues/818] を見てください。
* Xorg か Wayland でシステムの GL レンダラを使用するには、{{ic|1=--use-gl=egl}} を使用してください。Chrome 112 を使用している場合、このオプションはもはや必要ないかもしれず、AMD GPU を使用している場合は GPU アクセラレーションの機能が壊れる場合があります。
* VA-API がまだ動かない場合は、{{ic|1=--enable-features=VaapiIgnoreDriverChecks}} か {{ic|1=--disable-features=UseChromeOSDirectVideoDecoder}} フラグを試してください。
* VA-API が Xorg と古い GPU 上でまだ動かない場合は、{{ic|1=LIBVA_DRI3_DISABLE=1}} [[環境変数]]を設定してください [https://www.phoronix.com/news/VA-API-libva-2.18]。

==== Vulkan ====

Vulkan を使用する場合、以下のフラグが必要で、Chromium 126 と Mesa 24.1 ではこれで十分でしょう:

{{hc|~/.config/chromium-flags.conf|2=
--enable-features=VaapiVideoDecoder,VaapiIgnoreDriverChecks,Vulkan,DefaultANGLEVulkan,VulkanFromANGLE
}}

先述の追加のフラグは入れないでください。

==== ヒントとテクニック ====

{{Out of date|
* Wayland + RADV の環境では Chromium は AV1 に VaapiVideoDecoder を使用します。
* Wayland + RADV の環境では Chromium は全てのサイスの動画に VaapiVideoDecoder を使用します。
}}

使用中の VA-API ドライバでサポートされているコーデックの動画の視聴がうまく行くかどうか確認するには (''vainfo'' はどのコーデックがサポートされているかを表示しますが、Chromium は VP9 と h264 だけをサポートします):

* {{ic|Ctrl+Shift+I}} を押すか、コンテキスト (右クリック) メニューの ''検証'' ボタンを押して DevTools を開いてください
* Media inspection タブを追加してください: ''ハンバーガーメニュー(︙) > More tools > Media''
* 新しく開いた Media タブで、Video Decoder の Hardware decoder の状態を見てください。

十分に大きな動画でテストしてください。バージョン 86 から、デスクトップ版の Chromium は [https://bugs.chromium.org/p/chromium/issues/detail?id=684792 720p よりも大きい動画でしかアクセラレーションを使用しません]。

VP8/VP9 ハードウェアデコードが使用できない Youtube 動画を視聴しているときに CPU 使用率を減らすには、[https://chrome.google.com/webstore/detail/h264ify/aleakchihdccplidncghkekgioiakgal h264ify] や [https://chrome.google.com/webstore/detail/enhanced-h264ify/omkfmpieigblcllmkgbflkikinpkodlk enhanced-h264ify]、[https://chrome.google.com/webstore/detail/not-yet-av1/dcmllfkiihingappljlkffafnlhdpbai Not yet, AV1][https://bbs.archlinux.org/viewtopic.php?pid=2039884#p2039884] 拡張機能を使用してください。

一部のシステム (特に Xwayland) では、[[#GPU アクセラレーションを強制する]] 必要があるかもしれません。このセクションでの目的に対しては {{ic|--ignore-gpu-blocklist}} のみで十分です。

Skia レンダラーは、現在ビデオデコードアクセラレーションと互換性がないので、無効化する必要があるかもしれません: {{ic|1=--disable-features=UseSkiaRenderer}}

=== KDE 統合 ===

[[Plasma]] との統合は {{Pkg|plasma-browser-integration}} を[[インストール]]してください。詳細は [https://community.kde.org/Plasma/Browser_Integration KDE Plasma Browser Integration] を見てください。

=== PDF ビューアプラグイン ===

Chromium と Google Chrome には ''Chromium PDF Viewer'' プラグインがバンドルされています。このプラグインを使用したくない場合は、{{ic|chrome://settings/content/pdfDocuments}} 内の ''Download PDFs'' を確認してください。

=== Xwayland での動作 ===

NVIDIA 社のプロプライエタリドライバを使用している場合、Xwayland 上で Chromium を実行すると、GPU プロセスが時々クラッシュすることがあります。GPU プロセスがクラッシュしないようにするには、以下のフラグを追加してください:

--use-angle=vulkan --use-cmd-decoder=passthrough

{{Note|これはすべての Xwayland 関連のクラッシュを防止するわけではありません。}}

=== ネイティブ Wayland サポート ===

バージョン 97 以降、Chromium でのネイティブ [[Wayland]] サポートは、次のフラグを使用して有効にできます [https://chromium.googlesource.com/chromium/src/+/43cfb2f92a5cdc1a787d7326e74676884abf5052]:

--ozone-platform-hint=auto

これがうまくいかない場合 (例えば [[Weston]] バージョン 106 以下の場合)、次を使ってください:

--ozone-platform=wayland

永続的な設定については [[#フラグを永続化する]] を参照してください。このフラグは[[#chrome:// URL|ブラウザのフラグメニュー]]からも設定できます。

この設定により、wayland セッション内では wayland Ozone バックエンドが選択されます。なので、X11 と Wayland を頻繁に切り替える場合でも、デスクトップエントリは一つだけで大丈夫です。

{{Note|ブラウザのフラグメニューで "ozone-platform-hint" を変更すると、ブラウザが再起動ボタンを表示させます。しかし、これは使用しないでください。ブラウザは、フラグが変更される前のプラットフォームで再起動されるからです。ブラウザを閉じて、その後、再び開く必要があります。}}

追加で、[https://bugs.chromium.org/p/chromium/issues/detail?id=1422087 インプットメソッドの問題]が発生している場合は、新しい GTK を強制すると良いかもしれません:

--gtk-version=4

Fcitx5 を使用していて上記のフラグを使うと正しく動作しない場合は、{{ic|1=--gtk-version=4}} の代わりに {{ic|--enable-wayland-ime}} フラグを使用してみてください。[https://fcitx-im.org/wiki/Using_Fcitx_5_on_Wayland#Chromium_.2F_Electron]

--enable-wayland-ime --wayland-text-input-version=3

{{Note|{{ic|text_input_v1}} プロトコルがデフォルトで実装されている場合、{{ic|--enable-wayland-ime}} フラグは機能します。このプロトコルを実装している既知のコンポジタは Weston、KWin、Hyprland です。}}

==== ナビゲーションのタッチパッドジェスチャ ====

2本の指でスワイプすると戻ったり進んだりする機能を有効にするには、以下のフラグを使用してください:

--ozone-platform-hint=auto --enable-features=TouchpadOverscrollHistoryNavigation

== ヒントとテクニック ==

特に注意書きがなければ以下のヒントとテクニックは Chromium と Chrome の両方で使うことができます。

=== ブラウズのエクスペリエンス ===

==== chrome:// URL ====

多くの調整は Chrome の URL からアクセスすることができます。完全なリストは '''chrome://chrome-urls''' を参照してください。

* '''chrome://flags''' - WebGL などの実験的な機能や GPU によるウェブページのレンダリングなどにアクセスできます。
* '''chrome://extensions''' - 現在使用している Chromium 拡張を表示・有効化・無効化。
* '''chrome://gpu''' - 様々な GPU オプションの状態。
* '''chrome://sandbox''' - サンドボックスの状態を表示。
* '''chrome://version''' - バージョンや {{ic|/usr/bin/chromium}} を実行するときに使われたスイッチを表示。

Chromium のスイッチ (コマンドラインパラメータ) の自動的に更新される完全なリストが [https://peter.sh/experiments/chromium-command-line-switches/ こちら] にあります。

==== Chromium タスクマネージャ ====

Shift+ESC でブラウザのタスクマネージャを立ち上げることができます。メモリや CPU、ネットワークの使用量が閲覧可能です。

==== Chromium が Preferences ファイルを上書き/オーバーライドしてしまう ====

Google アカウントの同期を有効にしている場合、{{ic|~/.config/chromium/Default/Preferences}} 下の Preferences ファイルに直接編集を加えていても Chromium によって上書きされてしまいます。上書きされないようにするには、{{ic|--disable-sync-preferences}} スイッチを付けて Chromium を起動してください:
$ chromium --disable-sync-preferences

デスクトップ環境のログイン時にバックグラウンドで Chromium を起動する場合、デスクトップ環境から使用するコマンドを以下のようにしてください:
$ chromium --disable-sync-preferences --no-startup-window

==== 検索エンジン ====

[https://wiki.archlinux.org wiki.archlinux.org] や [https://en.wikipedia.org wikipedia.org] などのウェブサイトは検索を実行してから ''Settings > Search'' を選択して ''Manage search engines..'' ボタンをクリックすることで簡単に検索できるように設定できます。エントリを "Edit" してキーワードを '''w''' などに変更してください (ショートカットは自由に決めて下さい)。これでアドレスバーに "'''w arch linux'''" と入力するだけで "Arch Linux" で検索できるようになります。

{{Note|URL バーに何か入力すると自動的に Google 検索が使われます。また、ハードコードされたキーワードトリガとして '''?''' プレフィックスが使えます。}}

==== Tmpfs ====

===== tmpfs にキャッシュ =====

{{Note|Chromium はブラウザのプロファイルディレクトリとキャッシュディレクトリを分離して保存します。}}

物理ディスクに対する Chromium のキャッシュの書き込みを制限したい場合、{{ic|--disk-cache-dir}} フラグでキャッシュの書き込み先を変更することができます:

$ chromium --disk-cache-dir="$XDG_RUNTIME_DIR/chromium-cache"

キャッシュは一時的になり、再起動したりハードロックすると'''消えます'''。もしくは、tmpfs 領域を {{ic|/etc/fstab}} 内でセットアップすることもできます:

{{hc|/etc/fstab|2=
tmpfs /home/''username''/.cache tmpfs noatime,nodev,nosuid,size=400M 0 0
}}

または、{{ic|/tmp}} へのシンボリックリンクを作成してください。以下のコマンドを実行する前に、Chromium のキャッシュフォルダは削除しておいてください:

$ ln -s /tmp /home/''ユーザ名''/.cache/chromium

また、全てのアプリケーションで有効な[[XDG_Base_Directory#ユーザーディレクトリ|XDG_CACHE_HOME]]もあります。

===== tmpfs にプロファイル =====

{{ic|/tmp}} や {{ic|/dev/shm}} などの [[Wikipedia:ja:Tmpfs|tmpfs]] ファイルシステムにプロファイルを保存することで、プロファイル全体が RAM 内に保存されるので、Chromium の応答性が改善されます。

{{Pkg|profile-sync-daemon}} などの、プロファイルを動的に管理するスクリプトを使うことで信頼性と使いやすさを最大限高めることができます。profile-sync-daemon はブラウザプロファイルのディレクトリのシンボリックリンクを作成し、定期的にメモリと同期をとります。詳細については [[Profile-sync-daemon]] の記事を参照して下さい。

==== 新しいブラウザインスタンスを起動 ====

ブラウザを起動すると、最初に同じプロファイルを使っているインスタンスが他にないか確認されます。存在する場合、新しいウィンドウは既存のインスタンスに関連付けられます。以下のように {{ic|--user-data-dir}} パラメータを使って起動することで別のプロファイルでブラウザを起動できます:

$ chromium --user-data-dir=''/path/to/some/directory''

{{Note|ユーザーデータのデフォルトパスは {{ic|~/.config/chromium/}} です。}}

==== torrent クライアントで *.torrent ファイルやマグネットリンクを直接開く ====

デフォルトでは Chromium は {{ic|*.torrent}} ファイルを直接ダウンロードするため、ファイルを torrent クライアントで開くには画面左下の通知をクリックする必要があります。以下の方法で毎回クリックする手間を省けます:

* {{ic|*.torrent}} ファイルをダウンロード。
* 画面左下に表示される通知を右クリック。
* "Always Open Files of This Type" チェックボックスにチェックを入れる。

デフォルトの関連付けの変更については [[xdg-open]] を見てください。

==== タッチスクリーンデバイスでタッチスクロール ====

使用するタッチデバイスを指定する必要があります。タッチスクリーンデバイスを {{ic|xinput list}} で確認して、{{ic|1=--touch-devices='''x'''}} パラメータを付けて Chromium を起動してください ("'''x'''" はデバイスの id に置き換えてください)。
{{Note|スレーブポインタのデバイスは使えません。マスターポインタの ID を使ってください。}}

==== メモリの使用量を減らす ====

デフォルトでは、Chromium は開いているウェブサイトの数だけ OS プロセスを作成します [https://www.chromium.org/developers/design-documents/process-models#Supported_Models]。Chromium の起動時にコマンドラインスイッチを指定することで挙動を変更することが可能です。

例えば、全てのウェブサイトでひとつのプロセスを共有するには:

$ chromium --process-per-site

シングルプロセスモデルを使うには:

$ chromium --single-process

{{Warning|シングルプロセスモデルは安全でなく他のモデルに存在しないバグが含まれている可能性があるため推奨されていません [https://www.chromium.org/developers/design-documents/process-models#TOC-Single-process]。}}

さらに [https://chrome.google.com/webstore/detail/tab-suspender/fiabciakcmgepblmdkmemdbbkilneeeh?hl=en Tab Suspender] や [https://chrome.google.com/webstore/detail/onetab/chphlpgkkbolifaimnlloiipkdnihall?hl=en OneTab] などの拡張を使うことでアクティブでないタブを停止・保存することができます。

==== ユーザーエージェント ====

Chromium の起動時に {{Ic|<nowiki>--user-agent="[string]"</nowiki>}} パラメータを指定することでユーザーエージェントは任意に変更することができます。

==== DOM Distiller ====

Chromium には Firefox にあるのと似たレンダリングモードが存在します。これは DOM Distiller と呼ばれ、[https://github.com/chromium/dom-distiller オープンソースプロジェクト]です。
デフォルトでは無効化されていますが、{{Ic|chrome://flags/#enable-reader-mode}} フラグを使用することにより有効化できます。このフラグは[[#フラグを永続化する|永続化]]させることができます。
DOM Distiller は、ページのコンテンツから不要なものを取り除くことでより良いレンダリングエクスペリエンスを提供するだけでなく、印刷用にページを単純化してくれます。後者のチェックボックスオプションが印刷ダイアログから削除されたものの、不要なものを取り除いたページを印刷することは依然として可能です。これらには、基本的には同じ効果があります。

フラグを有効化すると、ウェブサイトから不要なものを取り除くことができると Chromium が判断したときに、"Enter reader mode" メニューアイテムとアイコンがアドレスバーに出現します。

==== 特定の GPU の使用を強制する ====

GPU が複数ある環境の場合、Chromium はレンダリングに使用する GPU (ディスクリートや統合 GPU) を自動的に検出します。99% は問題ありませんが、誤った GPU が選択された場合 (VFIO GPU パススルー環境でディスクリートグラフィックが選ばれるなど)、{{ic|chrome://gpu}} は GPU プロセスを初期化できないというエラーを吐きます。同じページの '''Driver Information''' には複数の GPU が表示されます (GPU0, GPU1, ...)。ユーザーフレンドリな方法で GPU を切り替えることはできませんが、デバイス/ベンダー ID を使って Chromium のフラグで使用する GPU を設定できます:

$ chromium --gpu-testing-vendor-id=0x8086 --gpu-testing-device-id=0x1912

{{ic|0x8086}} と {{ic|0x1912}} は使用したい GPU の ID に置き換えてください ({{ic|chrome://gpu}} ページで確認できます)。

==== Firefox からブックマークをインポート ====

[[Firefox]] から Chromium にブックマークをインポートすることができます。

Chromium で {{ic|chrome://settings/importData}} を開いてください。

コンピュータに Firefox がインストールされている場合、直接 Firefox からブックマークなどをインポートできます。

'''Mozilla Firefox''' を選択してください。不要なアイテムのチェックは外してかまいません。'''Import''' をクリックしてから '''Done''' をクリックすればインポートは完了です。

{{note|Chromium でまだ何もブックマークを作成していない場合、ブックマークバーにブックマークが表示されます。既にブックマークが存在する場合、ブックマークは "Imported From Firefox" というラベルが付いた新しいフォルダに保存されます。}}

他の PC からブックマークをインポートする場合、先に Firefox からブックマークをエクスポートする必要があります。

Firefox で {{ic|Ctrl+Shift+o}} ''Import and Backup > Export Bookmarks To HTML'' を選択してください

後の作業は同じです。{{ic|chrome://settings/importData}} を開いてください。ただし今度は '''From''' ドロップダウンメニューで '''Bookmarks HTML File''' を選択して '''Choose File''' ボタンをクリックしてブックマークファイルをアップロードします。

後の作業は同じです。{{ic|chrome://settings/importData}} を開いてください。ただし今度は '''From''' ドロップダウンメニューで '''Bookmarks HTML File''' を選択して '''Choose File''' ボタンをクリックしてブックマークファイルをアップロードします。

==== ネイティブ通知の有効化 ====

{{ic|chrome://flags#enable-system-notifications}} を開いて、''Enabled'' を選択してください。

==== マウスの中ボタンでの自動スクロールを有効化する ====

自動スクロールはまだ試験的な機能です [https://niek.github.io/chrome-features/]。開発版ビルドでない Chromium または Chromium ベースのブラウザで、Linux 環境で動作させている場合は、デフォルトで無効化されています。[https://issues.chromium.org/issues/40811836]

この機能を有効化するには、ブラウザを {{ic|1=--enable-features=MiddleClickAutoscroll}} フラグで起動してください。このオプションを永続化させたい場合は、[[#フラグを永続化する]] を見てください。

{{Note|
* {{ic|--enable-blink-features}} は {{ic|--enable-features}} と同じように動作しますが、ブラウザが、このフラグはサポートされておらず、安定性とセキュリティが損なわれると警告を表示することがあります。
* 代替策として Chrome Web Store から似たような機能を持つ [https://chromewebstore.google.com/detail/wheely-wheel-scroll-for-l/kkmfljfnlmppiaoijkfaejgkhccokpdn WHEELY] のような拡張機能を追加することもできます。
}}

{{Tip|もう一つの手段は、{{AUR|chromium-extension-autoscroll}} です。しかし、このパッケージは古くなっており、公式ではないため、推奨されていません。使用する場合は注意してください。}}

==== U2F 認証 ====

{{Pkg|libfido2}} ライブラリをインストールしてください。このパッケージは、(通常) ユーザとして [[U2F]] キーにアクセスできるようにするために必要な udev ルールを提供します。
U2F キーはデフォルトでは root としてしかアクセスできないので、これらのルールが無いと Chromium はエラーを吐きます。

==== テーマ ====

Chromium に現在の GTK テーマをブラウザメニューやコントロールで使用させることができます。{{ic|chrome://settings/appearance}} で ''Use GTK'' を押してください。

==== ダークモード ====

Chromium 114 から、ユーザの優先外観を自動的に決定するために [[XDG デスクトップポータル]] が使用されるようになりました ([https://bugs.chromium.org/p/chromium/issues/detail?id=998903 issue])。よって、ダークモードの有効化とユーザの GTK テーマが切り離されました。この設定は、CSS、JavaScript、設定、そして Dev-Tools の ''prefers-color-scheme'' に適用されます。

優先外観を変更する方法は、XDG Desktop Portal バックエンドに依存します。例えば、多くのデスクトップ環境はそれぞれの外観設定インターフェイスにモードを切り替えるスイッチを提供しています。または、例えば {{Pkg|xdg-desktop-portal-gtk}} 場合は、以下のコマンドを使って優先モードを {{ic|prefer-light}} や {{ic|prefer-dark}}、{{ic|default}} に設定します:

$ dconf write /org/gnome/desktop/interface/color-scheme \'prefer-dark\'

{{Pkg|dbus}} の {{ic|dbus-send}} を使用することで、現在の優先外観をクエリできます ([https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Settings ドキュメント]):

$ dbus-send --session --print-reply=literal --dest=org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Settings.Read string:org.freedesktop.appearance string:color-scheme | tr -s ' ' | cut -d ' ' -f 5

* '''0''': 設定無し
* '''1''': ダークモードを優先
* '''2''': ライトモードを優先

===== Chromium 114 より前 =====

ダークモードを有効化し、ダークテーマ (通常、incognito モードで使用されます) を有効化するには、以下のフラグを[[#フラグを永続化する|永続的な設定]]に[[追加]]してください:

{{hc|1=~/.config/chromium-flags.conf|2=
--force-dark-mode
--enable-features=WebUIDarkMode
}}

==== サイドパネルを有効化する ====

サイドパネルは {{ic|chrome://flags}} から有効化できます。'''Side panel''' を有効化/無効化することができ、'''Side panel border''' や '''Side panel drag and drop''' といったオプションを変更できます。

=== プロファイルのメンテナンス ===

Chromium は [[Sqlite]] データベースを使用して履歴やお気に入りを管理しています。Sqlite データベースは使っているうちに断片化していきます。しかしながら、データベースをチェックしたり最適化するプロセスが存在しないため、断片化によって段々とパフォーマンスに影響が出て来ます。デフラグを行ってデータベースから未使用領域を削除することで、起動時間やブックマークや履歴に関連する作業を素早く実行することができます。

{{Pkg|profile-cleaner}} と {{AUR|browser-vacuum}} でメンテナンスができます。

=== セキュリティ ===

==== JIT を無効化 ====

[https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ JS エンジンにおけるセキュリティ上の脆弱性のうち約半分]は JIT に原因があります。パフォーマンスが劣化しますが、{{ic|1=--js-flags=--jitless}} フラグを使用することで、JavaScript からネイティブなコードへの just-in-time コンパイルを無効化できます。

==== WebRTC ====

WebRTC は JavaScript を使用する通信プロトコルですが、VPN を使っている場合でもマシンの IP アドレスやハードウェアのハッシュ値が漏洩する可能性があります。VPN ソフトウェアによってはスクリプトの実行が阻止されることもありますが、プロトコルを直接ブロックしてしまう方が安全です。2016年10月現在、デスクトップ版 Chromium で WebRTC を無効化する方法はありませんが、ローカル IP アドレスの漏洩を阻止する拡張が存在します。そのひとつがこの[https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia 拡張機能]です。

WebRTC は https://browserleaks.com/webrtc でテストできます。

{{Warning|IP の漏洩は防げても、Chromium はユニークなハッシュを送信しており、それを止める方法はありません。詳しくは https://www.browserleaks.com/webrtc#webrtc-disable を読んでください。}}

==== SSL 証明書 ====

Chromium には SSL 証明書マネージャが存在しません。Chromium は NSS の共有データベース {{ic|~/.pki/nssdb}} を使用しています。データベースに SSL 証明書を追加するには、シェルを使う必要があります。

===== 自己署名証明書の CAcert 証明書を追加 =====

CAcerts を取得して {{ic|nssdb}} を作成してください (存在しない場合)。作成するには {{Pkg|nss}} パッケージをインストールして以下を実行する必要があります:

$ mkdir -p $HOME/.pki/nssdb
$ cd $HOME/.pki/nssdb
$ certutil -N -d sql:.

$ curl -k -o "cacert-root.crt" "http://www.cacert.org/certs/root.crt"
$ curl -k -o "cacert-class3.crt" "http://www.cacert.org/certs/class3.crt"
$ certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "CAcert.org" -i cacert-root.crt
$ certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "CAcert.org Class 3" -i cacert-class3.crt

{{Note|データベースのパスワードを作成していない場合、作成する必要があります。}}

これでユーザーは手動で自己署名証明書をインポートできるようになります。

===== 例 1: シェルスクリプトを使って TomatoUSB から証明書を分離 =====

以下は証明書を展開してユーザーの {{ic|nssdb}} に追加するシンプルなスクリプトです:

#!/bin/sh
#
# usage: import-cert.sh remote.host.name [port]
#
REMHOST=$1
REMPORT=${2:-443}
exec 6>&1
exec > $REMHOST
echo | openssl s_client -connect ${REMHOST}:${REMPORT} 2>&1 |sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n "$REMHOST" -i $REMHOST
exec 1>&6 6>&-

使用方法はコメント化されている行を見てください。

参照:
*https://web.archive.org/web/20180718193807/https://blog.avirtualhome.com/adding-ssl-certificates-to-google-chrome-linux-ubuntu
*https://chromium.googlesource.com/chromium/src/+/master/docs/linux/cert_management.md

===== 例 2: Firefox を使って TomatoUSB から証明書を分離 =====

{{Pkg|firefox}} ブラウザを使って証明書をファイルに保存してデータベースに手動でインポートすることができます。

Firefox を使って:
#取得先の URL を開く。
#"This Connection is Untrusted" 警告画面が表示されたら ''I understand the Risks > Add Exception...'' をクリック。
#''View > Details > Export'' をクリックしてどこか一時的な場所に証明書を保存 (以下の例では {{ic|/tmp/easy.pem}} を使用)。

Chromium で使用する証明書をインポート:
$ certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "easy" -i /tmp/easy.pem

{{Note|名前は証明書にあわせて変更してください。上記の例では "easy" が証明書の名前です。}}

参照:
*https://sahissam.blogspot.com/2012/06/new-ssl-certificates-for-tomatousb-and.html

==== Canvas Fingerprinting ====

Canvas Fingerprinting は HTML5 の canvas のレンダリング結果の差異を使ってユーザーを識別する技術です。{{ic|--disable-reading-from-canvas}} フラグを使うことで Canvas Fingerprinting を使えないようにすることができます。

フラグが機能しているかどうか確認するには [https://panopticlick.eff.org こちらのテスト] を実行して "hash of canvas fingerprint" の結果を確認してください。

{{Note|1=<nowiki/>
* 一部の拡張機能は canvas からの読み込みを必要としており、{{ic|--disable-reading-from-canvas}} を設定すると壊れる場合があります。
* YouTube プレイヤーや Google マップは canvas からの読み込みができないと正しく動作しません ([https://github.com/qutebrowser/qutebrowser/issues/5345 Qutebrowser issue 5345]、[https://bbs.archlinux.org/viewtopic.php?id=255958 BBS#255958]、[https://bbs.archlinux.org/viewtopic.php?id=276425 BBS#276425] を参照)。
}}

==== プライバシー拡張 ====

[[ブラウザ拡張機能#プライバシー]] を参照してください。

{{Tip|あまりにも多くの拡張機能をインストールしてしまうと、ツールバーのスペースを圧迫してしまうかもしれません。ユーザと対話しない拡張機能は、拡張機能を右クリックして ''Hide in Chromium menu'' を選択することで隠すことができます。}}

==== Do Not Track ====

[[wikipedia:Do Not Track|Do Not Track]] を有効化するには、{{ic|chrome://settings}} を開き、''Advanced'' まで下へスクロールして、''Privacy and security'' の ''Send a "Do Not Track" request with your browsing traffic'' にチェックを入れてください。

==== 特定のパスワードストアを強制する ====

Chromium はパスワードストアを使ってパスワードと (cookie の値を暗号化するのに使われる) ''Chromium Safe Storage'' キーを保存します [https://codereview.chromium.org/24734007]。

デフォルトでは Chromium は使用するパスワードストアを自動的に認識しますが、デスクトップ環境やウィンドウマネージャを変えたときにパスワードと cookie が失われてしまう可能性があります。

{{ic|--password-store}} フラグで以下のどれかの値を指定して Chromium を起動することで特定のパスワードストアを強制的に使うようにすることができます [https://chromium.googlesource.com/chromium/src/+/master/docs/linux/password_storage.md]:

* {{ic|gnome-libsecret}} - [https://gitlab.gnome.org/GNOME/libsecret libsecret] 経由で [[Gnome Keyring]] を使用
* {{ic|kwallet5}} - [[KDE Wallet]] 5 を使用。
* {{ic|kwallet6}} - [[KDE Wallet]] 6 を使用。
* {{ic|basic}} - {{ic|Login Data}} ファイルにプレーンテキストとしてパスワードと cookie の暗号鍵を保存
* {{ic|detect}} - デフォルトの自動認識

例えば、Gnome Keyring を使うようにするには {{ic|1=--password-store=gnome-libsecret}} を付けてください。永続化する方法は [[#フラグを永続化する]] を参照。

他のデスクトップ環境のパスワードストアを使う場合、自動的にアンロックされるように設定すると良いでしょう。[[GNOME/Keyring#キーリングを使用する]] や [[KDE Wallet#ログイン時に KDE ウォレットを自動的にアンロック]] を参照。

==== ハイブリッドポスト量子鍵交換を有効化する ====

バージョン 155 から Chromium は、TLS 1.3 向けのハイブリッドポスト量子鍵交換 [https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html X25519Kyber768] をサポートしています [https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html]。この機能はデフォルトで無効化されていますが、{{Ic|chrome://flags/#enable-tls13-kyber}} フラグで有効化できます。

== トラブルシューティング ==

=== フォント ===

{{Note|Chromium は独自のサンドボックスを使っているため、fontconfig/GTK/Pango/X などと完全な統合がされていません。詳しくは [https://dev.chromium.org/developers/linux-technical-faq Linux Technical FAQ] を参照してください。}}

==== タブのフォントサイズが大きすぎる ====

[[GTK#設定]] で言及されているように、Chromium は GTK の設定を使用します。Chromium はタブに {{ic|gtk-font-name}} の設定を使用します (これにより、ウインドウのフォントサイズと合わなくなる場合があります)。この設定を上書きするには、{{ic|1=--force-device-scale-factor=1.0}} を使用してください。

Chrome Refresh 2023 がデフォルトになってから、Cantarell フォントを使用している GNOME で動かすとタブタイトル内の一部の文字 (小文字の g など) が切れてしまうことがあります。[https://issues.chromium.org/issues/40934082 chromium.org のイシュー]を参照してください。

この問題が解決するまでの回避策は、[[フォント設定#デフォルトまたは代替フォントを設定する]] に載っている設定を使って Cantarell から別のフォントに変えることです。例えば:

{{hc|~/.config/fontconfig/conf.d/10-chromium-font.conf|<nowiki>
<match target="pattern">
<test name="prgname" compare="eq">
<string>chromium</string>
</test>
<test qual="any" name="family">
<string>Cantarell</string>
</test>
<edit name="family" mode="assign" binding="strong">
<string>Ubuntu</string>
</edit>
</match>
</nowiki>}}

この設定は、プロセスの名前が {{ic|chromium}} にマッチする場合にのみ適用されます。Google Chrome に対しては {{ic|chrome}} としてください。

=== WebGL ===

使用中のグラフィックカードが Chromium のブラックリストに入っている可能性があります。[[#GPU アクセラレーションを強制する]] を見てください。

[[Bumblebee]] で Chromium を使っている場合、GPU のサンドボックスによって WebGL がクラッシュすることがあります。このようなときは、{{ic|optirun chromium --disable-gpu-sandbox}} で GPU のサンドボックスを無効にできます。

WebGL サポートのデバッグ情報は {{ic|chrome://gpu/}} を見てください。

Chromium はユーザプロファイルに GPU に関する誤った情報を保存することがあります。例えば、Optimus を使って Nvidia カードから Intel カードに切り替えた場合、たとえ Nvidia カードや primusrun/optirun を使用していなくても、{{ic|chrome://gpu}} に Nvidia カードが表示されます。異なるユーザデータディレクトリを使って実行することにより (例: {{ic|1=chromium --user-data-dir=$(mktemp -d)}})、この問題を解決できる場合があります。持続的な解決策として、{{ic|~/.config/chromium/Local\ State}} を削除して GPU の情報をリセットできます。

=== HiDPI の描画がおかしい ===

Chromium は自動的に [[HiDPI]] ディスプレイでの倍率設定を行います。しかし、これにより GUI の描画がおかしくなることがあります。

{{ic|1=--force-device-scale-factor=1}} フラグをを使用して、自動倍率設定を上書きできます。

[[#ネイティブ Wayland サポート|ネイティブの Wayland サポート]] が有効化されている場合、Chromium は、各モニタに設定された倍率を元に自動的に倍率を設定します。

=== GNOME Keyring を使用していると起動するたびにパスワードを要求される ===

[[GNOME/Keyring#パスワードが保存されない]] を見てください。

=== パスワードだけが同期されない ===

同期がパスワードに対してだけ機能しない場合 ({{ic|chrome://sync-internals/}} で確認できます)、プロファイルのログインデータを削除してください:

$ rm ~/.config/chromium/Default/Login\ Data*

詳細は [https://support.google.com/chrome/thread/9947763?hl=en&msgid=23687608 Google Chrome Help forum] を見てください。

=== デスクトップ環境を切り替えると cookie とパスワードが消える ===

Chromium を起動したときにターミナルに {{ic|Failed to decrypt token for service AccountId-*}} というメッセージが表示される場合、Chromium が間違ったパスワード保存バックエンドを使おうとしたのかもしれません。これはデスクトップ環境を切り替えたときに起こりえます。

[[#特定のパスワードストアを強制する]] を見てください。

=== Google Sync を有効化すると起動時に固まる ===

{{ic|1=--password-store=basic}} フラグを使うか、他の適切なパスワードストアを使って Chrome を起動してみてください。

[[#特定のパスワードストアを強制する]] を見てください。

=== デフォルトのブラウザとして設定するかを毎回尋ねてくる ===

KDE を使用していて、一度 Firefox を (Firefox 内のボタンをクリックして) デフォルトのブラウザとして設定したことがある場合、たとえ "デフォルトに設定" ボタンをクリックしたとしても、Chromium を起動するたびに毎回 Chromium をデフォルトのブラウザとして設定するかを尋ねられることがあります。

Chromium は {{ic|xdg-settings check default-web-browser chromium.desktop}} を実行することで chromium がデフォルトのブラウザであるかを確認します。そのコマンドの出力が "no" である場合、chromium がデフォルトのブラウザでないと認識します。{{ic|xdg-settings}} スクリプトは以下の MIME の関連付けを確認し、すべてが {{ic|chromium.desktop}} であることを期待します:

{{bc|
x-scheme-handler/http
x-scheme-handler/https
text/html}}

これを直すには、''システム設定 > アプリケーション > デフォルトのアプリケーション > Web browser'' を開いて、Chormium を指定してください。そして、{{ic|text/html}} の MIME の関連付けを設定してください:

$ xdg-mime default chromium.desktop text/html

最後に、[[XDG_MIME_Applications#新しい MIME タイプ|MIME のデータベースを更新]]してください:

$ update-mime-database ~/.local/share/mime

=== "このブラウザまたはアプリは安全でない可能性があります" Google へのログインエラー ===

2020年04月20日以降、Web 開発用に {{ic|1=--remote-debugging-port=9222}} フラグを指定して chromium を実行すると、 Google アカウントにログインできません。このフラグを一時的に無効にしてログインすると、再び有効にできます。

=== 60 FPS より高いリフレッシュレートのディスプレイを使用しているのに Chromium は 60 FPS で描画される ===

一般的な問題に関する上流のバグレポートは[https://bugs.chromium.org/p/chromium/issues/detail?id=1200167 ここ]にあり、その他の回避策が見つかるかもしれません。また、混合リフレッシュレートに関する問題は[https://bugs.chromium.org/p/chromium/issues/detail?id=1138080 ここ]で報告されています。

==== 混合リフレッシュレート ====

{{Tip|この問題は Wayland バックエンドには存在しない可能性があります。要検証。}}

混合リフレッシュレート (例えば 60 Hz と 144 Hz) のあるディスプレイを使用している場合、Chromium は最も低いリフレッシュレートのディスプレイに合わせて描画するかもしれません。

この問題に対する適切な回避策があります。以下のフラグを[[#フラグを永続化する|永続的な設定]]に[[追加]]してください:

{{hc|1=~/.config/chromium-flags.conf|2=
--use-gl=egl
--ignore-gpu-blocklist
--enable-gpu-rasterization
}}

これにより、コンポジタが 144 FPS でリフレッシュする場合、144Hz ディスプレイ上で使用すると Chromium が 144 FPS で実行されます。これにより、少しカクつくかもしれないことを留意してください {{Bug|67035}}。しかし、60 FPS で止まるよりはマシです。

==== Wayland バックエンドで実行する ====

この問題を引き起こす Wayland コンポジタ固有の問題があるようです。

特に、Plasma 5 は環境によらず 60Hz で描画されるようですが、Plasma 6 (この記事の時点では rc1) では Chromium が高いリフレッシュレートでも問題なく動作します。

その他の解決策がうまく行かなかった場合は、XWayland バックエンドに切り替えてみてください。

=== Chromium でスクロール速度が遅い ===

Chromium や Electron ベースのアプリケーションでマウスホイールのスクロールが遅すぎることがあります。以下にいくつか解決法を挙げます。

[[Libinput#マウスホイールのスクロール速度の調整]] では libinput の {{ic|libinput_event_pointer_get_axis_value}} 関数をインジェクトし、スケール係数を変更するインターフェイスを提供します。これはアプリケーションレベルのインジェクションではないので、アプリケーション固有のスケール係数調整用の追加スクリプトが必要です。Chromium の縦幅の小さい開発者ツールでは、スケール係数を十分大きくするとスクロールが速くなりすぎるかもしれないことに注意してください。

[[imwheel]] は X のホイールボタンのイベントを複数回リプレイすることでスクロールの距離を増やします。しかし、chromium は実際のスクロールとリプレイされたスクロールを2つのイベントとして認識します。これらの間には小さいですが感知できる遅延が存在します。なので、一回のマウスホイールスクロールで2回のページジャンプが発生します。タッチパッドのスクロールでも注意が必要です。

[https://chrome.google.com/webstore/detail/linux-scroll-speed-fix/mlboohjioameadaedfjcpemcaangkkbp Linux Scroll Speed Fix] と [https://chrome.google.com/webstore/detail/smoothscroll/nbokbjkabcmbfdlbddjidfmibcpneigj SmoothScroll] はスクロール距離の変更をサポートする chromium 拡張機能です。ウェブページ内でスクロールすると、現在フォーカスされているノードの最も近いスクロールできる祖先を見つけて、たとえその祖先が一番下までスクロールされていたとしても、その祖先に対してスクロールメソッドがピクセル距離を使って呼ばれます。なので、テキストエディタやスクロール可能な要素にスクロールすると、マウスを動かす以外の方法でその要素からスクロールして出ることはできません。また、拡張機能ベースの手段は Chromium 外では利用できません。

=== 動画がロードされるが再生されない ===

これは PulseAudio の問題である場合があります。[[PulseAudio/トラブルシューティング#ブラウザ (firefox) が動画をロードするが、再生しない]] で提案されている修正方法を確認してください。

=== データベースの破損によりパスワードが保存されない ===

パスワードデータベースは破損することがあり、その場合、再ビルドする必要があります。再ビルドすると、データベース内の全データが破壊され、保存されているパスワードは失われます。

ターミナルから Chromium を起動すると、以下のように出力されます:

[472531:472565:1207/055404.688559:ERROR:login_database.cc(1048)] Password decryption failed, encryption_result is 2

Chromium を終了し、3つのデータベースファイル ({{ic|~/.config/chromium/Default/Login Data*}}) を削除してください。

Chromium を再度起動すると、データベースファイルが再作成されるはずです。

=== KDE Wayland でカーソルが正しく描画されない ===

[[KDE#Plasma のカーソルがときどきおかしくなる]] を参照してください。

=== Wayland で Chromium のウィンドウが透明になる ===

ある[https://issues.chromium.org/issues/329678163 バグ]により、chromium 124 はコマンドラインフラグ {{ic|1=--ozone-platform=wayland}} を明示的に指定して起動する必要があります。

=== Wayland hardware acceleration buffer handle is null エラー ===

とある[https://issues.chromium.org/issues/331796411 バグ]により (特にハードウェアアクセラレーションが有効化されている場合)、ターミナルから起動した際に以下のような出力がログに現れることがあります:

{{bc|1=[333310:333425:0919/121130.103852:ERROR:gpu_channel.cc(502)] Buffer Handle is null.
[333341:18:0919/121130.104000:ERROR:shared_image_interface_proxy.cc(134)] Buffer handle is null. Not creating a mailbox from it.
[333310:333425:0919/121130.137149:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
}}

今のところの回避策は以下のフラグを使用することです:

{{hc|1=~/.config/chromium-flags.conf|2=
--disable-gpu-memory-buffer-video-frames
}}

=== サウンドサーバー無しだと音が出ない ===

Chromiumは[[Advanced_Linux_Sound_Architecture#ハードウェアを直接割り当てる]]をサポートしません。
等ページを見てミキシングの為のデバイス{{ic|pcm.dmixer}},{{ic|pcm.dsnooper}}を設定し、
{{ic|1=-alsa-output-device=pcm.dmixer -alsa-input-device=pcm.dsnooper}}フラグを使ってください。

== 参照 ==

* [https://www.chromium.org/ Chromium ホームページ]
* [https://chromereleases.googleblog.com/ Google Chrome リリースノート]
* [https://chrome.google.com/webstore/ Chrome ウェブストア]
* [[Wikipedia:Chromium (web browser)#Differences from Google Chrome|Chromium と Google Chrome の違い]]
* [https://peter.sh/experiments/chromium-command-line-switches/ Chromium コマンドラインスイッチのリスト]
* [[Profile-sync-daemon]] - Chromium プロファイルを tmpfs に保存し、ディスクと同期する systemd サービス
* [[Tmpfs]] - {{ic|/etc/fstab}} での tmpfs ファイルシステム
* [https://docs.kernel.org/filesystems/tmpfs.html 公式の tmpfs カーネルドキュメント]

{{TranslationStatus|Chromium|2025-03-08|827760}}

Advanced Linux Sound Architecture

2025-04-23T13:21:15Z

Oech3: 謎の空白を削除/* ハードウェアを直接割り当てる */

[[Category:サウンド]]
[[cs:Advanced Linux Sound Architecture]]
[[de:Alsa]]
[[en:Advanced Linux Sound Architecture]]
[[es:Advanced Linux Sound Architecture]]
[[fa:ALSA]]
[[fr:Alsa]]
[[he:Advanced Linux Sound Architecture]]
[[it:Advanced Linux Sound Architecture]]
[[nl:Advanced Linux Sound Architecture]]
[[pt:Advanced Linux Sound Architecture]]
[[ru:Advanced Linux Sound Architecture]]
[[sk:Advanced Linux Sound Architecture]]
[[th:Advanced Linux Sound Architecture]]
[[tr:Gelişmiş_ses_mimarisi_(ALSA)]]
[[zh-hans:Advanced Linux Sound Architecture]]
{{Related articles start}}
{{Related|Advanced Linux Sound Architecture/設定例}}
{{Related|Advanced Linux Sound Architecture/トラブルシューティング}}
{{Related|サウンドシステム}}
{{Related|PC スピーカーのビープ音の無効化}}
{{Related|PulseAudio}}
{{Related|Open Sound System}}
{{Related articles end}}
[[Wikipedia:ja:Advanced Linux Sound Architecture|Advanced Linux Sound Architecture]] ('''ALSA''') は、サウンドカードのデバイスドライバを提供する Open Sound System (OSSv3) を置き換えるために開発された Linux カーネルコンポーネントです。デバイスドライバの他に、'''ALSA''' は、カーネルドライバと直接やりとりせずに高レベルの API を使ってドライバ機能を使いたいという開発者のために、ユーザ空間のライブラリも提供しています。

==インストール==

ALSA はデフォルトの Arch カーネルにモジュールセットとして含まれているので、インストールは不要です。

起動時に自動で [[udev]] があなたのハードウェアを調べて、オーディオカード用の適切なカーネルモジュールをロードします。したがって、サウンドはすでに鳴らせるはずです。ただ、デフォルトでは全てのチャンネルはミュートにされています。[[#チャンネルのミュートを解除する|チャンネルのミュートを解除]]してください。

=== ユーザー権限 ===

通常、ローカルユーザーは音楽を再生したり、ミキサーレベルを変更する権限があります。

リモートユーザーが ALSA を使用できるようにするには、ユーザーを {{ic|audio}} グループに[[ユーザーとグループ#グループ管理|追加]]する必要があります。

{{Note|1={{ic|audio}} グループに含まれているユーザーは直接デバイスにアクセスできるので、アプリケーションから排他的にアウトプットしたり（ソフトウェアミキシングが破壊されます）、高速ユーザー切り替えや multiseat を破壊してしまうおそれがあります。よって、特に必要がないのならばユーザーを {{ic|audio}} グループに追加することは'''推奨されません'''[https://wiki.ubuntu.com/Audio/TheAudioGroup]。}}

===ALSA ユーティリティ===

{{Pkg|alsa-utils}} パッケージを[[インストール]]してください、サウンドデバイスをコンソールや端末から設定するための {{ic|alsamixer}} ユーザー空間ツールが含まれています。また、[[#高品質なリサンプリング|高品質なリサンプリング]]や[[#アップ・ダウンミキシング|アップ・ダウンミキシング]]などの高度な機能を使いたい場合は {{Pkg|alsa-plugins}} パッケージをインストールしてください。

===OSS との互換性===

{{Note|{{ic|/dev/dsp}} や {{ic|/dev/snd/seq}} が存在しないとアプリケーションがエラーを吐く場合は以下の設定が必要です。}}

ALSA には [[OSS]] のコールに介入して ALSA を使うようにさせる機能があります。このエミュレーションレイヤーは {{ic|/dev/dsp}} を開いて音声データを直接書き込むような古いアプリケーションで有用です。OSS やエミュレーションライブラリがないと、{{ic|/dev/dsp}} が見つからずにアプリケーションは音声を鳴らすことができません。

OSS アプリケーションに dmix (ソフトウェアミキシング) を扱わせたい場合は {{Pkg|alsa-oss}} パッケージをインストールして {{ic|snd-seq-oss}}, {{ic|snd-pcm-oss}}, {{ic|snd-mixer-oss}} [[カーネルモジュール]]をロードして OSS エミュレーションモジュールを有効にしてください。

=== PulseAudio との互換性 ===

{{AUR|apulse}} を使うことで [[PulseAudio]] にしか対応していないアプリケーションで ALSA を利用することができます。使用方法は {{ic|$ apulse ''yourapplication''}} とアプリケーションを起動するだけです。

===ALSA と systemd===
{{pkg|alsa-utils}} パッケージには、それぞれ起動時とシャットダウン時に動くように設定された {{ic|alsa-restore.service}} と {{ic|alsa-state.service}} が含まれています。

自動的にインストールされ有効化されるため、特に設定は必要ありません。{{ic|systemctl}} を使うことでステータスを確認できます。

{{Note|1=ALSA は設定を {{ic|/var/lib/alsa/asound.state}} に保存します。}}

=== ALSA ファームウェア ===

{{Pkg|alsa-firmware}} パッケージには特定のサウンドカードを使うのに必要なファームウェアが含まれています (例: Creative SB0400 Audigy2)。

==チャンネルのミュートを解除する==

現在のバージョンでは ALSA をインストールしたあと全てのチャンネルは'''デフォルトでミュートされています'''。手動でチャンネルをアンミュートする必要があります。

===amixer を使ってミュートを解除===

コマンドラインで {{ic|amixer}} を使うことでサウンドカードのマスターボリュームのミュートを解除できます:

$ amixer sset Master unmute

===alsamixer を使ってミュートを解除===

{{ic|alsamixer}} ncurses UI を使えば簡単にミュートを解除できます:

$ alsamixer

{{ic|alsamixer}} の、チャンネルの下の {{ic|MM}} ラベルはそのチャンネルがミュートになっていることを示しています。{{ic|00}} はミュートが解除されていることを示しています。

{{ic|←}} や {{ic|→}} キーを押して {{ic|Master}} や {{ic|PCM}} チャンネルに移動して {{ic|m}} キーを押してミュートを解除してください。{{ic|↑}} キーを押してボリュームを上げて値を {{ic|0}} dB ゲインにしてください。ゲインは左上の {{ic|項目:}} の隣に表示されます。

{{Note|ゲインを大きくしすぎると音にノイズが混じります。}}

=== 5.1/7.1 サウンドのミュートの解除 ===

5.1 または 7.1 サラウンドを鳴らしたいときは Front, Surround, Center, LFE (サブウーファー), Side などの他のチャンネルも同じようにミュートを解除してください（これらのチャンネル名は Intel HD Audio のものです、チャンネル名はハードウェアによって変わっているかもしれません）。

{{Note|ミュートを解除しただけではステレオ音源は自動でアップミキシングされません。[[#アップ・ダウンミキシング]] を見て下さい。}}

=== マイクの有効化 ===

マイクロフォンを有効にするには、Capture タブに {{ic|F4}} で切り替えてチャンネルを {{ic|Space}} で有効にしてください。マイクが使えない時は [[Advanced Linux Sound Architecture/トラブルシューティング#マイクロフォン]] を見て下さい。

=== テスト ===

次に、音が鳴るかテストしてみましょう:

$ speaker-test -c 2

{{ic|-c}} はスピーカーによって変えて下さい。例えば 7.1 では {{ic|-c 8}} を使います:

$ speaker-test -c 8

間違ったデバイスから音が出力される場合、{{ic|-D}} 引数を使って手動でデバイスを指定してみてください:

$ speaker-test -D default:PCH -c 8

{{ic|-D}} では PCM チャンネルの名前を値として指定できます。以下のコマンドで確認することができます:

{{hc|<nowiki>$ aplay -L | grep :CARD</nowiki>|2=
default:CARD=PCH # 'default:PCH' is the PCM channel name for -D
sysdefault:CARD=PCH
front:CARD=PCH,DEV=0
surround21:CARD=PCH,DEV=0
surround40:CARD=PCH,DEV=0
surround41:CARD=PCH,DEV=0
surround50:CARD=PCH,DEV=0
surround51:CARD=PCH,DEV=0
surround71:CARD=PCH,DEV=0
}}

音が出ない場合、[[#設定]]や [[Advanced Linux Sound Architecture/トラブルシューティング]]に進んで問題を解決してください。

===ノート===

* カードによってはアナログサウンドを聞くためにはデジタル出力をミュートする必要があります。Soundblaster Audigy LS では IEC958 チャンネルをミュートしてください。
* マシンによっては (Thinkpad T61 など)、Speaker チャンネルのミュートを解除する必要があります。
* マシンによっては (Dell E6400 など)、同じく {{ic|Front}} や {{ic|Headphone}} チャンネルのミュートを解除する必要があります。
* 再起動するとボリューム調整が元に戻ってしまう場合、root で alsamixer を実行してみて下さい。

==設定==

システムの設定ファイルは {{ic|/etc/asound.conf}} で、ユーザー別の設定ファイルは {{ic|~/.asoundrc}} です。

===デフォルトサウンドカードの設定===

起動毎にサウンドカードの順番が変わってしまうときは、{{ic|/etc/modprobe.d}} 内の {{ic|.conf}} で終わるファイル (例: {{ic|/etc/modprobe.d/alsa-base.conf}}) に順番を明記することができます。
例えば、mia サウンドカードを #0 にしたい場合は:

{{hc|/etc/modprobe.d/alsa-base.conf|2=<nowiki>
options snd slots=snd_mia,snd_hda_intel
options snd_mia index=0
options snd_hda_intel index=1
</nowiki>}}

{{ic|<nowiki>$ cat /proc/asound/modules</nowiki>}} を使ってロードされているサウンドモジュールとその順番を取得してください。{{ic|<nowiki>$ lsmod | grep snd</nowiki>}} を使ってデバイス・モジュールのリストを取得してください。この設定では {{ic|snd_mia}} を使うサウンドカードと {{ic|snd_hda_intel}} を使うサウンドカード (例: オンボード) を一枚づつ挿していると仮定しています。

index を {{ic|-2}} にすることで ALSA にカードを優先的に使わせないようにすることも可能です。Linux Mint や Ubuntu などのディストリビューションでは以下の設定を使うことで USB やその他の"一般的でない"ドライバに index {{ic|0}} を与えないようにしています:

{{hc|/etc/modprobe.d/alsa-base.conf|2=
options bt87x index=-2
options cx88_alsa index=-2
options saa7134-alsa index=-2
options snd-atiixp-modem index=-2
options snd-intel8x0m index=-2
options snd-via82xx-modem index=-2
options snd-usb-audio index=-2
options snd-usb-caiaq index=-2
options snd-usb-ua101 index=-2
options snd-usb-us122l index=-2
options snd-usb-usx2y index=-2
options snd-pcsp index=-2
options snd-usb-audio index=-2
}}

変更を反映させるには再起動する必要があります。

==== 環境変数を使ってデフォルト PCM を選択する ====

設定ファイルで、以下を追加してください:
pcm.!default {
type plug
slave.pcm {
@func getenv
vars [ ALSAPCM ]
default "hw:Audigy2"
}
}

default の行はあなたのカードの名前に置き換える必要があります (ここでは {{ic|Audigy2}} を例にしています)。{{ic|aplay -l}} で名前を取得することができ '''surround51''' のように PCM を使うことも可能です。ただしマイクロフォンを使う必要がある場合は full-duplex PCM をデフォルトにすると良いでしょう。

これで環境変数 {{ic|ALSAPCM}} を変更することでサウンドカードを選択できるようになります。カードを選択できない全てのプログラムで問題なく使えます。
例えば、'''mix51to20''' という名前の downmix PCM を書いたときは {{ic|mplayer}} を {{ic|ALSAPCM=mix51to20 mplayer example_6_channel.wav}} で使うことができます。

==== ハードウェアを直接割り当てる ====

{{Warning|この設定では他のアプリケーションからデバイスが使用不可能になります。この方法は、デジタル出力や音楽サーバーに捧げる場合など、わざとそうした場合にのみ推奨されます。サウンドサーバーや[[Advanced_Linux_Sound_Architecture#ミキシング|ミキシング]]無しの設定は[[Chromium]]等の幾つかのアプリケーションでサポートされていません。}}

まずデフォルトに設定したいカード・デバイスの id を {{ic|aplay -l}} で見つける必要があります:

{{hc|$ aplay -l|2=
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: CONEXANT Analog [CONEXANT Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: Conexant Digital [Conexant Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: JamLab [JamLab], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: Audio [Altec Lansing XT1 - USB Audio], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
}}

例えば、このリストの最後のエントリはカード ID 2,カード名 Audio でデバイス ID 0 です。このカードをデフォルトにするには、システム全体のファイル {{ic|/etc/asound.conf}} かユーザー定義ファイル {{ic|~/.asoundrc}} のどちらかを使ってください。ファイルが存在しないときは作成する必要があります。そして以下のオプションを適切なカード・デバイス id を使って挿入して下さい。

{{bc|
pcm.!default {
type hw
card Audio #又はcard 2
}

ctl.!default {
type hw
card Audio
}

pcm.dmixer {
type dmix
ipc_key 2048
slave {
pcm "hw:Audio"
}
}
pcm.dsnooper {
type dsnoop
ipc_key 2048
slave {
pcm "hw:Audio"
}
}
}}

カードIDではなくカード名の使用をおすすめします。デバイスの順番に依存しないためです。

{{ic|pcm.dmixer}}と{{ic|pcm.dsnooper}}は[[Advanced_Linux_Sound_Architecture#ミキシング|ミキシング]]が必要なアプリケーションの為の予備です。
{{Accuracy|General method to select alsa device should be introduced such as environment value.}}
例えば、{{ic|1=chromium -alsa-output-device=pcm.dmixer -alsa-input-device=pcm.dsnooper}}でChromiumがミキシングを使えるようになります。

{{Note|Asus U32U シリーズではカードの pcm と ctl の両方を 1 に設定する必要があります。}}

'pcm' オプションは音声の再生で使われるカード・デバイスに影響を与え、'ctl' オプションは alsamixer などのコントロールユーティリティで使われるカードに影響を与えます。

アプリケーション (mplayer など) を（再）起動すれば変更はすぐ適用されます。また、''aplay'' などのコマンドを使ってテストすることが可能です。

$ aplay -D default:PCH ''your_favourite_sound.wav''

asound 設定に関するエラーが表示される場合は、[http://www.alsa-project.org/main/index.php/Asoundrc#The_default_plugin 上流のドキュメント] を確認して設定ファイルフォーマットの変更を確認してください。

===サウンドモジュールがロードされていることを確かめる===

udev が正しくサウンドカードを検知しているかチェックするには次のコマンドを実行してください:

{{hc|<nowiki>$ lsmod | grep '^snd' | column -t</nowiki>|<nowiki>
snd_hda_codec_hdmi 22378 4
snd_hda_codec_realtek 294191 1
snd_hda_intel 21738 1
snd_hda_codec 73739 3 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel
snd_hwdep 6134 1 snd_hda_codec
snd_pcm 71032 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_timer 18992 1 snd_pcm
snd 55132 9 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer
snd_page_alloc 7017 2 snd_hda_intel,snd_pcm
</nowiki>}}

出力が上と同じようになっていれば、サウンドドライバが首尾よく自動検出されています。
{{Note|{{ic|udev>=171}} から、OSS エミュレーションモジュール ({{ic|snd_seq_oss, snd_pcm_oss, snd_mixer_oss}}) はデフォルトではロードされないようになりました: 必要ならば[[カーネルモジュール#ロード|手動でロードしてください]]。}}

{{ic|/dev/snd/}} ディレクトリにデバイスファイルがあるか調べてもいいかもしれません:

{{hc|$ ls -l /dev/snd|2=<nowiki>
total 0
crw-rw---- 1 root audio 116, 0 Apr 8 14:17 controlC0
crw-rw---- 1 root audio 116, 32 Apr 8 14:17 controlC1
crw-rw---- 1 root audio 116, 24 Apr 8 14:17 pcmC0D0c
crw-rw---- 1 root audio 116, 16 Apr 8 14:17 pcmC0D0p
crw-rw---- 1 root audio 116, 25 Apr 8 14:17 pcmC0D1c
crw-rw---- 1 root audio 116, 56 Apr 8 14:17 pcmC1D0c
crw-rw---- 1 root audio 116, 48 Apr 8 14:17 pcmC1D0p
crw-rw---- 1 root audio 116, 1 Apr 8 14:17 seq
crw-rw---- 1 root audio 116, 33 Apr 8 14:17 timer
</nowiki>}}

{{Note|IRC やフォーラムで助けを求める時は、上記のコマンドの出力を貼って下さい。}}

とにかく '''controlC0''' や '''pcmC0D0p''' のようなデバイスがあれば、サウンドモジュールが正しくロードされていることを示しています。

そうなってないのなら、あなたのサウンドモジュールは正しく検出されていません。これを解決するには、手動でモジュールのロードを試して下さい:

* サウンドカードのモジュールを確認します: [http://www.alsa-project.org/main/index.php/Matrix:Main ALSA Soundcard Matrix] モジュールには名前の前に 'snd-' が付きます (例: {{ic|snd-via82xx}})。
* [[カーネルモジュール#ロード|モジュールをロードします]]。
* {{ic|/dev/snd}} の中のデバイスファイルを確認したり（上述）、{{ic|alsamixer}} や {{ic|amixer}} に変化がないか調べて下さい。
* {{ic|snd-NAME-OF-MODULE}} と {{ic|snd-pcm-oss}} を[[カーネルモジュール#ロード|起動時にロード]]するよう設定して下さい。

===S/PDIF 出力===

[[wikipedia:ja:S/PDIF|S/PDIF]] はコンピュータとオーディオアンプを接続するときにしばしば使われるデジタルオーディオインターフェイスです (5.1/7.1 サラウンドのホームシアターなど)。
{{note|サウンドカードによっては以下の瀬底でアナログ出力が無効になることがあります (例: Sound Blaster Audigy 2)。}}
使用している[[シェル]]にあわせて、シェルの設定ファイルに以下の行を追加してください:
amixer -c 0 cset name='IEC958 Playback Switch' on

カードのデジタル出力の名前は以下のコマンドで確認できます:
$ amixer scontrols

===イコライザー===

====AlsaEqual を使う (UI あり)====

{{AUR|alsaequal}} パッケージをインストールしてください。

パッケージをインストールした後、以下を ALSA 設定ファイル ({{ic|~/.asoundrc}} か {{ic|/etc/asound.conf}}) に挿入してください:

ctl.equal {
type equal;
}

pcm.plugequal {
type equal;
# Modify the line below if you do not
# want to use sound card 0.
#slave.pcm "plughw:0,0";
#by default we want to play from more sources at time:
slave.pcm "plug:dmix";
}
#pcm.equal {
# If you do not want the equalizer to be your
# default soundcard comment the following
# line and uncomment the above line. (You can
# choose it as the output device by addressing
# it with specific apps,eg mpg123 -a equal 06.Back_In_Black.mp3)
pcm.!default {
type plug;
slave.pcm plugequal;
}

x86_64 環境で {{Pkg|lib32-flashplugin}}{{Broken package link|{{aur-mirror|lib32-flashplugin}}}} を使用している場合、上記の設定では flash で音が鳴りません。以下の設定で flash の音を有効にできますが、{{ic|pcm "hw:0,0"}} の行でサウンドカードを手動で指定する必要があります (利用可能なサウンドカードとカードのデバイス番号は {{ic|aplay -l}} で確認できます):

{{hc|/etc/asound.conf|2=
pcm.dmixer {
type dmix
ipc_key 2048
slave {
pcm "hw:0,0"
buffer_size 16384
}
}

ctl.equal {
type equal;
}

pcm.equalizer {
type equal
slave.pcm "plug:dmixer"
}

pcm.!default {
type plug
slave.pcm equalizer
}
}}

次のコマンドを使ってイコライザーを変更することができます:
$ alsamixer -D equal

設定ファイルはユーザーごとに違うので注意してください。{{ic|~/.alsaequal.bin}}　に保存されます。
AlsaEqual を異なるユーザーの [[Music Player Daemon|mpd]] などのソフトウェアで使いたいときは、次を実行することで設定できます:
# su mpd -c 'alsamixer -D equal'
もしくは、ユーザーの home にある {{ic|.alsaequal.bin}} のシンボリックリンクを作って下さい。

=====AlsaEqual の管理=====

{{AUR|alsaequal-mgr}} パッケージをインストールしてください。

通常通りイコライザーを設定してください:
$ alsamixer -D equal

状態に満足したら、名前を付けて保存してください (例: "foo"):
$ alsaequal-mgr save foo

イコライザーの状態 "foo" は次のコマンドで戻すことができます:
$ alsaequal-mgr load foo

ゲームや映画、音楽のジャンル別、VoIP アプリなどそれぞれに合わせてイコライザーの状態を作成し、必要なときにリロードできます。

オプションの詳細は [https://xyne.archlinux.ca/projects/alsaequal-mgr/ project page] を見て下さい。

====mbeq を使う====

{{Note|この方法では ladspa プラグインを使う必要があります。サウンドを再生する際に CPU の使用量が多めです。さらに、ステレオサウンドを念頭に置いて作成されています (例: ヘッドフォン)。}}

{{Pkg|alsa-plugins}}, {{Pkg|ladspa}}, {{Pkg|swh-plugins}} パッケージをインストールしてください。

まだ {{ic|~/.asoundrc}} か {{ic|/etc/asound.conf}} ファイルを作成していない場合は、どちらかを作成して以下を挿入して下さい:

{{hc|/etc/asound.conf|2=<nowiki>pcm.eq {
type ladspa

# The output from the EQ can either go direct to a hardware device
# (if you have a hardware mixer, e.g. SBLive/Audigy) or it can go
# to the software mixer shown here.
#slave.pcm "plughw:0,0"
slave.pcm "plug:dmix"

# Sometimes you may need to specify the path to the plugins,
# especially if you have just installed them. Once you have logged
# out/restarted this should not be necessary, but if you get errors
# about being unable to find plugins, try uncommenting this.
#path "/usr/lib/ladspa"

plugins [
{
label mbeq
id 1197
input {
#this setting is here by example, edit to your own taste
#bands: 50hz, 100hz, 156hz, 220hz, 311hz, 440hz, 622hz, 880hz, 1250hz, 1750hz, 25000hz,
#50000hz, 10000hz, 20000hz
controls [ -5 -5 -5 -5 -5 -10 -20 -15 -10 -10 -10 -10 -10 -3 -2 ]
}
}
]
}

# Redirect the default device to go via the EQ - you may want to do
# this last, once you are sure everything is working. Otherwise all
# your audio programs will break/crash if something has gone wrong.

pcm.!default {
type plug
slave.pcm "eq"
}

# Redirect the OSS emulation through the EQ too (when programs are running through "aoss")

pcm.dsp0 {
type plug
slave.pcm "eq"
}
</nowiki>}}

==高品質なリサンプリング==

ソフトウェアミキシングが有効になっていると、ALSA は全てを同じ周波数 (デフォルトで 48000) にリサンプリングします。dmix はサウンドの品質を落としてしまう低品質リサンプリングアルゴリズムを使っています。

{{pkg|alsa-plugins}} と {{pkg|libsamplerate}} をインストールして下さい。

デフォルトの変換器を libsamplerate に変更します:

{{hc|/etc/asound.conf|defaults.pcm.rate_converter "samplerate_best"}}

または:

{{hc|~/.asoundrc|defaults.pcm.rate_converter "samplerate_best"}}

'''samplerate_best''' は最高のサウンド品質を提供しますが、リアルタイムサンプリングをするには CPU サイクルが大量に必要になるので使うにはそこそこの CPU が必須です。また、dmix の設定で buffer_size を基本の 4096 から 8192 か 16384 に調整する必要もあるかもしれません。他のアルゴリズム ('''samplerate''' など) も利用できますがデフォルトのリサンプラーに比べておそらくあまり改善はないでしょう。

{{Warning|環境によっては、samplerate_best を有効にすると flashplayer でサウンドが出力されなくなるという問題が発生します。}}

==アップ・ダウンミキシング==

===アップミキシング===

音楽などのステレオ音源を 5.1 や 7.1 サウンドシステムをフルに使って再生するには、アップミキシングを使う必要があります。黎明期ではこれをするのはとても難しいものでした。ですが現在では簡単にアップミキシングができるプラグインがあります。{{Pkg|alsa-plugins}} に含まれている {{ic|upmix}} プラグインを使います。

それから以下を ALSA 設定ファイル ({{ic|/etc/asound.conf}} か {{ic|~/.asoundrc}}) に追加してください:
pcm.upmix71 {
type upmix
slave.pcm "surround71"
delay 15
channels 8
}

上の例は 7.1 のものですが 5.1 や 4.0 にも簡単に変えられます。

設定をするとアップミキシングに使う新しい pcm が加わります。全てのサウンド音源をこの pcm に通したい時は、次のようにデフォルトとして追加してください:

pcm.!default "plug:upmix71"

このプラグインは使うにあたって特に設定を変える必要はありません。
プラグインが動作しないときは、以下のようにしてアップミキシングする PCM のための dmixer を自分で設定してください:
pcm.dmix6 {
type asym
playback.pcm {
type dmix
ipc_key 567829
slave {
pcm "hw:0,0"
channels 6
}
}
}

そして "surround71" のかわりに "dmix6" を使って下さい。
音がスキップしたり歪むときは、buffer_size を増やす (例: 32768) か [[#高品質なリサンプリング|高品質リサンプラー]]を使ってください。

===ダウンミキシング===
5.1 サウンドの映画をステレオシステムで視聴するときなど、音源をステレオにダウンミキシングしたい場合、{{Pkg|alsa-plugins}} に含まれている {{ic|vdownmix}} プラグインを使って下さい。

設定ファイルに以下を追加して下さい:

pcm.!surround51 {
type vdownmix
slave.pcm "default"
}
pcm.!surround40 {
type vdownmix
slave.pcm "default"
}

{{Note|1=これだけではダウンミキシングが動作しないかもしれません、[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541786] を参照してください。その場合、{{ic|pcm.!default "plug:surround51"}} か {{ic|pcm.!default "plug:surround40"}} を追加する必要があります。{{ic|vdownmix}} プラグはひとつだけ使うことができます; 7.1 チャンネルのときは、上の設定の代わりに {{ic|surround71}} を使って下さい。{{ic|vdownmix}} と {{ic|dmix}} の両方を動かす設定例が[https://bbs.archlinux.org/viewtopic.php?id=167275 ここ]にあります。}}

==ミキシング==

ミキシングを使うことで複数のアプリケーションが同時に音を出力することが可能になります。外付けのサウンドカードはほとんどの場合ハードウェアミキシングをサポートしており、可能であればデフォルトで有効にされます。内蔵のマザーボードに載っているサウンドカード (Intel HD Audio など) は基本的にハードウェアミキシングをサポートしていません。そのようなカードでは、dmix という名前の ALSA プラグインを使ってソフトウェアミキシングを利用します。この機能はハードウェアミキシングが使えない場合に自動で有効にされます。

===手動で dmix を有効にする===

{{Note|ALSA 1.0.9rc2 以上ではアナログサウンドに dmix を設定する必要はありません。ハードウェアミキシングをサポートしていないサウンドカードのために Dmix はデフォルトで有効にされています。}}

ソフトウェアミキシングが動作しない場合は、あなたの home フォルダに以下の内容で .asoundrc ファイルを作成してください。

pcm.dsp {
type plug
slave.pcm "dmix"
}

これでソフトウェアミキシングが有効になり複数のアプリケーションがサウンドカードを使えるようになるはずです。使えない場合は、{{ic|/etc/asound.conf}} の中身を全て上のように置き換えてみて下さい。

S/PDIF などのデジタル音声出力をするために、ALSA パッケージは依然として dmix をデフォルトで有効にしていません。そのため、上の dmix 設定は S/PDIF デバイスで dmix を有効にするために使うことはできません。

一般的な問題と解決方法は [[Advanced Linux Sound Architecture/トラブルシューティング]] を見て下さい。

===ハードウェアミキシング===

====サポート====

ハードウェアでミキシングをサポートしているオーディオチップセットを持っている場合、設定は必要ありません。ほとんど全てのオンボード・オーディオチップセットはハードウェアミキシングをサポートしていないので、ソフトウェアでミキシングする必要があります（上述）。ハードウェアミキシングをサポートしているサウンドカードは少なく、Linux でサポートされているサウンドカードは以下になります:

* Creative SoundBlaster Live! (5.1 モデル)
* Creative SoundBlaster Audigy (複数)
* Creative SoundBlaster Audidy 2 (ZS モデル)
* Creative SoundBlaster Audigy 4 (Pro モデル)

{{Note|
* 上記のカードのローエンド版 (Audigy SE, Audigy 2 NX, SoundBlaster Live! 24bit, SoundBlaster Live! 7.1) は別のチップを使っているためハードウェアミキシングに対応していません。
* オンボードの VIA8237 チップは4ストリームのハードウェアミキシングに対応していますが、マザーボードによってはそれが3ストリームになったり (4番目のストリームが音を出さない) あるいは使えないこともあります。動作したとしても、他の方法と比べて音質は劣ります。}}

====フィックス====

64-bit Arch で Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02) を使っている場合、Enemy Territory でサウンドを鳴らすには以下を実行して下さい:
echo "et.x86 0 0 direct" > /proc/asound/card0/pcm0p/oss
echo "et.x86 0 0 disable" > /proc/asound/card0/pcm0c/oss

== ヒントとテクニック ==

=== USB サウンドカードのホットプラグ ===

USB サウンドカードが挿入されたときに、自動的に第一のアウトプットデバイスにするために、以下の udev ルールを使うことができます (例: 以下の2行を {{ic|/etc/udev/rules.d/00-local.rules}} に追加して再起動する)。

{{bc|1=KERNEL=="pcmC[D0-9cp]*", ACTION=="add", PROGRAM="/bin/sh -c 'K=%k; K=$${K#pcmC}; K=$${K%%D*}; echo defaults.ctl.card $$K > /etc/asound.conf; echo defaults.pcm.card $$K >>/etc/asound.conf'"
KERNEL=="pcmC[D0-9cp]*", ACTION=="remove", PROGRAM="/bin/sh -c 'echo defaults.ctl.card 0 > /etc/asound.conf; echo defaults.pcm.card 0 >>/etc/asound.conf'"}}

=== 同時出力 ===

ミニジャックで接続した外付けスピーカーと内蔵のスピーカーで同時に音楽を再生したい場合、{{ic|alsamixer}} や {{ic|amixer}} を使うことで ''Auto-Mute'' のミュートを解除してください:
$ amixer sset "Auto-Mute" unmute

そして ''Headphones''', ''Speaker'', '''Bass Speaker'' など他の必要なアイテムのミュートを解除してください。
{{Note|(ミニジャック) ヘッドフォンコネクタで接続した場合に音が割れる場合、[[Advanced Linux Sound Architecture/トラブルシューティング#ミニジャック (ヘッドフォンコネクタ) で音が割れる]]を見て下さい。}}

=== キーボードのボリュームコントロール ===

以下のコマンドをボリュームキーにマッピングしてください: {{ic|XF86AudioRaiseVolume}}, {{ic|XF86AudioLowerVolume}}, {{ic|XF86AudioMute}}

ボリュームを上げるには:
amixer set Master 5%+

ボリュームを下げるには:
amixer set Master 5%-

==トラブルシューティング==
[[Advanced Linux Sound Architecture/トラブルシューティング]]を見て下さい。

==設定例==

[[Advanced Linux Sound Architecture/設定例]]を見て下さい。

==参照==
* [http://www.alsa-project.org/ ALSA wiki]
* [http://www.alsa-project.org/main/index.php/Asoundrc Asoundrc]
* [http://alsa.opensrc.org/ 非公式 ALSA wiki]
* [https://www.mjmwired.net/kernel/Documentation/sound/alsa/ALSA-Configuration.txt 高度な ALSA モジュール設定]
* [https://bbs.archlinux.org/viewtopic.php?id=36815 HOWTO: compile driver from svn]
* [http://www.volkerschatz.com/noise/alsa.html A close look at ALSA: ALSA concept introduction]
* [http://www.sabi.co.uk/Notes/linuxSoundALSA.html Linux ALSA sound notes]

Advanced Linux Sound Architecture

2025-04-23T13:20:15Z

Oech3: dsnoopデバイスを追加/* ハードウェアを直接割り当てる */

[[Category:サウンド]]
[[cs:Advanced Linux Sound Architecture]]
[[de:Alsa]]
[[en:Advanced Linux Sound Architecture]]
[[es:Advanced Linux Sound Architecture]]
[[fa:ALSA]]
[[fr:Alsa]]
[[he:Advanced Linux Sound Architecture]]
[[it:Advanced Linux Sound Architecture]]
[[nl:Advanced Linux Sound Architecture]]
[[pt:Advanced Linux Sound Architecture]]
[[ru:Advanced Linux Sound Architecture]]
[[sk:Advanced Linux Sound Architecture]]
[[th:Advanced Linux Sound Architecture]]
[[tr:Gelişmiş_ses_mimarisi_(ALSA)]]
[[zh-hans:Advanced Linux Sound Architecture]]
{{Related articles start}}
{{Related|Advanced Linux Sound Architecture/設定例}}
{{Related|Advanced Linux Sound Architecture/トラブルシューティング}}
{{Related|サウンドシステム}}
{{Related|PC スピーカーのビープ音の無効化}}
{{Related|PulseAudio}}
{{Related|Open Sound System}}
{{Related articles end}}
[[Wikipedia:ja:Advanced Linux Sound Architecture|Advanced Linux Sound Architecture]] ('''ALSA''') は、サウンドカードのデバイスドライバを提供する Open Sound System (OSSv3) を置き換えるために開発された Linux カーネルコンポーネントです。デバイスドライバの他に、'''ALSA''' は、カーネルドライバと直接やりとりせずに高レベルの API を使ってドライバ機能を使いたいという開発者のために、ユーザ空間のライブラリも提供しています。

==インストール==

ALSA はデフォルトの Arch カーネルにモジュールセットとして含まれているので、インストールは不要です。

起動時に自動で [[udev]] があなたのハードウェアを調べて、オーディオカード用の適切なカーネルモジュールをロードします。したがって、サウンドはすでに鳴らせるはずです。ただ、デフォルトでは全てのチャンネルはミュートにされています。[[#チャンネルのミュートを解除する|チャンネルのミュートを解除]]してください。

=== ユーザー権限 ===

通常、ローカルユーザーは音楽を再生したり、ミキサーレベルを変更する権限があります。

リモートユーザーが ALSA を使用できるようにするには、ユーザーを {{ic|audio}} グループに[[ユーザーとグループ#グループ管理|追加]]する必要があります。

{{Note|1={{ic|audio}} グループに含まれているユーザーは直接デバイスにアクセスできるので、アプリケーションから排他的にアウトプットしたり（ソフトウェアミキシングが破壊されます）、高速ユーザー切り替えや multiseat を破壊してしまうおそれがあります。よって、特に必要がないのならばユーザーを {{ic|audio}} グループに追加することは'''推奨されません'''[https://wiki.ubuntu.com/Audio/TheAudioGroup]。}}

===ALSA ユーティリティ===

{{Pkg|alsa-utils}} パッケージを[[インストール]]してください、サウンドデバイスをコンソールや端末から設定するための {{ic|alsamixer}} ユーザー空間ツールが含まれています。また、[[#高品質なリサンプリング|高品質なリサンプリング]]や[[#アップ・ダウンミキシング|アップ・ダウンミキシング]]などの高度な機能を使いたい場合は {{Pkg|alsa-plugins}} パッケージをインストールしてください。

===OSS との互換性===

{{Note|{{ic|/dev/dsp}} や {{ic|/dev/snd/seq}} が存在しないとアプリケーションがエラーを吐く場合は以下の設定が必要です。}}

ALSA には [[OSS]] のコールに介入して ALSA を使うようにさせる機能があります。このエミュレーションレイヤーは {{ic|/dev/dsp}} を開いて音声データを直接書き込むような古いアプリケーションで有用です。OSS やエミュレーションライブラリがないと、{{ic|/dev/dsp}} が見つからずにアプリケーションは音声を鳴らすことができません。

OSS アプリケーションに dmix (ソフトウェアミキシング) を扱わせたい場合は {{Pkg|alsa-oss}} パッケージをインストールして {{ic|snd-seq-oss}}, {{ic|snd-pcm-oss}}, {{ic|snd-mixer-oss}} [[カーネルモジュール]]をロードして OSS エミュレーションモジュールを有効にしてください。

=== PulseAudio との互換性 ===

{{AUR|apulse}} を使うことで [[PulseAudio]] にしか対応していないアプリケーションで ALSA を利用することができます。使用方法は {{ic|$ apulse ''yourapplication''}} とアプリケーションを起動するだけです。

===ALSA と systemd===
{{pkg|alsa-utils}} パッケージには、それぞれ起動時とシャットダウン時に動くように設定された {{ic|alsa-restore.service}} と {{ic|alsa-state.service}} が含まれています。

自動的にインストールされ有効化されるため、特に設定は必要ありません。{{ic|systemctl}} を使うことでステータスを確認できます。

{{Note|1=ALSA は設定を {{ic|/var/lib/alsa/asound.state}} に保存します。}}

=== ALSA ファームウェア ===

{{Pkg|alsa-firmware}} パッケージには特定のサウンドカードを使うのに必要なファームウェアが含まれています (例: Creative SB0400 Audigy2)。

==チャンネルのミュートを解除する==

現在のバージョンでは ALSA をインストールしたあと全てのチャンネルは'''デフォルトでミュートされています'''。手動でチャンネルをアンミュートする必要があります。

===amixer を使ってミュートを解除===

コマンドラインで {{ic|amixer}} を使うことでサウンドカードのマスターボリュームのミュートを解除できます:

$ amixer sset Master unmute

===alsamixer を使ってミュートを解除===

{{ic|alsamixer}} ncurses UI を使えば簡単にミュートを解除できます:

$ alsamixer

{{ic|alsamixer}} の、チャンネルの下の {{ic|MM}} ラベルはそのチャンネルがミュートになっていることを示しています。{{ic|00}} はミュートが解除されていることを示しています。

{{ic|←}} や {{ic|→}} キーを押して {{ic|Master}} や {{ic|PCM}} チャンネルに移動して {{ic|m}} キーを押してミュートを解除してください。{{ic|↑}} キーを押してボリュームを上げて値を {{ic|0}} dB ゲインにしてください。ゲインは左上の {{ic|項目:}} の隣に表示されます。

{{Note|ゲインを大きくしすぎると音にノイズが混じります。}}

=== 5.1/7.1 サウンドのミュートの解除 ===

5.1 または 7.1 サラウンドを鳴らしたいときは Front, Surround, Center, LFE (サブウーファー), Side などの他のチャンネルも同じようにミュートを解除してください（これらのチャンネル名は Intel HD Audio のものです、チャンネル名はハードウェアによって変わっているかもしれません）。

{{Note|ミュートを解除しただけではステレオ音源は自動でアップミキシングされません。[[#アップ・ダウンミキシング]] を見て下さい。}}

=== マイクの有効化 ===

マイクロフォンを有効にするには、Capture タブに {{ic|F4}} で切り替えてチャンネルを {{ic|Space}} で有効にしてください。マイクが使えない時は [[Advanced Linux Sound Architecture/トラブルシューティング#マイクロフォン]] を見て下さい。

=== テスト ===

次に、音が鳴るかテストしてみましょう:

$ speaker-test -c 2

{{ic|-c}} はスピーカーによって変えて下さい。例えば 7.1 では {{ic|-c 8}} を使います:

$ speaker-test -c 8

間違ったデバイスから音が出力される場合、{{ic|-D}} 引数を使って手動でデバイスを指定してみてください:

$ speaker-test -D default:PCH -c 8

{{ic|-D}} では PCM チャンネルの名前を値として指定できます。以下のコマンドで確認することができます:

{{hc|<nowiki>$ aplay -L | grep :CARD</nowiki>|2=
default:CARD=PCH # 'default:PCH' is the PCM channel name for -D
sysdefault:CARD=PCH
front:CARD=PCH,DEV=0
surround21:CARD=PCH,DEV=0
surround40:CARD=PCH,DEV=0
surround41:CARD=PCH,DEV=0
surround50:CARD=PCH,DEV=0
surround51:CARD=PCH,DEV=0
surround71:CARD=PCH,DEV=0
}}

音が出ない場合、[[#設定]]や [[Advanced Linux Sound Architecture/トラブルシューティング]]に進んで問題を解決してください。

===ノート===

* カードによってはアナログサウンドを聞くためにはデジタル出力をミュートする必要があります。Soundblaster Audigy LS では IEC958 チャンネルをミュートしてください。
* マシンによっては (Thinkpad T61 など)、Speaker チャンネルのミュートを解除する必要があります。
* マシンによっては (Dell E6400 など)、同じく {{ic|Front}} や {{ic|Headphone}} チャンネルのミュートを解除する必要があります。
* 再起動するとボリューム調整が元に戻ってしまう場合、root で alsamixer を実行してみて下さい。

==設定==

システムの設定ファイルは {{ic|/etc/asound.conf}} で、ユーザー別の設定ファイルは {{ic|~/.asoundrc}} です。

===デフォルトサウンドカードの設定===

起動毎にサウンドカードの順番が変わってしまうときは、{{ic|/etc/modprobe.d}} 内の {{ic|.conf}} で終わるファイル (例: {{ic|/etc/modprobe.d/alsa-base.conf}}) に順番を明記することができます。
例えば、mia サウンドカードを #0 にしたい場合は:

{{hc|/etc/modprobe.d/alsa-base.conf|2=<nowiki>
options snd slots=snd_mia,snd_hda_intel
options snd_mia index=0
options snd_hda_intel index=1
</nowiki>}}

{{ic|<nowiki>$ cat /proc/asound/modules</nowiki>}} を使ってロードされているサウンドモジュールとその順番を取得してください。{{ic|<nowiki>$ lsmod | grep snd</nowiki>}} を使ってデバイス・モジュールのリストを取得してください。この設定では {{ic|snd_mia}} を使うサウンドカードと {{ic|snd_hda_intel}} を使うサウンドカード (例: オンボード) を一枚づつ挿していると仮定しています。

index を {{ic|-2}} にすることで ALSA にカードを優先的に使わせないようにすることも可能です。Linux Mint や Ubuntu などのディストリビューションでは以下の設定を使うことで USB やその他の"一般的でない"ドライバに index {{ic|0}} を与えないようにしています:

{{hc|/etc/modprobe.d/alsa-base.conf|2=
options bt87x index=-2
options cx88_alsa index=-2
options saa7134-alsa index=-2
options snd-atiixp-modem index=-2
options snd-intel8x0m index=-2
options snd-via82xx-modem index=-2
options snd-usb-audio index=-2
options snd-usb-caiaq index=-2
options snd-usb-ua101 index=-2
options snd-usb-us122l index=-2
options snd-usb-usx2y index=-2
options snd-pcsp index=-2
options snd-usb-audio index=-2
}}

変更を反映させるには再起動する必要があります。

==== 環境変数を使ってデフォルト PCM を選択する ====

設定ファイルで、以下を追加してください:
pcm.!default {
type plug
slave.pcm {
@func getenv
vars [ ALSAPCM ]
default "hw:Audigy2"
}
}

default の行はあなたのカードの名前に置き換える必要があります (ここでは {{ic|Audigy2}} を例にしています)。{{ic|aplay -l}} で名前を取得することができ '''surround51''' のように PCM を使うことも可能です。ただしマイクロフォンを使う必要がある場合は full-duplex PCM をデフォルトにすると良いでしょう。

これで環境変数 {{ic|ALSAPCM}} を変更することでサウンドカードを選択できるようになります。カードを選択できない全てのプログラムで問題なく使えます。
例えば、'''mix51to20''' という名前の downmix PCM を書いたときは {{ic|mplayer}} を {{ic|ALSAPCM=mix51to20 mplayer example_6_channel.wav}} で使うことができます。

==== ハードウェアを直接割り当てる ====

{{Warning|この設定では他のアプリケーションからデバイスが使用不可能になります。この方法は、デジタル出力や音楽サーバーに捧げる場合など、わざとそうした場合にのみ推奨されます。サウンドサーバーや[[Advanced_Linux_Sound_Architecture#ミキシング|ミキシング]]無しの設定は[[Chromium]]等の幾つかのアプリケーションでサポートされていません。}}

まずデフォルトに設定したいカード・デバイスの id を {{ic|aplay -l}} で見つける必要があります:

{{hc|$ aplay -l|2=
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: CONEXANT Analog [CONEXANT Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: Conexant Digital [Conexant Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: JamLab [JamLab], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: Audio [Altec Lansing XT1 - USB Audio], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
}}

例えば、このリストの最後のエントリはカード ID 2,カード名 Audio でデバイス ID 0 です。このカードをデフォルトにするには、システム全体のファイル {{ic|/etc/asound.conf}} かユーザー定義ファイル {{ic|~/.asoundrc}} のどちらかを使ってください。ファイルが存在しないときは作成する必要があります。そして以下のオプションを適切なカード・デバイス id を使って挿入して下さい。

{{bc|
pcm.!default {
type hw
card Audio #又はcard 2
}

ctl.!default {
type hw
card Audio
}

pcm.dmixer {
type dmix
ipc_key 2048
slave {
pcm "hw:Audio"
}
}
pcm.dsnooper {
type dsnoop
ipc_key 2048
slave {
pcm "hw:Audio"
}
}
}}

カードIDではなくカード名の使用をおすすめします。デバイスの順番に依存しないためです。

{{ic|pcm.dmixer}}と{{ic|pcm.dsnooper}}は[[Advanced_Linux_Sound_Architecture#ミキシング|ミキシング]]が必要なアプリケーションの為の予備です。
{{Accuracy|General method to select alsa device should be introduced such as environment value.}}
例えば、{{ic|1=chromium -alsa-output-device=pcm.dmixer -alsa-input-device=pcm.dsnooper}}でChromiumがミキシングを使えるようになります。

{{Note|Asus U32U シリーズではカードの pcm と ctl の両方を 1 に設定する必要があります。}}

'pcm' オプションは音声の再生で使われるカード・デバイスに影響を与え、'ctl' オプションは alsamixer などのコントロールユーティリティで使われるカードに影響を与えます。

アプリケーション (mplayer など) を（再）起動すれば変更はすぐ適用されます。また、''aplay'' などのコマンドを使ってテストすることが可能です。

$ aplay -D default:PCH ''your_favourite_sound.wav''

asound 設定に関するエラーが表示される場合は、[http://www.alsa-project.org/main/index.php/Asoundrc#The_default_plugin 上流のドキュメント] を確認して設定ファイルフォーマットの変更を確認してください。

===サウンドモジュールがロードされていることを確かめる===

udev が正しくサウンドカードを検知しているかチェックするには次のコマンドを実行してください:

{{hc|<nowiki>$ lsmod | grep '^snd' | column -t</nowiki>|<nowiki>
snd_hda_codec_hdmi 22378 4
snd_hda_codec_realtek 294191 1
snd_hda_intel 21738 1
snd_hda_codec 73739 3 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel
snd_hwdep 6134 1 snd_hda_codec
snd_pcm 71032 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_timer 18992 1 snd_pcm
snd 55132 9 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer
snd_page_alloc 7017 2 snd_hda_intel,snd_pcm
</nowiki>}}

出力が上と同じようになっていれば、サウンドドライバが首尾よく自動検出されています。
{{Note|{{ic|udev>=171}} から、OSS エミュレーションモジュール ({{ic|snd_seq_oss, snd_pcm_oss, snd_mixer_oss}}) はデフォルトではロードされないようになりました: 必要ならば[[カーネルモジュール#ロード|手動でロードしてください]]。}}

{{ic|/dev/snd/}} ディレクトリにデバイスファイルがあるか調べてもいいかもしれません:

{{hc|$ ls -l /dev/snd|2=<nowiki>
total 0
crw-rw---- 1 root audio 116, 0 Apr 8 14:17 controlC0
crw-rw---- 1 root audio 116, 32 Apr 8 14:17 controlC1
crw-rw---- 1 root audio 116, 24 Apr 8 14:17 pcmC0D0c
crw-rw---- 1 root audio 116, 16 Apr 8 14:17 pcmC0D0p
crw-rw---- 1 root audio 116, 25 Apr 8 14:17 pcmC0D1c
crw-rw---- 1 root audio 116, 56 Apr 8 14:17 pcmC1D0c
crw-rw---- 1 root audio 116, 48 Apr 8 14:17 pcmC1D0p
crw-rw---- 1 root audio 116, 1 Apr 8 14:17 seq
crw-rw---- 1 root audio 116, 33 Apr 8 14:17 timer
</nowiki>}}

{{Note|IRC やフォーラムで助けを求める時は、上記のコマンドの出力を貼って下さい。}}

とにかく '''controlC0''' や '''pcmC0D0p''' のようなデバイスがあれば、サウンドモジュールが正しくロードされていることを示しています。

そうなってないのなら、あなたのサウンドモジュールは正しく検出されていません。これを解決するには、手動でモジュールのロードを試して下さい:

* サウンドカードのモジュールを確認します: [http://www.alsa-project.org/main/index.php/Matrix:Main ALSA Soundcard Matrix] モジュールには名前の前に 'snd-' が付きます (例: {{ic|snd-via82xx}})。
* [[カーネルモジュール#ロード|モジュールをロードします]]。
* {{ic|/dev/snd}} の中のデバイスファイルを確認したり（上述）、{{ic|alsamixer}} や {{ic|amixer}} に変化がないか調べて下さい。
* {{ic|snd-NAME-OF-MODULE}} と {{ic|snd-pcm-oss}} を[[カーネルモジュール#ロード|起動時にロード]]するよう設定して下さい。

===S/PDIF 出力===

[[wikipedia:ja:S/PDIF|S/PDIF]] はコンピュータとオーディオアンプを接続するときにしばしば使われるデジタルオーディオインターフェイスです (5.1/7.1 サラウンドのホームシアターなど)。
{{note|サウンドカードによっては以下の瀬底でアナログ出力が無効になることがあります (例: Sound Blaster Audigy 2)。}}
使用している[[シェル]]にあわせて、シェルの設定ファイルに以下の行を追加してください:
amixer -c 0 cset name='IEC958 Playback Switch' on

カードのデジタル出力の名前は以下のコマンドで確認できます:
$ amixer scontrols

===イコライザー===

====AlsaEqual を使う (UI あり)====

{{AUR|alsaequal}} パッケージをインストールしてください。

パッケージをインストールした後、以下を ALSA 設定ファイル ({{ic|~/.asoundrc}} か {{ic|/etc/asound.conf}}) に挿入してください:

ctl.equal {
type equal;
}

pcm.plugequal {
type equal;
# Modify the line below if you do not
# want to use sound card 0.
#slave.pcm "plughw:0,0";
#by default we want to play from more sources at time:
slave.pcm "plug:dmix";
}
#pcm.equal {
# If you do not want the equalizer to be your
# default soundcard comment the following
# line and uncomment the above line. (You can
# choose it as the output device by addressing
# it with specific apps,eg mpg123 -a equal 06.Back_In_Black.mp3)
pcm.!default {
type plug;
slave.pcm plugequal;
}

x86_64 環境で {{Pkg|lib32-flashplugin}}{{Broken package link|{{aur-mirror|lib32-flashplugin}}}} を使用している場合、上記の設定では flash で音が鳴りません。以下の設定で flash の音を有効にできますが、{{ic|pcm "hw:0,0"}} の行でサウンドカードを手動で指定する必要があります (利用可能なサウンドカードとカードのデバイス番号は {{ic|aplay -l}} で確認できます):

{{hc|/etc/asound.conf|2=
pcm.dmixer {
type dmix
ipc_key 2048
slave {
pcm "hw:0,0"
buffer_size 16384
}
}

ctl.equal {
type equal;
}

pcm.equalizer {
type equal
slave.pcm "plug:dmixer"
}

pcm.!default {
type plug
slave.pcm equalizer
}
}}

次のコマンドを使ってイコライザーを変更することができます:
$ alsamixer -D equal

設定ファイルはユーザーごとに違うので注意してください。{{ic|~/.alsaequal.bin}}　に保存されます。
AlsaEqual を異なるユーザーの [[Music Player Daemon|mpd]] などのソフトウェアで使いたいときは、次を実行することで設定できます:
# su mpd -c 'alsamixer -D equal'
もしくは、ユーザーの home にある {{ic|.alsaequal.bin}} のシンボリックリンクを作って下さい。

=====AlsaEqual の管理=====

{{AUR|alsaequal-mgr}} パッケージをインストールしてください。

通常通りイコライザーを設定してください:
$ alsamixer -D equal

状態に満足したら、名前を付けて保存してください (例: "foo"):
$ alsaequal-mgr save foo

イコライザーの状態 "foo" は次のコマンドで戻すことができます:
$ alsaequal-mgr load foo

ゲームや映画、音楽のジャンル別、VoIP アプリなどそれぞれに合わせてイコライザーの状態を作成し、必要なときにリロードできます。

オプションの詳細は [https://xyne.archlinux.ca/projects/alsaequal-mgr/ project page] を見て下さい。

====mbeq を使う====

{{Note|この方法では ladspa プラグインを使う必要があります。サウンドを再生する際に CPU の使用量が多めです。さらに、ステレオサウンドを念頭に置いて作成されています (例: ヘッドフォン)。}}

{{Pkg|alsa-plugins}}, {{Pkg|ladspa}}, {{Pkg|swh-plugins}} パッケージをインストールしてください。

まだ {{ic|~/.asoundrc}} か {{ic|/etc/asound.conf}} ファイルを作成していない場合は、どちらかを作成して以下を挿入して下さい:

{{hc|/etc/asound.conf|2=<nowiki>pcm.eq {
type ladspa

# The output from the EQ can either go direct to a hardware device
# (if you have a hardware mixer, e.g. SBLive/Audigy) or it can go
# to the software mixer shown here.
#slave.pcm "plughw:0,0"
slave.pcm "plug:dmix"

# Sometimes you may need to specify the path to the plugins,
# especially if you have just installed them. Once you have logged
# out/restarted this should not be necessary, but if you get errors
# about being unable to find plugins, try uncommenting this.
#path "/usr/lib/ladspa"

plugins [
{
label mbeq
id 1197
input {
#this setting is here by example, edit to your own taste
#bands: 50hz, 100hz, 156hz, 220hz, 311hz, 440hz, 622hz, 880hz, 1250hz, 1750hz, 25000hz,
#50000hz, 10000hz, 20000hz
controls [ -5 -5 -5 -5 -5 -10 -20 -15 -10 -10 -10 -10 -10 -3 -2 ]
}
}
]
}

# Redirect the default device to go via the EQ - you may want to do
# this last, once you are sure everything is working. Otherwise all
# your audio programs will break/crash if something has gone wrong.

pcm.!default {
type plug
slave.pcm "eq"
}

# Redirect the OSS emulation through the EQ too (when programs are running through "aoss")

pcm.dsp0 {
type plug
slave.pcm "eq"
}
</nowiki>}}

==高品質なリサンプリング==

ソフトウェアミキシングが有効になっていると、ALSA は全てを同じ周波数 (デフォルトで 48000) にリサンプリングします。dmix はサウンドの品質を落としてしまう低品質リサンプリングアルゴリズムを使っています。

{{pkg|alsa-plugins}} と {{pkg|libsamplerate}} をインストールして下さい。

デフォルトの変換器を libsamplerate に変更します:

{{hc|/etc/asound.conf|defaults.pcm.rate_converter "samplerate_best"}}

または:

{{hc|~/.asoundrc|defaults.pcm.rate_converter "samplerate_best"}}

'''samplerate_best''' は最高のサウンド品質を提供しますが、リアルタイムサンプリングをするには CPU サイクルが大量に必要になるので使うにはそこそこの CPU が必須です。また、dmix の設定で buffer_size を基本の 4096 から 8192 か 16384 に調整する必要もあるかもしれません。他のアルゴリズム ('''samplerate''' など) も利用できますがデフォルトのリサンプラーに比べておそらくあまり改善はないでしょう。

{{Warning|環境によっては、samplerate_best を有効にすると flashplayer でサウンドが出力されなくなるという問題が発生します。}}

==アップ・ダウンミキシング==

===アップミキシング===

音楽などのステレオ音源を 5.1 や 7.1 サウンドシステムをフルに使って再生するには、アップミキシングを使う必要があります。黎明期ではこれをするのはとても難しいものでした。ですが現在では簡単にアップミキシングができるプラグインがあります。{{Pkg|alsa-plugins}} に含まれている {{ic|upmix}} プラグインを使います。

それから以下を ALSA 設定ファイル ({{ic|/etc/asound.conf}} か {{ic|~/.asoundrc}}) に追加してください:
pcm.upmix71 {
type upmix
slave.pcm "surround71"
delay 15
channels 8
}

上の例は 7.1 のものですが 5.1 や 4.0 にも簡単に変えられます。

設定をするとアップミキシングに使う新しい pcm が加わります。全てのサウンド音源をこの pcm に通したい時は、次のようにデフォルトとして追加してください:

pcm.!default "plug:upmix71"

このプラグインは使うにあたって特に設定を変える必要はありません。
プラグインが動作しないときは、以下のようにしてアップミキシングする PCM のための dmixer を自分で設定してください:
pcm.dmix6 {
type asym
playback.pcm {
type dmix
ipc_key 567829
slave {
pcm "hw:0,0"
channels 6
}
}
}

そして "surround71" のかわりに "dmix6" を使って下さい。
音がスキップしたり歪むときは、buffer_size を増やす (例: 32768) か [[#高品質なリサンプリング|高品質リサンプラー]]を使ってください。

===ダウンミキシング===
5.1 サウンドの映画をステレオシステムで視聴するときなど、音源をステレオにダウンミキシングしたい場合、{{Pkg|alsa-plugins}} に含まれている {{ic|vdownmix}} プラグインを使って下さい。

設定ファイルに以下を追加して下さい:

pcm.!surround51 {
type vdownmix
slave.pcm "default"
}
pcm.!surround40 {
type vdownmix
slave.pcm "default"
}

{{Note|1=これだけではダウンミキシングが動作しないかもしれません、[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541786] を参照してください。その場合、{{ic|pcm.!default "plug:surround51"}} か {{ic|pcm.!default "plug:surround40"}} を追加する必要があります。{{ic|vdownmix}} プラグはひとつだけ使うことができます; 7.1 チャンネルのときは、上の設定の代わりに {{ic|surround71}} を使って下さい。{{ic|vdownmix}} と {{ic|dmix}} の両方を動かす設定例が[https://bbs.archlinux.org/viewtopic.php?id=167275 ここ]にあります。}}

==ミキシング==

ミキシングを使うことで複数のアプリケーションが同時に音を出力することが可能になります。外付けのサウンドカードはほとんどの場合ハードウェアミキシングをサポートしており、可能であればデフォルトで有効にされます。内蔵のマザーボードに載っているサウンドカード (Intel HD Audio など) は基本的にハードウェアミキシングをサポートしていません。そのようなカードでは、dmix という名前の ALSA プラグインを使ってソフトウェアミキシングを利用します。この機能はハードウェアミキシングが使えない場合に自動で有効にされます。

===手動で dmix を有効にする===

{{Note|ALSA 1.0.9rc2 以上ではアナログサウンドに dmix を設定する必要はありません。ハードウェアミキシングをサポートしていないサウンドカードのために Dmix はデフォルトで有効にされています。}}

ソフトウェアミキシングが動作しない場合は、あなたの home フォルダに以下の内容で .asoundrc ファイルを作成してください。

pcm.dsp {
type plug
slave.pcm "dmix"
}

これでソフトウェアミキシングが有効になり複数のアプリケーションがサウンドカードを使えるようになるはずです。使えない場合は、{{ic|/etc/asound.conf}} の中身を全て上のように置き換えてみて下さい。

S/PDIF などのデジタル音声出力をするために、ALSA パッケージは依然として dmix をデフォルトで有効にしていません。そのため、上の dmix 設定は S/PDIF デバイスで dmix を有効にするために使うことはできません。

一般的な問題と解決方法は [[Advanced Linux Sound Architecture/トラブルシューティング]] を見て下さい。

===ハードウェアミキシング===

====サポート====

ハードウェアでミキシングをサポートしているオーディオチップセットを持っている場合、設定は必要ありません。ほとんど全てのオンボード・オーディオチップセットはハードウェアミキシングをサポートしていないので、ソフトウェアでミキシングする必要があります（上述）。ハードウェアミキシングをサポートしているサウンドカードは少なく、Linux でサポートされているサウンドカードは以下になります:

* Creative SoundBlaster Live! (5.1 モデル)
* Creative SoundBlaster Audigy (複数)
* Creative SoundBlaster Audidy 2 (ZS モデル)
* Creative SoundBlaster Audigy 4 (Pro モデル)

{{Note|
* 上記のカードのローエンド版 (Audigy SE, Audigy 2 NX, SoundBlaster Live! 24bit, SoundBlaster Live! 7.1) は別のチップを使っているためハードウェアミキシングに対応していません。
* オンボードの VIA8237 チップは4ストリームのハードウェアミキシングに対応していますが、マザーボードによってはそれが3ストリームになったり (4番目のストリームが音を出さない) あるいは使えないこともあります。動作したとしても、他の方法と比べて音質は劣ります。}}

====フィックス====

64-bit Arch で Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02) を使っている場合、Enemy Territory でサウンドを鳴らすには以下を実行して下さい:
echo "et.x86 0 0 direct" > /proc/asound/card0/pcm0p/oss
echo "et.x86 0 0 disable" > /proc/asound/card0/pcm0c/oss

== ヒントとテクニック ==

=== USB サウンドカードのホットプラグ ===

USB サウンドカードが挿入されたときに、自動的に第一のアウトプットデバイスにするために、以下の udev ルールを使うことができます (例: 以下の2行を {{ic|/etc/udev/rules.d/00-local.rules}} に追加して再起動する)。

{{bc|1=KERNEL=="pcmC[D0-9cp]*", ACTION=="add", PROGRAM="/bin/sh -c 'K=%k; K=$${K#pcmC}; K=$${K%%D*}; echo defaults.ctl.card $$K > /etc/asound.conf; echo defaults.pcm.card $$K >>/etc/asound.conf'"
KERNEL=="pcmC[D0-9cp]*", ACTION=="remove", PROGRAM="/bin/sh -c 'echo defaults.ctl.card 0 > /etc/asound.conf; echo defaults.pcm.card 0 >>/etc/asound.conf'"}}

=== 同時出力 ===

ミニジャックで接続した外付けスピーカーと内蔵のスピーカーで同時に音楽を再生したい場合、{{ic|alsamixer}} や {{ic|amixer}} を使うことで ''Auto-Mute'' のミュートを解除してください:
$ amixer sset "Auto-Mute" unmute

そして ''Headphones''', ''Speaker'', '''Bass Speaker'' など他の必要なアイテムのミュートを解除してください。
{{Note|(ミニジャック) ヘッドフォンコネクタで接続した場合に音が割れる場合、[[Advanced Linux Sound Architecture/トラブルシューティング#ミニジャック (ヘッドフォンコネクタ) で音が割れる]]を見て下さい。}}

=== キーボードのボリュームコントロール ===

以下のコマンドをボリュームキーにマッピングしてください: {{ic|XF86AudioRaiseVolume}}, {{ic|XF86AudioLowerVolume}}, {{ic|XF86AudioMute}}

ボリュームを上げるには:
amixer set Master 5%+

ボリュームを下げるには:
amixer set Master 5%-

==トラブルシューティング==
[[Advanced Linux Sound Architecture/トラブルシューティング]]を見て下さい。

==設定例==

[[Advanced Linux Sound Architecture/設定例]]を見て下さい。

==参照==
* [http://www.alsa-project.org/ ALSA wiki]
* [http://www.alsa-project.org/main/index.php/Asoundrc Asoundrc]
* [http://alsa.opensrc.org/ 非公式 ALSA wiki]
* [https://www.mjmwired.net/kernel/Documentation/sound/alsa/ALSA-Configuration.txt 高度な ALSA モジュール設定]
* [https://bbs.archlinux.org/viewtopic.php?id=36815 HOWTO: compile driver from svn]
* [http://www.volkerschatz.com/noise/alsa.html A close look at ALSA: ALSA concept introduction]
* [http://www.sabi.co.uk/Notes/linuxSoundALSA.html Linux ALSA sound notes]

セキュリティ

2025-04-20T11:29:45Z

Oech3: SUIDバイナリの同期/* SUID ファイルと SGID ファイル */

[[Category:セキュリティ]]
[[Category:ファイルシステム]]
[[Category:ネットワーク]]
[[en:Security]]
[[fa:امنیت]]
[[ru:Security]]
[[zh-hans:Security]]
{{Related articles start}}
{{Related|PAM}}
{{Related|ケイパビリティ}}
{{Related|アプリケーション一覧/セキュリティ}}
{{Related|:カテゴリ:セキュリティ}}
{{Related articles end}}
この記事には、Arch Linux システムを[[Wikipedia:ja:ハードニング|ハードニング]]するための推奨事項とベストプラクティスを並べています。

== 概念 ==

* システムのセキュリティを厳重にしすぎると、使い物にならなくなることもある。セキュリティと利便性のバランスを取ることが重要だ。重要なのは、安全で ''かつ'' 使いやすいシステムを作ること。
* 最大の脅威は常にユーザー自身である。
* [[Wikipedia:ja:最小権限の原則|最小権限の原則]]: システムの各部分は、必要最小限の権限のみを持つべきであり、それ以上のアクセスは許可されるべきではない。
* 多層防御 (Defense in Depth): セキュリティは独立した複数の層で成り立つべきである。一つの層が突破されても、次の層が攻撃を食い止める仕組みが必要です。
* 少しだけ疑い深くなること。常に警戒すること。うますぎる話には注意すべきだ。それが本当である可能性は低いと思うこと。
* システムを100%安全にする方法はただ一つ。それはネットワークから切り離し、電源を切り、金庫に入れ、コンクリートで固め、二度と使用しないこと。
* 失敗を想定せよ。セキュリティが破られたときに備え、あらかじめ対応策を準備しておくこと。

==パスワード==
パスワードは安全な linux システムのかぎです。パスワードは[[ユーザーとグループ|ユーザーアカウント]], [[ディスク暗号化|暗号化されたファイルシステム]], [[SSH 鍵|SSH]]/[[GPG]] 鍵などを守ります。コンピュータを使用する人を信頼するのに使う主要な手段なので、安全なパスワードを選んでそれを保護するというのがセキュリティの大部分と言っても過言ではありません。

=== 安全なパスワードの選び方 ===

パスワードは、個人情報などから簡単に推測されないよう十分に複雑であり、また、ソーシャルエンジニアリングやブルートフォース攻撃などの手法で[[Wikipedia:Password cracking|クラック]]されないようにする必要があります。強力なパスワードの基本原則は、''長さ''と''ランダム性''に基づいています。暗号学では、パスワードの品質はその[[Wikipedia:Password strength#Entropy as a measure of password strength|エントロピー]]によって測られます。

安全でないパスワードには、以下のようなものが含まれます。また、以下のようなものを元に変更や置き換えを行った場合も同様に危険です。

* 個人を特定できる情報(例:ペットの名前、生年月日、市外局番、好きなビデオゲームなど)
* 単純な文字の置き換えを行った単語(例:{{ic|k1araj0hns0n}})最新の辞書攻撃ではこれらも簡単に解析可能
* 既存の "単語" や一般的な文字列の前後に数字・記号・文字を追加したもの(例:{{ic|DG091101%}})
* 一般的なフレーズや辞書にある単語を短く組み合わせたもの(例:{{ic|photocopyhauntbranchexpose}})文字の置き換えを行っても(例:{{ic|Ph0toc0pyh4uN7br@nch3xp*se}})、安全とは限らない(ただし、後述の "Diceware" を利用した場合は例外あり)
* [[Wikipedia:List of the most common passwords|最も一般的なパスワード]]のいずれか

最も安全なパスワードは、十分に長く(長いほど良い)ランダムなソースから生成されたものです。長いパスワードを使用することが重要です。[https://www.theregister.com/2019/02/14/password_length 弱いハッシュアルゴリズムを使用すると、8文字のパスワードハッシュはわずか数時間で解読可能] です。

{{Pkg|pwgen}} や {{AUR|apg}} のようなツールを使用すると、ランダムなパスワードを生成できます。しかし、これらのパスワードは覚えにくいことがあります。覚えやすくするための1つの方法は、長いパスワードを生成し、最初は最低限の安全な文字数だけを暗記し、完全な文字列を一時的に書き留めることです。時間をかけて入力する文字数を増やしていけば、最終的にはパスワードが筋肉の記憶として定着し、完全に覚える必要がなくなります。この方法は難易度が高いものの、辞書攻撃や "知的" ブルートフォース攻撃(単語の組み合わせや文字の置き換えを考慮する攻撃)に対して非常に強力です。

パスワード管理とは別に、{{Pkg|keepassxc}} はパスワード/パスフレーズの生成機能を提供します。GUI でカスタマイズ可能なパスワード生成機能があり、辞書ベースのパスフレーズもサポートされています。

パスワードを覚えるための1つの方法として、**記憶術(ニーモニック)**を利用することが挙げられます。
例えば、"the girl is walking down the rainy street" というフレーズは、以下のようなパスワードに変換できます。簡単な例:{{ic|t6!WdtR5}} より複雑な例:{{ic|t&6!RrlW@dtR,57}}
この方法は、パスワードを覚えやすくすることができますが、英単語の最初の文字には偏りがあることに注意が必要です([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]] を参照)

また、ランダムに生成したパスワードを紙に書いて安全な場所に保管するという方法も有効です。例えば、財布、カバン、金庫などに保管するのがよいでしょう。ほとんどの人は、デジタルセキュリティよりも物理的な貴重品の保護に関しては理解しやすいため、この方法は現実的です。

さらに、記憶術とランダム生成を組み合わせる方法も効果的です。例えば、長くランダムに生成したパスワードを[[パスワードマネージャ]]に保存し、それをマスターパスワードで管理する方法です。マスターパスワードは記憶し、絶対に保存しないようにします。この方法では、パスワードマネージャーがインストールされているシステムでのみパスワードにアクセスできるようになり、状況によっては不便にもなりますが、セキュリティ強化の側面もあります。一部のパスワードマネージャーにはスマートフォンアプリもあり、手入力が必要な場合にパスワードを表示することができます(この場合、完全にランダムなものではなく、タイピングしやすいが安全なパスワードを使うことも検討できます)ただし、マスターパスワードを忘れるとすべてのパスワードにアクセスできなくなるため、単一障害点になり得ることに注意が必要です。
また、一部のパスワードマネージャーは、保存するパスワードを暗号化するのではなく、マスターパスワードとサービス名から計算する方式を採用しており、新しいシステムでもデータ同期なしで使用できます。

覚えやすく、それでいて強力なパスワードの作成方法として、無関係な単語を複数組み合わせたパスフレーズを使うという方法もあります。この方法では、十分に長いフレーズを使用することで、辞書単語を使うことによるエントロピーの損失を補うことができます。この手法のエントロピーのトレードオフについては、[https://xkcd.com/936/ xkcdのコミック] に示されています。この方法の安全性は、選択可能な単語の集合が大きい(数千語以上)ことと、5〜7語以上のランダムな単語を選択することによって保証されます。攻撃者が選択可能な単語の集合と、使用する単語数を知っていたとしても、(選択可能な単語数) の (選択する単語数) 乗の通りのパスフレーズが生成可能であり、安全性が確保されます。詳細については [https://www.rempe.us/diceware/ Diceware] を参照してください。

さらに詳しい情報については、[https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] や [[Wikipedia:Password strength]] も参考になります。

=== パスワードの管理 ===

強力なパスワードを選んだら、それを安全に保管することが重要です。[[Wikipedia:Keylogger|キーロガー]] (ソフトウェアおよびハードウェア)、スクリーンロガー、[[Wikipedia:Social engineering (security)|ソーシャルエンジニアリング]]、[[Wikipedia:Shoulder surfing (computer security)|ショルダースーフィング]]に注意し、パスワードの使い回しを避けて、セキュリティの低いサーバーから不要な情報が漏れないようにしましょう。[[アプリケーション一覧/セキュリティ#パスワードマネージャ|パスワードマネージャ]]を使用すると、大量の複雑なパスワードを管理できます。パスワードマネージャーからアプリケーションに保存されたパスワードをコピー&ペーストして使用する場合は、毎回コピーした内容をクリアし、ログに保存されないようにしてください(例:プレーンテキストのターミナルコマンドにペーストしないようにし、{{ic|.bash_history}} などのファイルに保存されないようにします)ブラウザ拡張として実装されたパスワードマネージャは、[https://www.spookjs.com サイドチャネル攻撃]に脆弱である可能性があります。これを回避するためには、別のアプリケーションとして実行されるパスワードマネージャーを使用することが推奨されます。

原則として、強力なパスワードを覚えにくいからといって、セキュリティが低いパスワードを選んではいけません。パスワードはバランスを取る必要があります。強力なマスターパスワードと鍵で守られた暗号化された安全なパスワードデータベースを持つ方が、多くの似たような弱いパスワードを使うよりも優れています。パスワードを紙に書いて保管することも、[https://www.schneier.com/blog/archives/2005/06/write_down_your.html] で示されているように、ソフトウェアの脆弱性を避けつつ物理的なセキュリティを確保できるため、非常に効果的です。

パスフレーズの強度のもう一つの側面は、それが他の場所から簡単に回復できないことです。

ディスク暗号化のパスフレーズをログインパスワードと同じに使用する場合(例えば、ログイン時に暗号化されたパーティションやフォルダを自動マウントする場合)、{{ic|/etc/shadow}} が暗号化されたパーティションに保存されるか、または強力な鍵導出関数 (i.e. yescrypt/argon2 や sha512 を PBKDF2 で使用、md5 や低回数の PBKDF2 は避ける) を使用して保存されたパスワードハッシュを使うようにしてください (詳細については [[SHA hashes#SHA パスワードハッシュ|SHA パスワードハッシュ]] を参照してください)

{{Tip|Arch Linux は [https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのハッシュアルゴリズム]を yescrypt に変更しました。もしデフォルトをカスタマイズしていない場合は、{{ic|passwd}} を実行してパスワード変更を行うなどして下さい。}}

パスワードデータベースをバックアップする場合、そのコピーが他のパスフレーズで保護されていないことを確認してください。例えば、暗号化されたドライブや認証されたリモートストレージサービスなどです。もしそのような保護が施されている場合、必要なときにアクセスできなくなります。役立つ方法としては、データベースがバックアップされているドライブやアカウントをマスターパスワードの簡単な暗号学的ハッシュで保護することです。バックアップ場所のリストを保持してください。もしもマスターパスワードが漏洩したと疑われる場合、その場所すべてでパスワードを即座に変更し、マスターパスワードから導出された鍵で保護されたすべてのバックアップと場所も変更する必要があります。

データベースをセキュアにバージョン管理するのは非常に複雑な場合があります。もしその方法を選択するなら、すべてのデータベースバージョンでマスターパスワードを更新する手段を持っている必要があります。マスターパスワードが漏洩したときにそれを即座に知るのは難しいことがあります。他の人がパスワードを発見するリスクを減らすために、定期的にパスワードを変更することを選ぶかもしれません。もしデータベースのコピーの管理が失われたと感じた場合、そのコピーがブルートフォース攻撃によってマスターパスワードを解読される前に、そのデータベース内のすべてのパスワードを変更する必要があります。

=== パスワードのハッシュ ===

ハッシュは一方向の関数です。つまり、入力を計算せずにそのハッシュを解読することは不可能になるように設計されています (例:MD5、SHA)

パスワードハッシュ関数は、ユーザー入力 (パスワード) を計算せずに解読することが不可能になるように設計されています(例:bcrypt)[[Wikipedia:Key derivation function|鍵導出関数]] (KDF; 例:yescrypt、scrypt、PBKDF2) は、入力 (マスターキーやパスワード) から秘密鍵 (例:AESキー、パスワードハッシュ) を導出するために設計された暗号アルゴリズムです。したがって、KDF はパスワードハッシュ関数としても使用できる複数の用途に対応します。

デフォルトでは、Arch Linux はユーザーパスワードをルート専用の読み取り可能な {{ic|/etc/shadow}} ファイルにハッシュ化して保存します。これは、他のユーザーのパラメータが保存される世界に読み取り可能な {{ic|/etc/passwd}} ファイルから分離されています。詳細は [[ユーザーとグループ#ユーザーデータベース]] を参照してください。また、[[#root の制限]] も参照してください。

パスワードは '''passwd''' コマンドを使用して設定され、このコマンドはシステムの暗号化関数でパスワードを[[Wikipedia:Key stretching|ストレッチ]]し、その後 {{ic|/etc/shadow}} に保存されます。パスワードは[[Wikipedia:Salt (cryptography)|ソルト]]も施され、[[Wikipedia:Rainbow table|レインボーテーブル]]攻撃に対して防御されます。詳細は[https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils Linux でパスワードがどのように保存されているか(Shadow ユーティリティを使ったハッシュの理解)]を参照してください。

パスワードハッシュは定義されたフォーマットに従って保存されるため、新たな ''passwd'' コマンドの実行に対してメソッドとパラメータを設定することができます。したがって、{{ic|/etc/shadow}} ファイルに保存された個々のハッシュは、システムでサポートされているハッシュ関数の異種混合になる可能性があります。

フォーマット、ハッシュメソッド、およびパラメータに関する詳細は、{{man|5|crypt}} を参照してください。

{{ic|/etc/login.defs}} ファイルでは、[https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのパスワードハッシュメソッド]{{ic|ENCRYPT_METHOD YESCRYPT}} とそのパラメータ {{ic|YESCRYPT_COST_FACTOR}} が設定されます。

例えば、デフォルトの {{ic|YESCRYPT_COST_FACTOR}} パラメータを増加させると、パスワードからハッシュを導き出すために必要な計算時間が対数的に増加します。これは、システムがユーザーのログインを認証する際や、第三者がパスワードの秘密を取得しようとする場合にも適用されます。

これに対して、SHA-512 ハッシュ関数の計算時間は、パラメータにより線形的に影響されます。以前の Arch のデフォルトについては [[SHA パスワードハッシュ]] を参照してください。yescrypt アルゴリズムは内部で SHA-256、HMAC、およびPBKDF2 を使用してパスワードハッシュを計算することに注意してください。主な理由は、これらの広く使用され、テストされた関数の良い特性を組み合わせ、攻撃への耐性を強化することです。例えば、SHA の多用途性が原因で、この関数のハードウェアサポートが提供され、SHA ハッシュの計算性能が著しく向上したため、パスワードハッシュ関数としての使用が次第に時代遅れになりつつあります。

=== pam_cracklib を用いた強力なパスワードの強制 ===

''pam_pwquality'' は、[[Wikipedia:Dictionary attack|辞書攻撃]]に対する保護を提供し、システム全体で強制できるパスワードポリシーを設定するのに役立ちます。これは ''pam_cracklib'' をベースにしており、そのオプションとの後方互換性があります。

{{Pkg|libpwquality}} パッケージを[[インストール]]してください。

{{Warning|デフォルトでは、''root'' アカウントはこのポリシーの影響を受けません。}}

{{Note|
* ''root'' アカウントを使用すると、設定したパスワードポリシーをバイパスするユーザーパスワードを設定できます。これは一時的なパスワードを設定する際に便利です。
* 現在のパスワードに関するセキュリティガイドライン(例:NISTなど)では、特別な文字を強制することは推奨されていません。なぜなら、それらはしばしば予測可能な変更を引き起こすだけだからです。
}}

例えば、以下のポリシーを強制したい場合:

* エラーが発生した場合にパスワードを2回入力する (retry オプション)
* 最小長10文字 (minlen オプション)
* 新しいパスワードを入力する際、古いパスワードとは少なくとも6文字異なること (difok オプション)
* 最低1桁の数字 (dcredit オプション)
* 最低1つの大文字 (ucredit オプション)
* 最低1つの小文字 (lcredit オプション)
* 最低1つのその他の文字 (ocredit オプション)
* "myservice" および "mydomain" という単語を含めない
* root にもこのポリシーを強制する

{{ic|/etc/pam.d/passwd}}ファイルを以下のように編集します:

{{bc|1=
#%PAM-1.0
password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root
password required pam_unix.so use_authtok sha512 shadow
}}

{{ic|password required pam_unix.so use_authtok}} は、''pam_unix'' モジュールに対してパスワードの入力を促さず、代わりに ''pam_pwquality'' で提供されたものを使用するように指示します。

詳細については、{{man|8|pam_pwquality}} および {{man|8|pam_unix}} のマニュアルページを参照してください。

== CPU ==

=== マイクロコード ===

CPU のマイクロコードに対する重要なセキュリティ更新プログラムをインストールする方法については、[[マイクロコード]] を参照してください。

=== ハードウェアの脆弱性 ===

CPU の中には、ハードウェアの脆弱性を含んでいるものがあります。これらの脆弱性の一覧と、特定の使用シナリオに合わせてこれらの脆弱性を緩和するためにカーネルをカスタマイズするのに役立つ緩和策の選択ガイドについては、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/ kernel documentation on hardware vulnerabilities] を参照してください。

既知の脆弱性の影響を受けているかどうかを確認するには、以下を実行してください。

$ grep -r . /sys/devices/system/cpu/vulnerabilities/

ほとんどの場合、カーネルとマイクロコードを更新することで、脆弱性を軽減することができます。

==== 同時マルチスレッディング (ハイパースレッディング) ====

[https://ja.wikipedia.org/wiki/%E5%90%8C%E6%99%82%E3%83%9E%E3%83%AB%E3%83%81%E3%82%B9%E3%83%AC%E3%83%83%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0 同時マルチスレッディング]] (SMT) は、インテル CPU のハイパースレッディングとも呼ばれ、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html L1 Terminal Fault] および [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html Microarchitectural Data Sampling] 脆弱性の原因となる可能性のあるハードウェア機能です。Linux カーネルとマイクロコードのアップデートには、既知の脆弱性に対する緩和策が含まれていますが、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html#virtualization-with-untrusted-guests 信頼できない仮想化ゲストが存在する場合、特定の CPU で SMT を無効にしたほうが良い場合があります。]

SMT は、システムのファームウェアで無効にできることがよくあります。詳細については、マザーボードまたはシステムのドキュメントを参照してください。また、以下の [[カーネルパラメータ]] を追加することで、カーネルで SMT を無効にすることができます。

l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force

== メモリ ==

===ハード化された malloc ===

[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened_malloc}}, {{AUR|hardened-malloc-git}}) は [https://ja.wikipedia.org/wiki/GNU_C%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA glibc] の malloc() をハード化した代替品です。元々は Android の [[Wikipedia:Bionic (software)|Bionic]] と [https://ja.wikipedia.org/wiki/Musl musl] に組み込むために開発されましたが、 x86_64 アーキテクチャの標準 Linux ディストリビューションのサポートにも組み込みました。

hardened_malloc はまだ glibc に統合されていませんが(支援とプルリクエストは歓迎します)、LD_PRELOAD と一緒に簡単に使用することができます。これまでのテストでは、 {{ic|/etc/ld.so.preload}} でグローバルに有効にすると、一握りのアプリケーションにしか問題を起こしません。例えば、{{ic|getrandom}} が標準のホワイトリストにないため、{{ic|seccomp}} 環境フラグが無効でないと {{ic|man}} は正常に動作しませんが、これはシステムコールを追加して再構築すれば簡単に修正可能です。hardened_malloc は性能上のコストがあるので、どの実装を使うかは攻撃対象領域と性能上の必要性に基づいてケースバイケースで決めるとよいでしょう。

スタンドアロンで試すには、hardened-malloc-preload ラッパースクリプトを使用するか、適切なプリロード値でアプリケーションを手動で開始します。

LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox

[[Firejail]] の正しい使い方は、その wiki ページにあります。また、hardened_malloc の設定可能なビルドオプションは、githubレポで見つけることができます。

== ストレージ ==

===ディスク暗号化===

[[ディスク暗号化]]、特に [[#パスワード|強力なパスフレーズ]] を使用したフルディスク暗号化は、物理的な回復からデータを守る唯一の方法です。これにより、コンピュータの電源がオフになっている場合や、対象のディスクがアンマウントされている場合にデータの機密性が保たれます。

ただし、コンピュータの電源が入っており、ドライブがマウントされている場合、そのデータは暗号化されていないドライブと同様に脆弱です。そのため、データパーティションがもう必要なくなったら、できるだけ早くアンマウントすることが最良の実践です。

また、[[Trusted Platform Module#LUKS による保存データの暗号化|TPMにキーを保存してドライブを暗号化]] することもできますが、過去に [https://tpm.fail 脆弱性] があり、キーは [https://pulsesecurity.co.nz/articles/TPM-sniffing TPMバススニッフィング攻撃] によって抽出される可能性があります。

[[dm-crypt]] のような特定のプログラムは、ユーザーが仮想ボリュームとしてループファイルを暗号化できるようにします。これは、システムの特定の部分だけを安全に保護する必要がある場合、フルディスク暗号化の合理的な代替手段です。

[[ディスク暗号化]] の記事で比較されているブロックデバイスやファイルシステムベースの暗号化方法は、物理メディア上のデータ保護には有効ですが、リモートシステム(例えば [[保存データ暗号化#クラウドストレージの最適化|クラウドストレージ]])に保存されたデータを保護するためには使用できません。そのため、個々のファイル暗号化が役立つ場合もあります。

ファイルを暗号化するためのいくつかの方法は次の通りです:

* 一部の [[アーカイブと圧縮|アーカイブおよび圧縮]] ツールは基本的な暗号化も提供します。例としては、[[7-Zip]] ({{ic|-p}} フラグ)、{{Pkg|zip}} ({{ic|-e}}フラグ) があります。これらのツールはクロスプラットフォームの互換性のためにカスタムアルゴリズムを使用している場合があるため、特別な注意を払って使用するべきです。[https://math.ucr.edu/~mike/zipattacks.pdf]
* [[GnuPG]] を使用してファイルを [[GnuPG#Encrypt and decrypt|暗号化]] できます。
* {{Pkg|age}} は、シンプルで使いやすいファイル暗号化ツールです。複数の受信者をサポートしており、SSH キーを使用した暗号化もサポートしているため、安全なファイル共有に役立ちます。

=== ファイルシステム ===

現在カーネルは {{ic|fs.protected_hardlinks}} や {{ic|fs.protected_symlinks}} sysctl スイッチが有効になっていればハードリンクやシンボリックリンクに関するセキュリティの問題を解決するので、world-writable なディレクトリを分離させるセキュリティ的な利点はもはや存在しません。

それでもディスク容量が消耗したときのダメージを低減させる荒っぽい方法として world-writable なディレクトリを含むパーティションが分割されることがあります。しかしながら、サービスを落とすには {{ic|/var}} や {{ic|/tmp}} などのパーティションを一杯にするだけで十分です。この問題の対処についてはもっと柔軟性のある方法が存在します (クォータなど)、またファイルシステムによっては関連する機能を持っていることがあります (btrfs はサブボリュームにクォータを設定できます)。

====マウントオプション====

最小特権の原則に従い、ファイルシステムは可能な限り制限の厳しいマウントオプションを使用してマウントするべきです(機能を失わない範囲で)

関連するマウントオプションは以下の通りです:

* {{ic|nodev}}: ファイルシステム上のキャラクタデバイスやブロックデバイスを解釈しない。
* {{ic|nosuid}}: set-user-identifier や set-group-identifier ビットを無効にする。
* {{ic|noexec}}: マウントされたファイルシステム上のバイナリを直接実行できないようにする。
** {{ic|/home}} に {{ic|noexec}} を設定すると、実行可能なスクリプトが禁止され、[[Wine]]、[[Steam]]、PyCharm、[[.NET]] などが動作しなくなります。
*** Wine は Windows バイナリの実行に {{ic|exec}} フラグを必要としません。ただし、Wine 自体を {{ic|/home}} にインストールする場合は必要です。
*** [[Steam]] を動作させるには、{{ic|/home/user/.local/share/Steam}} を [[fstab]] で {{ic|exec}} としてマウントできます。以下の設定を追加してください: {{bc|/home/user/.local/share/Steam /home/user/.local/share/Steam none defaults,bind,user,exec,nofail 0 0}}
** 一部のパッケージ(例:{{Pkg|nvidia-dkms}} のビルド)では、{{ic|/var}} に {{ic|exec}} が必要な場合があります。

データ用のファイルシステムは、常に {{ic|nodev}}、{{ic|nosuid}}、{{ic|noexec}} を指定してマウントするべきです。

マウントを検討すべきファイルシステム:

* {{ic|/var}}
* {{ic|/home}}
* {{ic|/dev/shm}}
* {{ic|/tmp}}
* {{ic|/boot}}

{{Tip|[[systemd#GPT パーティションの自動マウント|GPT パーティションの自動マウント]] を使用する場合、ESP および XBOOTLDR パーティションは [https://github.com/systemd/systemd-stable/commit/49804cfb71d3a79f433096e4cfb5616980171336 常に {{ic|noexec,nosuid,nodev}} で強化] されます。}}

==== スナップショット ====

ファイルシステムのスナップショットを利用する場合(例えば [[Btrfs]]、[[LVM]]、[[ZFS]] など)、スナップショットがユーザーが削除したと期待している機密情報を保持する可能性があることを理解することが重要です。特に、[[Snapper]] のような自動スナップショットツールを設定している場合、定期的またはシステムイベントに応じてスナップショットが作成されるため、この問題が発生しやすくなります。

以下は、{{ic|/home/}} 内の機密情報がスナップショットに残存する例です:

* 削除されたファイルやディレクトリ: ファイルシステム上から削除されたとしても、古いスナップショット内には残存している可能性があります。これは通常想定される動作ですが、{{ic|.local/share/Trash/}}、{{ic|.history}} などのファイルやディレクトリを保持する必要があるかどうかを検討すべきです。
* 一時ファイルやキャッシュ: アプリケーションによって生成された一時ファイルやキャッシュデータもスナップショットに含まれる可能性があります。例えば、暗号化されたディレクトリ内のファイルを開くと、サムネイル({{ic|.cache/thumbnails}})や作業用のコピーが作成され、それらがスナップショットに含まれる可能性があります。同様に、ブラウザの履歴({{ic|.mozilla/}}、{{ic|.config/chromium/}} など)も、削除される前にスナップショットに記録されている場合があります。

対応可能であれば、これらのディレクトリをスナップショットの対象から完全に除外することを検討してください。例えば、[[Btrfs]] を使用している場合、{{ic|.cache/}}、{{ic|.config/}}、{{ic|.local/}}、{{ic|.var/}} など、用途に応じたディレクトリをサブボリュームとして作成することで、スナップショットの影響を受けにくくできます。

{{Note|{{ic|.local/share/Trash}} を別のサブボリュームに移動すると、場合によっては [[GNOME/Files]] などでゴミ箱の機能が正常に動作しなくなる可能性があります。}}

===ファイルシステムのパーミッション===

デフォルトの [[パーミッション]] では、ほとんどのファイルが読み取り可能になっていますが、これを変更することで、{{ic|http}} ユーザーや {{ic|nobody}} ユーザーなどの非 root アカウントに侵入した攻撃者から貴重な情報を隠すことができます。[[chmod]] を使用して、グループやその他のユーザーからすべてのアクセス権を削除できます。

# chmod go-r ''path_to_hide''

{{Warning|この設定を広範囲に適用しないでください。1つの設定ファイルごとに適用し、非表示にする価値があるか、プログラムの動作に影響しないかを確認してください。グループが必要な場合は、{{ic|g}} をコマンドから削除するか、既に実行してしまった場合は {{ic|chmod g+r path}} で再度許可を追加する必要があるかもしれません。}}

考慮すべきパスの例:

* {{ic|/boot}}: [[パーティショニング#/boot|ブートディレクトリ]]、[[vmlinuz]] や [[initramfs]] image、または [[ユニファイドカーネルイメージ]] が含まれる場合があります。なお、[[systemd# GPT パーティションの自動マウント]] を使用する場合、デフォルトで安全なパーミッションが適用されます。
* {{ic|/etc/nftables.conf}}: [[nftables]] の設定ファイル({{Pkg|nftables}} および {{Pkg|iptables-nft}} に適用)
* {{ic|/etc/iptables}}: レガシーな [[iptables]] の設定ファイル({{Pkg|iptables}} に適用)

また、新しく作成されるファイルのセキュリティを向上させるために、デフォルトの [[umask]] 値 {{ic|0022}} を変更することも可能です。[https://apps.nsa.gov/iaarchive/library/ia-guidance/security-configuration/operating-systems/guide-to-the-secure-configuration-of-red-hat-enterprise.cfm NSA RHEL5 Security Guide] では最大限のセキュリティを確保するために、{{ic|0077}} を推奨しており、これにより所有者以外のユーザーが新しいファイルを読み取れなくなります。変更方法については [[Umask#マスクの値を設定]] を参照してください。

さらに、[[sudo]] を使用する場合、[[Sudo#Permissive umask|デフォルトの root umask]] を適用するよう設定することを検討してください。

=== SUID ファイルと SGID ファイル ===

[[Wikipedia:ja:Setuid|Setuid]] ビットや Setgid ビットが設定されたファイルには注意しましょう。このようなファイルの例としては、以下があります。

* [[PAM|unix_chkpwd]]
* chage, expiry, gpasswd, groupmems, [[passwd]], sg, ({{Pkg|shadow}})
* [[FUSE|fusermount3]]
* pkexec, polkit-agent-helper-1[https://github.com/polkit-org/polkit/pull/501] ([[polkit]])
* [[OpenSSH|ssh-keysign]]
* chfn, chsh, mount, newgrp, umount, wall, write ({{Pkg|util-linux}})
* [[sudo]], {{Pkg|sudo-rs}}, [[doas]], [[su]], su-rs, [[Kerberos|ksu]]
* [[firejail]]
* [[Dbus|dbus-daemon-launch-helper]]
* [[Chromium|chromium-sandbox]]
* [[Xorg|Xorg.wrap]]

このような実行ファイルの主なリスクとして、特権昇格の脆弱性があります。例えば [[Wikipedia:Setuid#Security impact]] を参照してください。[https://www.cvedetails.com/vulnerability-list/vendor_id-16224/product_id-36412/Calibre-ebook-Calibre.html][https://www.cvedetails.com/product/32625/Sudo-Project-Sudo.html?vendor_id=15714][https://www.cvedetails.com/vulnerability-list/vendor_id-16191/Firejail-Project.html]

SUID ビットが設定されているが root によって所有されていないファイル、または SGID ビットが設定されているファイルは、''典型的には''潜在的なリスクがより小さいですが、理論上、そのようなファイルに脆弱性が存在している場合は、依然として損害を与える可能性があります。通常、代わりに[[ケイパビリティ]]を割り当てることによって、Setuid や Setgid の使用を回避することが可能です。

{{Tip|SUID/SGID 実行ファイルを含むパッケージを最新に保って、脆弱性からシステムを守ることが肝心です。}}

SUID ビットか SGID ビットを持つファイルを {{ic|/usr/bin}} から探すには:

$ find /usr/bin -perm "/u=s,g=s"

== ユーザー設定 ==

=== root アカウントを日常的に使用しない ===

最小特権の原則に従い、root ユーザーを日常的に使用しないようにしてください。システムを使用する各人に非特権ユーザーアカウントを作成するか。一時的な特権アクセスには、必要に応じて [[sudo]] を使用する。

=== ログイン失敗後の遅延時間の設定 ===

以下の行を {{ic|/etc/pam.d/system-login}} に追加し、ログインに失敗した際に最低4秒の遅延を追加します。

{{hc|/etc/pam.d/system-login|2=
auth optional pam_faildelay.so delay=4000000
}}

{{ic|4000000}} は遅延させる時間をマイクロ秒単位で指定します。

===3回ログインを失敗したユーザーをロックアウトする===

{{Pkg|pambase}} 20200721.1-2 の時点では、デフォルトで {{ic|pam_faillock.so}} が有効になっており、15分間に3回ログインに失敗すると10分間ユーザをロックアウトします ({{Bug|67644}} を参照してください) このロックアウトはパスワード認証 (例:ログインと ''sudo'') にのみ適用され、SSH 経由の公開鍵認証はそのまま利用可能です。完全なサービス拒否を防ぐために、このロックアウトは root では無効になっています。

ユーザーをロック解除するには、次のようにします。

$ faillock --reset --user ''username''

デフォルトでは、ロック機構は {{ic|/run/faillock/}} にあるユーザーごとのファイルです。ディレクトリの所有者は root ですが、ファイルの所有者はユーザーなので、 {{ic|faillock}} コマンドはファイルを空にするだけで、root は必要ありません。

モジュール {{ic|pam_faillock.so}} は、ファイル {{ic|1=/etc/security/faillock.conf}} で設定することが可能です。ロックアウトのパラメータです。

* {{ic|unlock_time}} - ロックアウト時間 (秒単位、デフォルトは10分)
* {{ic|fail_interval}} - ロックアウトに失敗するとロックアウトされる時間 (秒単位、デフォルトは15分)
* {{ic|deny}} - ロックアウトするまでに何回ログインに失敗するか (デフォルトは 3)

{{Note|{{ic|1=deny = 0}} はロックアウトを無効化します}}

デフォルトでは、すべてのユーザーロックは再起動後に失われます。攻撃者がマシンをリブートできるのであれば、ロックは持続させた方が安全です。ロックを持続させるには、{{ic|1=/etc/security/faillock.conf}} の {{ic|dir}} パラメータを {{ic|/var/lib/faillock}} に変更する必要があります。

変更を反映させるために再起動する必要はありません。root アカウントのロックアウトを有効にする、集中ログイン (LDAP など) を無効にするなど、さらなる設定オプションについては {{man|5|faillock.conf}} を参照してください。

=== プロセスの数を制限する ===

信頼できないユーザーが大量に存在するシステムでは、一度に実行できるプロセスの数を制限して、[[Wikipedia:ja:Fork爆弾|フォーク爆弾]]などのサービス拒否攻撃を予防することが重要です。ユーザーやグループごとに実行できるプロセスの数は {{ic|/etc/security/limits.conf}} で定義することができ、デフォルトでは空になっています。以下の値をファイルに追加すると、実行できるプロセスが100個までに制限されます。{{ic|prlimit}} コマンドを使って一時的に上げられる最大数も200個までに制限します。ユーザーが普段実行するプロセスの数や、管理するハードウェアにあわせて適切な値に変更してください。

* soft nproc 100
* hard nproc 200

=== Wayland を使用する ===

[[Xorg]] よりも [[Wayland]] を使用することをお勧めします。Xorg の設計は現代のセキュリティ慣行より古く、多くの人が [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 は安全でないと考えています] 例えば、Xorg のアプリケーションは非アクティブな状態でもキーストロークを記録することがあります。

もし Xorg を実行しなければならないなら、[[Xorg#Rootless_Xorg|root での実行を避ける]]ことが推奨されます。Wayland 内では、XWayland 互換レイヤーは自動的に root レス Xorg を使用します。

== root の制限 ==
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。

=== su の代わりに sudo を使う ===
[[Su#セキュリティ|色々な理由]]から特権アクセスには [[su]] よりも [[sudo]] を使うほうが好ましいとされます。

* 通常の権限しか持たないユーザーが実行した特権コマンドのログを保持します。
* root アクセスを必要とする各ユーザーに root ユーザーのパスワードを与える必要がありません。
* 完全な root ターミナルは作成されないため、{{ic|sudo}} は root アクセスが必要ないコマンドを偶発的に ''root'' で実行してしまうことを防止します。これは[[Wikipedia:ja:最小権限の原則|最小権限の原則]]と合っています。
* 一つのコマンドを実行するためだけに完全な root アクセスを与える代わりに、ユーザーごとに個々のプログラムを有効にすることができます。例えば、ユーザー ''alice'' に特定のプログラムへのアクセス権限を与えるには:

# visudo

{{hc|/etc/sudoers|
alice ALL = NOPASSWD: /path/to/program}}

また、全てのユーザーに個別のコマンドを許可することも可能です。通常ユーザーでサーバーから Samba 共有をマウントするには:

%users ALL=/sbin/mount.cifs,/sbin/umount.cifs

これによって users グループのメンバーである全てのユーザーが全てのマシン (ALL) から {{ic|/sbin/mount.cifs}} や {{ic|/sbin/umount.cifs}} コマンドを実行できるようになります。

{{Tip|{{ic|visudo}} で {{ic|vi}} の代わりに {{ic|nano}} を使うには:

{{hc|/etc/sudoers|
2=Defaults editor=/usr/bin/rnano
}}
{{ic|1=# EDITOR=nano visudo}} のエクスポートは何にでも {{ic|EDITOR}} として使うことができるためにセキュリティリスクとされています。
}}

==== sudo を使ってファイルを編集する ====
root で {{ic|vim}} などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:

export SUDO_EDITOR=rvim

ファイルの編集には {{ic|sudoedit filename}} または {{ic|sudo -e filename}} を使って下さい。自動的に {{ic|rvim}} によって {{ic|filename}} が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。

=== root ログインの制限 ===
[[sudo]] を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。[[sudo]] を使える状態のまま root を無効化したい場合、{{ic|passwd -l root}} を使用します。

==== 特定のユーザーだけに許可を与える ====
[[Wikipedia:Pluggable authentication module|PAM]] の {{ic|pam_wheel.so}} は {{ic|wheel}} グループに入っているユーザーだけに {{ic|su}} を使用したログインを許可します。{{ic|/etc/pam.d/su}} と {{ic|/etc/pam.d/su-l}} の両方を編集して次の行をアンコメントしてください:
{{bc|<nowiki>
# Uncomment the following line to require a user to be in the "wheel" group.
auth required pam_wheel.so use_uid
</nowiki>}}
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。

==== ssh ログインを拒否する ====
ローカルユーザーの root ログインを拒否したくない場合でも、[[SSH#root ログインを拒否する|SSH による root ログインを拒否]]するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。

==== access.conf で許容されるログインの組み合わせを指定する ====

誰かが [[PAM]] でログインしようとすると、 {{ic|/etc/security/access.conf}} がそのログインプロパティに一致する最初の組み合わせをチェックします。そして、その組み合わせのルールに基づいて、試行が失敗するか成功するかが決まります。

+:root:LOCAL
-:root:ALL

特定のグループやユーザーに対してルールを設定することができます。この例では、ユーザー archie は、wheel および adm グループに属するすべてのユーザーと同様に、ローカルでのログインを許可されています。それ以外のログインは拒否されます。

+:archie:LOCAL
+:(wheel):LOCAL
+:(adm):LOCAL
-:ALL:ALL

詳しくは {{man|5|access.conf}} で確認してください。

==強制アクセス制御==

[[Wikipedia:ja:強制アクセス制御|強制アクセス制御]] (Mandatory Access Control, MAC) は Arch やほとんどの Linux ディストリビューションで使われている[[Wikipedia:ja:任意アクセス制御|任意アクセス制御]] (Discretionary Access Control, DAC) とは大きく異なるタイプのセキュリティポリシーです。原則的に MAC ではシステムに影響を与えるプログラムの行動は全てセキュリティルールセットによってチェックを受けます。このルールセットは、DAC とは対照的に、ユーザーが変更することは不可能です。実装方法は色々と異なるタイプが存在しますが、強制アクセス制御を使うことで実質的にコンピュータのセキュリティを著しく向上させることになります。

===パス名 MAC===
パス名ベースのアクセス制御は指定されたファイルのパスに基づいてパーミッションを与えるというシンプルな形式のアクセス制御です。この形式のアクセス制御の欠点としてはファイルが移動されてもパーミッションはファイルと一緒に付いていかないということが挙げられます。プラス面となるのは、パス名ベースの MAC はラベルベースの MAC と異なり、幅広いファイルシステムに実装できることです。

*[[AppArmor]] は [[Wikipedia:ja:カノニカル|Canonical]] によって開発されている MAC 実装で SELinux に比べて"簡単"になっています。
*[[TOMOYO Linux|Tomoyo]] はもうひとつのシンプルで、使いやすい強制アクセス制御を提供するシステムです。利用と実装の両面でシンプルになるように設計されており、依存するライブラリがとても少なくなっています。

===ラベル MAC===
ラベルベースのアクセス制御ではファイルの拡張属性を使ってセキュリティパーミッションを管理します。このシステムはセキュリティの機能においてパス名ベースの MAC よりも間違いなく柔軟性が高い一方、拡張属性をサポートしているファイルシステムでしか動作しません。

*[[SELinux]] は、Linux セキュリティを向上させる [[Wikipedia:ja:アメリカ国家安全保障局|NSA]] プロジェクトに基づいており、システムユーザーやロールとは完全に独立して MAC を実装しています。成長してオリジナルの設定が変わっていくシステムのコントロールを簡単に維持できる、極めて強固なマルチレベル MAC ポリシー実装を提供します。

=== アクセス制御リスト ===
[[アクセス制御リスト]] (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。

== カーネルの堅牢化 ==

=== カーネルの自己防衛機能/脆弱性攻撃対策 ===

{{pkg|linux-hardened}} パッケージは、[https://github.com/anthraxx/linux-hardened 基本的なカーネル堅牢化パッチセット]と、{{pkg|linux}} パッケージよりもセキュリティに重点を置いたコンパイル時設定オプションを使用します。カスタムビルドでは、セキュリティ寄りのデフォルトとは異なる、セキュリティと性能の妥協点を選択することができます。

しかし、このカーネルを使うといくつかのパッケージが動かなくなることに注意する必要があります。例えば

* {{AUR|skypeforlinux-preview-bin}}
* {{AUR|skypeforlinux-stable-bin}}
* {{pkg|throttled}}

[[NVIDIA]] などのアウトオブツリードライバを使用している場合、その [[DKMS]] パッケージに切り替える必要があるかもしれません。

==== ユーザー空間 ASLR の比較 ====

{{pkg|linux-hardened}} パッケージは、アドレス空間配置ランダム化の改善された実装をユーザ空間のプロセスに対して提供します。{{pkg|paxtest}} コマンドを使うことで、提供されるエントロピーの推定値を得ることができます:

===== 64 ビットプロセス =====

{{hc|linux-hardened 5.4.21.a-1-hardened|
Anonymous mapping randomization test : 32 quality bits (guessed)
Heap randomization test (ET_EXEC) : 40 quality bits (guessed)
Heap randomization test (PIE) : 40 quality bits (guessed)
Main executable randomization (ET_EXEC) : 32 quality bits (guessed)
Main executable randomization (PIE) : 32 quality bits (guessed)
Shared library randomization test : 32 quality bits (guessed)
VDSO randomization test : 32 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)
Randomization under memory exhaustion @~0: 32 bits (guessed)
Randomization under memory exhaustion @0 : 32 bits (guessed)
}}

{{hc|linux 5.5.5-arch1-1|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 20 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 29 bits (guessed)
Randomization under memory exhaustion @0 : 29 bits (guessed)
}}

{{hc|linux-lts 4.19.101-1-lts|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 19 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 28 bits (guessed)
Randomization under memory exhaustion @0 : 28 bits (guessed)
}}

===== 32 ビットプロセス (x86_64 カーネル上) =====

{{hc|linux-hardened|
Anonymous mapping randomization test : 16 quality bits (guessed)
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)
Heap randomization test (PIE) : 27 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 18 quality bits (guessed)
Shared library randomization test : 16 quality bits (guessed)
VDSO randomization test : 16 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)
Randomization under memory exhaustion @~0: 18 bits (guessed)
Randomization under memory exhaustion @0 : 18 bits (guessed)
}}

{{hc|linux|
Anonymous mapping randomization test : 8 quality bits (guessed)
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)
Heap randomization test (PIE) : 13 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 8 quality bits (guessed)
Shared library randomization test : 8 quality bits (guessed)
VDSO randomization test : 8 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)
Randomization under memory exhaustion @~0: No randomization
Randomization under memory exhaustion @0 : No randomization
}}

=== proc ファイルシステム内のカーネルポインタへのアクセスを制限する ===

{{ic|kernel.kptr_restrict}} を 1 に設定すると、{{ic|CAP_SYSLOG}} を持たない通常ユーザから {{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが秘匿され、カーネルのエクスプロイトで動的にアドレス/シンボルを解決することが困難になります。これは、事前にコンパイルされた Arch Linux カーネルではあまり意味がありません。周到な攻撃者はカーネルパッケージをダウンロードして、そこから手動でシンボルを取得することができるからです。しかしながら、自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし、一部の {{Pkg|perf}} コマンドの機能が、root 以外のユーザによって使用されば場合に破壊されます (しかし、いずれにせよ多くの {{Pkg|perf}} コマンドは root アクセスを必要とします)。詳細は {{Bug|34323}} を参照してください。

{{ic|kernel.kptr_restrict}} を 2 に設定すると、{{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが権限に依らず隠されます。

{{hc|/etc/sysctl.d/51-kptr-restrict.conf|2=
kernel.kptr_restrict = 1
}}

{{Note|{{pkg|linux-hardened}} はデフォルトで {{ic|0}} ではなく {{ic|1=kptr_restrict=2}} を設定します。}}

=== BPF の堅牢化 ===

BPF は、実行時にカーネル内のバイトコードを動的にロードして実行するために使用されるシステムです。ネットワーク (XDP, tc など)、トレース (kprobes, uprobes, tracepoints など)、セキュリティ (seccomp など) など、多くの Linux カーネルサブシステムで使用されています。また、高度なネットワークセキュリティ、パフォーマンスプロファイリング、ダイナミックトレースにも有効です。

BPF はもともと [[Wikipedia:ja:Berkeley Packet Filter|Berkeley Packet Filter]] の頭文字をとったもので、オリジナルの古典的な BPF は BSD 用のパケットキャプチャツールに使われていたためです。これは最終的に拡張 BPF (eBPF) に発展し、その後まもなくただの BPF (頭字語ではありません) に改名されました。BPFはパケットフィルタリングツールの実装に使われることがありますが、 iptables や netfilter のようなパケットフィルタリングツールと混同しないでください。

BPF のコードは解釈されるか、[[Wikipedia:ja:実行時コンパイラ|Just-In-Time (JIT) コンパイラ]]を使ってコンパイルされるかのどちらかです。Arch のカーネルは {{ic|CONFIG_BPF_JIT_ALWAYS_ON}} でビルドされており、BPF インタープリタを無効にして全ての BPF を JIT コンパイラでコンパイルするよう強制しています。これにより、攻撃者が BPF を使って SPECTRE 型の脆弱性を悪用した特権昇格攻撃をすることが難しくなります。詳しくは、[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290af86629b25ffd1ed6232c4e9107da031705cb CONFIG_BPF_JIT_ALWAYS_ON を導入したカーネルパッチ]を参照してください。

カーネルは JIT コンパイルされた BPF に対して、パフォーマンスと多くの BPF プログラムをトレース・デバッグする能力を犠牲にして、ある種の JIT スプレー攻撃を軽減するための堅牢化機能を備えています。この機能は、{{ic|net.core.bpf_jit_harden}} を {{ic|1}} (非特権コードの堅牢化を有効化する) か {{ic|2}} (全てのコードの堅牢化を有効化する) に設定することで有効化できます。

詳しくは、[https://docs.kernel.org/admin-guide/sysctl/net.html カーネルドキュメント] の {{ic|net.core.bpf_*}} 設定を参照してください。

{{Tip|
* {{Pkg|linux-hardened}} では、デフォルトで {{ic|1=net.core.bpf_jit_harden=2}} が設定されており、{{ic|0}} ではありません。
* デフォルトでは、BPF プログラムは非特権ユーザでも実行可能です。この挙動を変更するには {{ic|1=kernel.unprivileged_bpf_disabled=1}} を設定してください [https://access.redhat.com/security/cve/cve-2021-33624]。
}}

=== ptrace スコープ ===

{{man|2|ptrace}} システムコールは、あるプロセス ("tracer") が他のプロセス ("tracee") の実行を監視、制御し、tracee のメモリとレジスタを検査、変更するための手段を提供します。通常、{{ic|ptrace}} は ''gdb'' や ''strace''、''perf''、''reptyr'' などのデバッグツールによって使用されます。しかし、他のプロセスからデータを読んだり、他のプロセスの制御を奪ったりする手段を悪意のあるプロセスにも提供してしまいます。

Arch では、{{ic|kernel.yama.ptrace_scope}} [[カーネルパラメータ]]を提供する [https://docs.kernel.org/admin-guide/LSM/Yama.html Yama LSM] がデフォルトで有効化されています。このパラメータはデフォルトで {{ic|1}} (制限) に設定されており、{{ic|CAP_SYS_PTRACE}} [[ケイパビリティ]]も特権も持たない tracer が制限されたスコープ外で {{ic|ptrace}} コールを実行できないようにしています。これは、古典的なパーミッションと比べてセキュリティ上大きな改善です。このモジュールが無いと、同じユーザとして実行されているプロセスを隔てるものがなくなってしまいます ({{man|7|pid_namespaces}} などの他のセキュリティレイヤーがない場合)。

{{Note|デフォルトでは、[[sudo]] を使うなどして、{{ic|ptrace}} を必要とするツールを特権プロセスとして実行することができます。}}

デバッグツールを使う必要がない場合は、システムを堅牢化するために {{ic|kernel.yama.ptrace_scope}} を {{ic|2}} (管理者限定) や {{ic|3}} ({{ic|ptrace}} を禁止) に設定することを検討してください。

=== hidepid ===

{{Warning|
* これは、サンドボックスと [[Xorg]] 内で実行するアプリケーションなど、特定のアプリケーションで問題を発生させる場合があります (回避策を見てください)。
* {{Pkg|systemd}} > 237.64-1 を使用している場合、これは [[D-Bus]]、[[Polkit]]、[[PulseAudio]]、そして [[bluetooth]] で問題を発生させます。
}}

カーネルには、{{ic|proc}} ファイルシステムを {{ic|1=hidepid=}} オプションと {{ic|1=gid=}} オプションを使ってマウントすることで、他のユーザのプロセス (通常、{{ic|/proc}} でアクセス可能) を非特権ユーザから秘匿する機能があります。これらのマウントオプションは https://docs.kernel.org/filesystems/proc.html でドキュメント化されています。

これにより、侵入者が動作中のプロセスの情報 (特権で動作しているデーモンがあるか、他のユーザが機密情報を扱うプログラムを実行しているか、他のユーザがプログラムを実行しているか) を得る作業を複雑化し、ユーザが特定のプログラムを実行しているかどうかを知るのを不可能にし (ただし、そのプログラムがそれ自体の挙動で存在を他者に知られることがないとする)、さらに、貧弱に書かれたプログラムが機密情報をプログラム引数を介して渡したとしてもローカルの盗聴者から守られます。

{{ic|proc}} [[ユーザーとグループ#システムグループ#グループ]] ({{Pkg|filesystem}} パッケージによって提供されています) は、他のユーザのプロセス情報を得ることのできるユーザのホワイトリストとして機能します。ユーザやサービスが自身以外の {{ic|/proc/<pid>}} ディレクトリにアクセスする必要がある場合、そのユーザまたはサービスを[[ユーザーとグループ#グループ管理|proc グループに追加してください]]。

例えば、プロセスの情報を {{ic|proc}} グループに属さない他のユーザから隠すには:

{{hc|/etc/fstab|2=
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
}}

ユーザのセッションを正しく動作させるために、''systemd-logind'' を例外として追加する必要があります:

{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=
[Service]
SupplementaryGroups=proc
}}

=== モジュールのロードを制限する ===

デフォルトの Arch カーネルは {{ic|CONFIG_MODULE_SIG_ALL}} が有効で、{{Pkg|linux}} パッケージの一部としてビルドされた全てのカーネルモジュールに署名します。これにより、カーネルは有効なキーで署名されたモジュールだけをロードするように制限できます。実際、これはローカルでコンパイルされた、もしくは {{Pkg|virtualbox-host-modules-arch}} などのパッケージによって提供された、ツリー外のモジュールは全てロードできないことを意味します。

カーネルモジュールの読み込みは {{ic|1=module.sig_enforce=1}} [[カーネルパラメータ]]を設定することで制限することができます。詳細は[https://docs.kernel.org/admin-guide/module-signing.html カーネルドキュメント]で見られます。

=== kexec を無効にする ===

Kexec は、現在実行中のカーネルを置き換えることを可能にします。

{{hc|/etc/sysctl.d/51-kexec-restrict.conf|2=
kernel.kexec_load_disabled = 1
}}

{{Tip|kexec は {{pkg|linux-hardened}} でデフォルトで無効になっています。}}

=== カーネルロックダウンモード ===

Linux 5.4 から、オプションの[https://mjg59.dreamwidth.org/55105.html ロックダウン機能]がカーネルに[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d 追加されました]。これは、UID 0 (root) とカーネルの間の境界を強化することを目的としています。この機能を有効にすると、ハードウェアやカーネルへの低レベルなアクセスに依存している一部のアプリケーションは動作しなくなる可能性があります。

ロックダウンを使用するには、LSM が初期化され、ロックダウンモードが設定されている必要があります。

[[カーネル#公式サポートカーネル|公式にサポートされているカーネル]]は全て LSM を初期化しますが、ロックダウンモードを強制しません。

{{Tip|有効化されている LSM は {{ic|cat /sys/kernel/security/lsm}} を実行することで確認することができます。}}

ロックダウンには2つの動作モードがあります:

* {{ic|integrity}}: ユーザーランドが実行中のカーネルを変更できるカーネル機能 (kexec、bpf) は無効化されます。
* {{ic|confidentiality}}: ユーザーランドがカーネルから機密情報を抽出するためのカーネルの機能も無効化されます。

特定の脅威モデルで指示がない限り、{{ic|integrity}} を使用することが推奨されます。

実行時にカーネルのロックダウンを有効にするには、以下を実行してください:

# echo ''mode'' > /sys/kernel/security/lockdown

起動時にカーネルのロックダウンを有効にするには、{{ic|1=lockdown=''mode''}} [[カーネルパラメータ]]を使用してください:

{{Note|
* カーネルロックダウンを実行時に無効化することはできません。
* カーネルロックダウンは、[[ハイバネート]]を無効化します。
}}

{{man|7|kernel_lockdown}} も参照してください。

=== Linux Kernel Runtime Guard (LKRG) ===

[https://www.openwall.com/lkrg/ LKRG] ({{AUR|lkrg-dkms}}) は、カーネルの整合性チェックとエクスプロイト行為の検出を行うカーネルモジュールです。

== アプリケーションのサンドボックス化 ==

こちらも参照 [[Wikipedia:ja:サンドボックス (セキュリティ)]]

{{Note|ユーザー名前空間の設定項目 {{ic|CONFIG_USER_NS}} は、現在 {{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}}、および {{Pkg|linux-hardened}} で有効になっています。これが無効だと、一部のアプリケーションで特定のサンドボックス機能が利用できなくなる可能性があります。}}

{{Warning|非特権ユーザー名前空間の使用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) は、{{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}} でデフォルトで有効になっています。これにより、ローカル特権昇格の攻撃対象が大幅に拡大します([https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction AppArmorのWiki] および {{Bug|36969}} を参照。}}

これを軽減するためには、次のいずれかを行ってください:

* 安全なデフォルトを持つ {{Pkg|linux-hardened}} カーネルを使用する、または
* {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] を {{ic|0}} に設定する。

これにより、[[Zoom Meetings|Zoom]] や {{pkg|nsjail}} などのアプリケーションが動作しなくなる場合があることに注意してください。また、システムに {{pkg|bubblewrap}} がインストールされている場合は、{{pkg|bubblewrap-suid}} に置き換える必要があります。詳細は [[Bubblewrap#インストール]] を参照してください。

=== Firejail ===

[[Firejail]] は、アプリケーションやサーバーをサンドボックス化するための使いやすいツールです。元々はブラウザやインターネット向けアプリケーションのために作成されましたが、現在では多くのアプリケーションに対応しています。さまざまな機能を備えたサンドボックス環境を構築するために、suid バイナリとしてインストールされ、ブラックリストとホワイトリストに基づいてターゲットアプリケーションのサンドボックス化された実行環境を構築します。

=== bubblewrap ===

[[bubblewrap]] は、[[Flatpak]] などの非特権コンテナツール向けに開発されたサンドボックスアプリケーションで、Firejail よりもリソース消費と複雑さが大幅に小さいです。ファイルパスのホワイトリスト機能は欠けていますが、bubblewrap はバインドマウントのほか、ユーザー/IPC/PID/ ネットワーク /cgroup 名前空間の作成をサポートしており、シンプルなものから複雑なサンドボックスまで対応可能です。

[[Bubblejail]] サンドボックスは [[bubblewrap]] を基にしており、リソース指向の権限モデルと、権限を調整するためのグラフィカルインターフェースを提供します。

=== chroot ===

手動で [[chroot]] してサンドボックス化されたプロセス環境を作成できます。しかし、これは他のサンドボックス技術に比べて非常に制限されています。そのサンドボックス化の範囲はファイルパスの隔離に限られています。

=== Linux Containers ===

[[Linux Containers]] は、他のオプション([[#完全な仮想化オプション|完全な仮想化オプション]] を除く) よりも多くの隔離が必要な場合に適した選択肢です。LXC は、既存のカーネルの上で擬似 chroot 内で実行され、独自の仮想ハードウェアを持っています。

=== 完全な仮想化オプション ===

[[VirtualBox]]、[[KVM]]、[[Xen]]、または [https://www.qubes-os.org/ Qubes OS](Xen ベース)などの完全仮想化オプションを使用することで、リスクの高いアプリケーションを実行したり、危険なウェブサイトを閲覧したりする場合に、隔離とセキュリティを強化することができます。

==ネットワークとファイアウォール==

===ファイアウォール===

標準の Arch カーネルは [[Wikipedia:Netfilter|Netfilter]] の [[iptables]] および [[nftables]] を使用できますが、これらのサービスはデフォルトで [[有効化]] されていません。システム上で実行されているサービスを保護するために、何らかの形のファイアウォールを設定することを強く推奨します。多くのリソース(ArchWiki など)では、どのサービスを保護するべきかが明示的に記載されていないため、ファイアウォールを有効にすることは良い予防措置となります。

* 一般的な情報については [[iptables]] および [[nftables]] を参照してください。
* iptables ファイアウォールの設定方法については [[シンプルなステートフルファイアウォール]] を参照してください。
* netfilter の設定方法については [[ファイアウォール]] を参照してください。
* Bluetack などの IP アドレスリストをブロックするには [[Ipset]] を参照してください。
* {{Pkg|opensnitch}} は、アプリケーション、ポート、ホストなどによる設定可能なルールをサポートする、構成可能なインバウンドおよびアウトバウンドファイアウォールです。

==== ポートを開く ====

一部のサービスは、開かれたネットワークポートでインバウンドトラフィックを待ち受けます。これらのサービスは、必要最低限のアドレスとインターフェースにのみバインドすることが重要です。リモート攻撃者が [https://samy.pl/slipstream/ ネットワークプロトコルの欠陥を悪用して公開されたサービスにアクセスする] 可能性があります。これは、[https://nvd.nist.gov/vuln/detail/CVE-2019-13450 localhost にバインドされたプロセス] にも発生することがあります。

一般的に、サービスがローカルシステムのみでアクセス可能であれば、非ループバックアドレス(例えば {{ic|0.0.0.0/0}})ではなく、Unix ドメインソケット({{man|7|unix}})や {{ic|localhost}} のようなループバックアドレスにバインドするべきです。

サービスがネットワーク越しに他のシステムからアクセス可能である必要がある場合、厳格な [[ファイアウォール]] ルールでアクセスを制御し、可能な限り認証、認可、暗号化を構成することが重要です。

現在のすべてのオープンポートをリストするには、{{ic|ss -l}} を使用できます。すべてのリスニング中のプロセスとその数値的な TCP および UDP ポート番号を表示するには:

# ss -lpntu

その他のオプションについては、{{man|8|ss}}を参照してください。

===カーネルパラメータ===
ネットワークに影響を与えるカーネルパラメータは [[sysctl]] を使って設定できます。設定方法は [[sysctl#TCP/IP スタックの防御]] を見て下さい。

===SSH===
[[SSH 鍵#パスワードログインの無効化|SSH 鍵を必要]]としない [[Secure Shell]] を使うのは避けましょう。これは[[Wikipedia:ja:総当たり攻撃|総当たり攻撃]]を防ぎます。また、[[Fail2ban]] や [[Sshguard]] はログを監視して [[iptables|iptables ルール]]を書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。

二段階認証によって認証を強化することができます。[[Google Authenticator]] はワンタイムパスコード (OTP) を使用する二段階認証方式を提供します。

[[Secure Shell#root ログインを拒否する|root ログインを拒否する]]のは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。

===DNS===

[[DNSSEC]] や [[DNSCrypt]] を見て下さい。

=== プロキシ ===

プロキシはアプリケーションとネットワークの間に挟まる追加レイヤーとして使われ、信頼できないソースからのデータをサニタイズします。少ない権限でプロキシを動作させることで、エンドユーザー権限で複雑なアプリケーションを実行するよりも攻撃対象を小さくすることができます。

例えば {{Pkg|glibc}} の中に実装されている DNS リゾルバを考えてみてください。(root で実行することもある) アプリケーションにリンクされている DNS リゾルバにバグが存在した場合、リモートコード実行につながる危険があります。[[dnsmasq]] などの DNS キャッシュサーバーをインストールしてプロキシとして使うことで問題を防ぐことが可能です [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]。

=== SSL 証明書の管理 ===

サーバーサイドの SSL 証明書の管理については [[OpenSSL]] や [[Network Security Services]] (NSS) を参照してください。また、関連する [[Let’s Encrypt]] プロジェクトも見てください。

デフォルトのインターネット SSL 証明書のトラストチェーンは {{Pkg|ca-certificates}} パッケージによって提供されています。Arch はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: {{AUR|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) に依存しています。

デフォルトの証明書を変えたいと思うことがあるかもしれません。例えば、[http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ ニュース] を読んで証明書を信頼しないようにしたい場合 (ソースのプロバイダーによって無効になるのを待てない場合)、Arch のインフラを使うことで簡単に設定できます:
# {{ic|.crt}} 形式の証明書を入手してください (例: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; 既存のルート認証局の場合、システム内にあるはずです)。
# {{ic|/etc/ca-certificates/trust-source/blacklist/}} にコピーしてください。
# root で ''update-ca-trust'' を実行してください。

お好きなブラウザを開いて'''信頼できない'''サイトとして表示されれば、ブラックリストが上手く機能しています。

== 物理セキュリティ ==

{{Note|リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。}}

十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで''実用的で''高いレベルのセキュリティを得ることができます。

攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [http://www.breaknenter.org/projects/inception/]。これを防ぐためにできることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識がなく実行されることはほとんどありません。

[[#ディスク暗号化|ディスク暗号化]]はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。

===BIOS をロックダウンする===

BIOS にパスワードを追加することによってリムーバブルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。

=== ブートローダー ===

[[Arch ブートプロセス#ブートローダー|ブートローダー]] を保護することは非常に重要です。保護されていないブートローダは、例えば {{ic|1=init=/bin/sh}} を設定することでログインの制限を回避することができます。[[カーネルパラメータ]] でシェルに直接ブートするようにします。

==== Syslinux ====

Syslinux は[[Syslinux#セキュリティ|ブートローダーのパスワード保護]]をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。

==== GRUB ====

[[GRUB]] はブートローダのパスワードもサポートしています。詳しくは [[GRUB/ヒントとテクニック#GRUB メニューのパスワード保護|GRUB メニューのパスワード保護]] を参照してください。[[GRUB/ヒントとテクニック# GRUB メニューのパスワード保護|暗号化 /boot]] もサポートしていますが、これはブートローダコードの一部だけを暗号化しないままにしています。GRUB の設定、[[カーネル]]、[[initramfs]] は暗号化されています。

==== systemd-boot ====

[[systemd-boot]] は [[#セキュアブート]] が有効な場合、カーネルパラメータの編集を無効にします。代わりの方法として、[[systemd-boot#パスワードで保護されたカーネルパラメータエディタ]] を参照して下さい、より伝統的なパスワードベースのオプションを使用できます。

=== セキュアブート ===

[[セキュアブート]] は [[UEFI]] の機能で、コンピュータが起動するファイルの認証を可能にするものです。これは、起動パーティション内のファイルを置き換えるような、いくつかの [https://ja.wikipedia.org/wiki/%E6%82%AA%E6%84%8F%E3%81%82%E3%82%8B%E3%83%A1%E3%82%A4%E3%83%89%E6%94%BB%E6%92%83 悪意あるメイド攻撃] を防止するのに役立つ。通常、コンピュータにはベンダー (OEM) によって登録されたキーが付属しています。しかし、これを取り外して、コンピュータを「セットアップモード」にし、ユーザーが自分のキーを登録・管理できるようにすることができます。

セキュアブートのページでは、[https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Implementing_Secure_Boot using your own keys] によってセキュアブートを設定する方法を案内しています。

=== トラステッドプラットフォームモジュール(TPM) ===

[[Trusted Platform Module|TPM]] は、暗号鍵が埋め込まれたハードウェア・マイクロプロセッサです。これは、最近のほとんどのコンピュータの基本的な信頼性の根源を形成し、ブートチェーンのエンドツーエンドの検証を可能にします。内部スマートカードとして使用したり、コンピュータ上で動作するファームウェアを証明したり、改ざん防止とブルートフォース耐性のあるストアにユーザーがシークレットに挿入することができます。

=== リムーバブルフラッシュドライブ上のブートパーティション ===

ブートパーティションをフラッシュドライブに置き、それがないとシステムが起動しないようにする、というのはよくあるアイデアです。このアイデアの支持者はしばしば [[セキュリティ#ディスク暗号化|ディスク暗号化]] を併用し、ブートパーティションに置かれた [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USBdetached encryption headers] を使っている人もいます。

この方法は [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USB encrypting /boot] と統合することも可能です。

=== 自動ログアウト ===
[[Bash]] または [[Zsh]] を使っている場合、{{ic|TMOUT}} によってタイムアウトによるシェルからの自動ログアウトを設定できます。

例えば、以下は仮想コンソールから自動でログアウトします (X11 のターミナルエミュレータからはログアウトしません):

{{hc|/etc/profile.d/shell-timeout.sh|<nowiki>
TMOUT="$(( 60*10 ))";
[ -z "$DISPLAY" ] && export TMOUT;
case $( /usr/bin/tty ) in
/dev/tty[0-9]*) export TMOUT;;
esac
</nowiki>}}

(X のコンソールも含めて) 全ての Bash/Zsh プロンプトでタイムアウトさせたい場合は、次を使って下さい:

$ export TMOUT="$(( 60*10 ))";

シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや {{ic|TMOUT}} をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。

=== 不正なUSBデバイスから保護する ===

[[Usbguard]] は、デバイスの属性に基づく基本的なホワイトリストおよびブラックリスト機能を実装することで、不正な USB デバイス (別名 [https://ja.wikipedia.org/wiki/BadUSB BadUSB], [https://github.com/samyk/poisontap PoisonTap] または [https://lanturtle.com/ LanTurtle]) からコンピューターを保護できるソフトウェアフレームワークです。

=== 揮発性データの収集 ===

電源が入っているコンピュータは、[https://fedvte.usalearning.gov/courses/CSI/course/videos/pdf/CSI_D01_S05_T01_STEP.pdf volatile data collection] に対して脆弱である可能性があります。コンピュータの電源を入れる必要がない時や、コンピュータの物理的な安全性が一時的に損なわれる場合(例:セキュリティチェックポイントを通過する時)には、コンピュータの電源を完全に切ることがベストプラクティスです。

== パッケージ ==

=== パッケージの認証 ===
パッケージの署名が適正に使われていないと [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview パッケージマネージャへの攻撃] が考えられ、さらに [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html 適切な署名システム] を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは [[Pacman-key]] を見て下さい。

=== アップグレード ===

定期的に [[システムメンテナンス#システムのアップグレード|システムのアップグレード]] を行うことが重要です。

=== 脆弱性アラートの確認 ===

National Vulnerability Database が提供する Common Vulnerabilities and Exposure (CVE) Security Alert の更新を購読し、[https://nvd.nist.gov/download.cfm NVD Download webpage] で見つけてください。[https://security.archlinux.org/ Arch Linux Security Tracker] は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットを表形式でまとめた、特に有用なリソースです。ツール {{Pkg|arch-audit}} は実行中のシステムに影響を与える脆弱性をチェックするために使われます。グラフィカルなシステムトレイである {{Pkg|arch-audit-gtk}} も使うことができます。[https://wiki.archlinux.org/title/Arch_Security_Team Arch Security Team]も参照してください。

特にメインレポジトリや AUR 以外の手段でソフトウェアをインストールしている場合は、あなたが使っているソフトウェアのリリース通知を購読することも検討すべきです。いくつかのソフトウェアには、セキュリティに関する通知を受け取るために購読できるメーリングリストがあります。ソースコードホスティングサイトはしばしば新しいリリースの RSS フィードを提供しています。

=== パッケージの再ビルド ===

攻撃対象領域を減らす手段として、パッケージをリビルドし、不要な関数や機能を削除することができます。例えば、{{Pkg|bzip2}} は [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189] を回避するために {{ic|bzip2recover}} を使わずにリビルドすることが可能です。カスタムハードニングフラグは、手動またはラッパーを介して適用することもできます。

{| class="wikitable"
! フラグ !! 目的
|-
| -D_FORTIFY_SOURCE=2 || ランタイムバッファオーバーフローの検出
|-
| -D_GLIBCXX_ASSERTIONS || C++ の文字列とコンテナのランタイム境界チェック
|-
| -fasynchronous-unwind-tables || バックトレースの信頼性向上
|-
| -fexceptions || テーブルベースのスレッドキャンセルを有効にする
|-
| -fpie -Wl,-pie || 実行可能ファイルに対する完全な ASLR
|-
| -fpic -shared || 共有ライブラリのテキスト再配置を行わない
|-
| -fplugin=annobin || ハードニング品質管理用データの作成
|-
| -fstack-clash-protection || スタックオーバーフロー検出の信頼性向上
|-
| -fstack-protector or -fstack-protector-all || スタックスマッシュプロテクター
|-
| -fstack-protector-strong || 同様に
|-
| -g || デバッグ情報を生成する
|-
| -grecord-gcc-switches || デバッグ情報にコンパイラのフラグを格納する
|-
| -mcet -fcf-protection || 制御フローの完全性保護
|-
| -O2 || 推奨される最適化
|-
| -pipe || 一時ファイルを回避し、ビルドを高速化します。
|-
| -Wall || 推奨されるコンパイラの警告
|-
| -Werror=format-security || 安全でない可能性のあるフォーマット文字列の引数を拒否する
|-
| -Werror=implicit-function-declaration || 関数プロトタイプの欠落を却下する
|-
| -Wl,-z,defs || アンダーリンクの検出と拒否
|-
| -Wl,-z,now || 遅延バインディングを無効にする
|-
| -Wl,-z,relro || 移設後の読み出し専用セグメント
|}

* [https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/ Flags and info ソース]

== 参照 ==

* [https://security.archlinux.org/ Arch Linux セキュリティトラッカー]
* ArchWiki のセキュリティアプリケーションのリスト: [[アプリケーション一覧/セキュリティ]]
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux ワークステーションのセキュリティチェックリスト]
* [https://www.privacytools.io/ privacytools.io Privacy Resources]
* [https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/index.html Red Hat Enterprise Linux 7 セキュリティガイド]
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Debian 安全化マニュアル (PDF)]
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]

PKGBUILD

2025-04-19T15:46:33Z

Oech3: /* 整合性 */

[[Category:パッケージ開発]]
[[cs:PKGBUILD]]
[[da:PKGBUILD]]
[[el:PKGBUILD]]
[[en:PKGBUILD]]
[[es:PKGBUILD]]
[[fa:PKGBUILD]]
[[fr:PKGBUILD]]
[[it:PKGBUILD]]
[[pl:PKGBUILD]]
[[pt:PKGBUILD]]
[[ru:PKGBUILD]]
[[sr:PKGBUILD]]
[[zh-hans:PKGBUILD]]
[[zh-hant:PKGBUILD]]
{{Related articles start}}
{{Related|Arch パッケージングスタンダード}}
{{Related|Arch Build System}}
{{Related|パッケージの作成}}
{{Related|.SRCINFO}}
{{Related|:カテゴリ:パッケージ開発}}
{{Related|カスタムローカルリポジトリ}}
{{Related|pacman ヒント}}
{{Related|Arch User Repository}}
{{Related|makepkg}}
{{Related|pacman}}
{{Related articles end}}

この記事では {{ic|PKGBUILD}} の中でメンテナが定義できる変数について説明します。{{ic|PKGBUILD}} の関数や一般的なパッケージの作成については [[パッケージの作成]] を参照してください。{{man|5|PKGBUILD}} も読んで下さい。

{{ic|PKGBUILD}} はシェルスクリプトで、[[Arch Linux]] のパッケージが必要とするビルド情報を含んでいます。

Arch Linux のパッケージは [[makepkg]] ユーティリティを使ってビルドされます。''makepkg'' を実行すると、カレントディレクトリにある {{ic|PKGBUILD}} ファイルを探し、その中の指示に従ってコンパイルするか、パッケージアーカイブ ({{ic|''pkgname''.pkg.tar.zst}}) を構築するためのファイルを入手します。出来上がったパッケージにはバイナリファイルとインストール手順が含まれ、[[pacman]] で簡単にインストールできます。

必須の変数は、{{ic|pkgname}}、{{ic|pkgver}}、{{ic|pkgrel}}、および {{ic|arch}} です。 {{ic|license}} は、パッケージをビルドするために厳密に必要というわけではありませんが、''makepkg'' が存在しない場合に警告を生成するため、他のユーザーと共有する {{ic|PKGBUILD}} には推奨されます。

ここで指定された順番で {{ic|PKGBUILD}} の変数を定義するのが一般的なやり方です。しかし、正しい [[Bash]] 構文が使われている限り、これは必須ではありません。

{{Tip|{{ic|PKGBUILD}} によくあるパッケージングの間違いがないかチェックするには [[namcap]] を使って下さい。}}

== パッケージ名 ==

=== pkgbase ===

通常のパッケージをビルドするときは、この変数を {{ic|PKGBUILD}} で明示的に宣言してはいけません:
この変数のデフォルトの値は [[PKGBUILD#pkgname|pkgname]] の値です。

[https://man.archlinux.org/man/PKGBUILD.5#PACKAGE_SPLITTING 分割パッケージ] をビルドするときは、この変数を使って ''makepkg'' の出力やソースだけの tarball の名前付けにパッケージのグループを参照するために使う名前を明示的に指定できます。この値はハイフンで始めることはできません。指定しない場合、値はデフォルトで {{ic|pkgname}} 配列の最初の要素になります。

分割パッケージのすべてのオプションとディレクティブのデフォルトは {{ic|PKGBUILD}} で指定されたグローバルな値です。ただし、以下のものは各分割パッケージのパッケージング関数の中でオーバーライドすることができます。[[PKGBUILD#pkgdesc|pkgdesc]], [[PKGBUILD#arch|arch]], [[PKGBUILD#url|url]], [[PKGBUILD#license|license]], [[PKGBUILD#groups|groups]], [[PKGBUILD#depends|depends]], [[PKGBUILD#optdepends|optdepends]], [[PKGBUILD#provides|provides]], [[PKGBUILD#conflicts|conflicts]], [[PKGBUILD#replaces|replaces]], [[PKGBUILD#backup|backup]], [[PKGBUILD#options|options]], [[PKGBUILD#install|install]] そして [[PKGBUILD#changelog|changelog]]

=== pkgname ===

パッケージの名前、例えば {{ic|1=pkgname='foo'}} か、分割パッケージの場合は名前の配列、例えば {{ic|1=pkgname=('foo' 'bar')}} を指定します。パッケージ名は小文字の英数字と以下の文字のみで構成されている必要があります。{{ic|@._+-}} は小文字の英数字と以下の文字で構成されています。(アットマーク、ドット、アンダースコア、プラス、ハイフン) ハイフンやドットで名前を始めることはできません。一貫性を保つために、{{ic|pkgname}} はソフトウェアのソース tarball の名前と一致させるべきです。例えば、ソフトウェアが {{ic|foobar-2.5.tar.gz}} に入っているならば、{{ic|1=pkgname=foobar}} と記述して下さい。

== バージョン ==

=== pkgver ===
パッケージのバージョン。この値はパッケージの作成者によって公開されたバージョンと同じでなくてはなりません。文字と数字、ピリオドとアンダーバーを使えますがハイフンは使うことができません。パッケージの作成者がバージョンのナンバリングにハイフンを使っている時は、アンダーバーに置き換えてください。例えば、バージョンが ''0.99-10'' の場合、''0.99_10'' に変更してください。{{ic|pkgver}} を後で PKGBUILD で使うときに、ダッシュの代わりにアンダーラインを使うのは簡単にできます例:
source=($pkgname-${pkgver//_/-}.tar.gz)

{{Note|ソフトウェアの開発元が {{ic|30102014}} のようなタイムスタンプによるバージョン付けをしている場合、日付の順序を逆にしてください: {{ic|20141030}} ([[Wikipedia:ISO 8601|ISO 8601]] 形式)。そうしないと新しいバージョンが認識されません。}}

{{Tip|
* [[pacman]] パッケージに含まれている [https://www.archlinux.org/pacman/vercmp.8.html vercmp] を使うことでバージョンの優先度をテストできます。
* PKGBUILD に {{ic|pkgver()}} 関数を定義することで [[makepkg]] は自動的に pkgver 変数を [http://allanmcrae.com/2013/04/pacman-4-1-released/ 更新] します。詳しくは [[VCS パッケージガイドライン#関数 pkgver()]] を見て下さい。}}

=== pkgrel ===
Arch Linux におけるパッケージのリリース番号。パッケージの同じバージョンを続けてビルドするときにそれを区別するためにこの値を使います。新しいバージョンのパッケージが始めてリリースされたとき、'''リリース番号は1からスタートします'''。{{ic|PKGBUILD}} ファイルに修正や最適化が加えられるたびに、パッケージは'''再リリース'''され'''リリース番号'''は1づつ増やされます。新しいバージョンのパッケージが出たら、リリース番号は1にリセットします。

=== epoch ===
{{Warning|{{ic|epoch}} はどうしても必要なときだけ使って下さい。}}

バージョン番号が更新を引き起こさないときでも、(epoch が低い) 以前のバージョンよりもパッケージを新しいものだと強制的に見せるために使用されます。この変数の値は正の整数でなくてはなりません。指定されていない場合、デフォルトの値は 0 になります。パッケージのナンバリングの規則が変更されたり、バージョンの通常の比較ルールを破壊したいときに有用です。例:

{{hc|1=
pkgver=5.13
pkgrel=2
epoch=1
|2=
1:5.13-2
}}

バージョンの比較についての詳細は [https://www.archlinux.org/pacman/pacman.8.html pacman(8)] を見て下さい。

== 汎用 ==

=== pkgdesc ===

パッケージの説明。これは 80 文字以下にすることをお勧めします。また、アプリケーション名がパッケージ名と異なる場合を除き、パッケージ名を自己参照的に含めないでください。たとえば、{{ic|1=pkgdesc="Nedit is a text editor for X11"}} の代わりに {{ic|1=pkgdesc="Text editor for X11"}} を使用します。

また、キーワードを賢く使用して、関連する検索クエリに表示される可能性を高めることも重要です。

=== arch ===
{{ic|PKGBUILD}} がビルド・動作するアーキテクチャの文字列。現在、{{ic|i686}} と {{ic|x86_64}} が使えます。ただし、[https://archlinuxarm.org/ Arch Linux ARM] などのプロジェクトでは他のアーキテクチャもサポートしています: {{ic|arm}} (armv5), {{ic|armv6h}} (armv6 hardfloat), {{ic|armv7h}} (armv7 hardfloat), {{ic|aarch64}} (armv8 64bit)。

アーキテクチャに依存しないパッケージ (シェルスクリプト, フォント, テーマなど) には {{ic|any}} を使うことができます。{{ic|-i686}} や {{ic|-x86_64}} とは対照的に、一度ビルドしたら他のアーキテクチャでも使うことができるようなパッケージには {{ic|-any}} を指定してください。全てのアーキテクチャに対応するようにパッケージをコンパイルすることができても、特定のアーキテクチャに向けてコンパイルされる場合は、Arch によって公式にサポートされているアーキテクチャを指定してください: {{ic|1=arch=('i686' 'x86_64')}}。

{{ic|$CARCH}} 変数を使うことで、ビルドや、変数を定義する時にターゲットとするアーキテクチャを知ることができます。{{bug|16352}} を参照してください。例:

depends=(foobar)
if test "$CARCH" == x86_64; then
depends+=(lib32-glibc)
fi

=== url ===
パッケージされるソフトウェアの公式サイトの URL。

=== license ===

ソフトウェアが配布されるライセンス。{{ic|[core]}} の {{pkg|licenses}} パッケージは {{ic|/usr/share/licenses/common}} によく使われるライセンスを保存しています、例えば {{ic|/usr/share/licenses/common/GPL}} パッケージのライセンスがここに保存されているライセンスのどれかのときは、ディレクトリの名前を設定してください、例えば {{ic|1=license=('GPL')}} 適切なライセンスが公式の {{Pkg|licenses}} パッケージに含まれていない場合は、やる必要があることがいくつかあります:

# ライセンスファイルを次のディレクトリに含めなくてはなりません: {{ic|/usr/share/licenses/''pkgname''/}}, 例 {{ic|/usr/share/licenses/foobar/LICENSE}}
# ソース tarball にライセンスの詳細が含まれずウェブサイトなど他のところで示されている場合は、ライセンスをファイルにコピーしてそのファイルを含めて下さい。
# {{ic|license}} 行に {{ic|custom}} を追加してください。任意で、{{ic|custom}} を {{ic|custom:ライセンスの名前}} にすることができます。あるライセンスが ({{ic|[community] を含む}}) 公式リポジトリの2つ以上のパッケージで使われると、{{Pkg|licenses}} パッケージに入れられます。
* 特別な事例として [[Wikipedia:ja:BSDライセンス|BSD]], [[Wikipedia:ja:MIT License|MIT]], [[Wikipedia:ja:zlib License|zlib/png]], [[Wikipedia:ja:Python Software Foundation License|Python]] ライセンスは {{pkg|licenses}} パッケージに含められていません。{{ic|license}} 行の目的のために、一般的なライセンス ({{ic|1=license=('BSD')}}, {{ic|1=license=('MIT')}}, {{ic|1=license=('ZLIB')}}, {{ic|1=license=('Python')}}) として扱われておきながらそれぞれ固有の copyright 行を持っているために技術的にカスタムライセンスになっています。これら4つのライセンスを使っている全てのパッケージは {{ic|/usr/share/licenses/''pkgname''}} 内にそのライセンスを保存しておく必要があります。パッケージによってはライセンスがひとつだけではないこともあります。そのような場合は、license 行に複数のエントリを書くことができます、例えば {{ic|1=license=('GPL' 'custom:name of license')}}
* さらに、(L)GPL には多くのバージョンと組み合わせが存在します。(L)GPL ソフトウェアで使えるのは:
** (L)GPL - (L)GPLv2 とそれ以降のバージョン
** (L)GPL2 - (L)GPL2 のみ
** (L)GPL3 - (L)GPL3 とそれ以降のバージョン
* license が決められていないと、{{ic|PKGBUILD.proto}} は {{ic|unknown}} を使うことを提案します。ただし、ソフトウェアが利用できるかできないかについてはアップストリームに連絡をすべきです。

{{Tip|ソフトウェアの作者によってはライセンスファイルを作らずに普通の {{ic|ReadMe.txt}} の中に配布ルールについて記述しているかもしれません。{{Ic|build()}} フェイズの時に、次のようにすることでファイルにこの情報を展開することが可能です: {{Ic|sed -n '/'''This software'''/,/''' thereof.'''/p' ReadMe.txt > LICENSE}}}}

こちらも参照 [[ノンフリーアプリケーションパッケージガイドライン]]

フリーおよびオープンソースソフトウェアライセンスに関する追加情報と展望は、次のページで見つけることができます。

* [[Wikipedia:ja:自由ソフトウェアライセンス|自由ソフトウェアライセンス]]
* [[Wikipedia:Comparison of free and open-source software licenses]]
* [https://www.softwarefreedom.org/resources/2008/foss-primer.html オープンソースおよびフリーソフトウェアプロジェクトの法的問題の入門書]
* [https://www.gnu.org/licenses/license-list.html GNU Project - さまざまなライセンスとそれらについての解説]
* [https://www.debian.org/legal/licenses/ Debian - ライセンス情報]
* [https://www.opensource.org/licenses/alphabetical Open Source Initiative - 名前別ライセンス]

=== groups ===

パッケージが属する [[メタパッケージとパッケージグループ|group]] たとえば、{{Grp|plasma}} をインストールすると、そのグループに属するすべてのパッケージがインストールされます。

== 依存関係 ==

{{Note|アンダーバーとアーキテクチャの名前を付けることで、特定のアーキテクチャだけの依存パッケージを追加することができます。例: {{ic|1=depends_x86_64=()}}, {{ic|1=optdepends_x86_64=()}}。}}

=== depends ===
ソフトウェアを実行する前にインストールする必要があるパッケージの名前を示す文字列。ソフトウェアが依存パッケージの最低必要バージョンがあるときは、{{ic|1=>=}} 演算子を使ってこれを表して下さい、例 {{ic|1=depends=('foobar>=1.8.0')}}。あなたのソフトウェアが依存している他のパッケージの依存にすでに含まれているパッケージを depends に加える必要はありません。例えば、{{pkg|gtk2}} は {{pkg|glib2}} と {{pkg|glibc}} に依存しています。しかしながら、{{pkg|glibc}} は {{pkg|glib2}} の依存にあるので {{pkg|gtk2}} の依存として {{pkg|glibc}} を含める必要はありません。

=== optdepends ===
ソフトウェアを機能させるのには必要ないが機能を追加することができるパッケージの名前の文字列。それぞれのパッケージが提供する機能の説明も短く書いておいて下さい。例えば {{ic|optdepends}} は以下のようになります:
optdepends=('cups: printing support'
'sane: scanners support'
'libgphoto2: digital cameras support'
'alsa-lib: sound support'
'giflib: GIF images support'
'libjpeg: JPEG images support'
'libpng: PNG images support')

===makedepends===
ソフトウェアをビルドするためにインストールする必要はあるが、インストール後にソフトウェアを使うために残しておく必要はないパッケージの名前。{{ic|depends}} 行と同じフォーマットを使ってパッケージの最小必要バージョンを指定できます。

{{Note|既に {{ic|depends}} に含まれているパッケージを指定する必要はありません。}}
{{Warning|makepkg でビルドする際 {{Grp|base-devel}} グループは既にインストールされているものと前提されます。"base-devel" のパッケージを {{ic|makedepends}} 行に入れては'''いけません'''。}}

=== checkdepends ===
テストスイートを実行するときに必要だが普通の実行時には必要ないパッケージの文字列。このリストのパッケージは depends と同じフォーマットに従います。[[パッケージの作成#関数 check()|check()]] 関数が makepkg によって実行される時だけこの依存関係が考慮されます。

== パッケージの関係性 ==

{{Note|アンダーバーとアーキテクチャの名前を付けることで、特定のアーキテクチャだけのパッケージの関係性を追加することができます。例: {{ic|1=provides_x86_64=()}}, {{ic|1=conflicts_x86_64=()}}}}

=== provides ===

パッケージの機能を提供するパッケージ (もしくは {{Ic|cron}} や {{Ic|sh}} などの仮想パッケージ) の名前の文字列。同じものを提供するパッケージは互いに衝突しないかぎり同時にインストールすることができます。

{{Note|この変数を使う場合は、バージョンによって影響を受ける依存関係がある場合パッケージが提供するバージョン ({{ic|pkgver}} と恐らく {{ic|pkgrel}}) を追加してください。例えば、''qt'' にモディファイを加えて ''qt'' を提供する ''qt-foobar'' バージョン 3.3.8 という名前で作成するときは、{{ic|provides}} 行は {{ic|1=provides=('qt=3.3.8')}} のようにしてください。{{ic|1=provides=('qt')}} とすると ''qt'' の特定バージョンを必要とする依存関係が破壊されることになります。{{ic|provides}} 行に {{ic|pkgname}} を加えないでください、自動で追加されます。}}

=== conflicts ===

インストールするとパッケージと問題が生じるパッケージの名前の文字列。この名前を持つパッケージとこの名前の仮想パッケージを {{Ic|provides}} に入れている全てのパッケージが削除されます。{{ic|depends}} 行と同じフォーマットを使って衝突するパッケージのバージョンプロパティを指定することもできます。

競合は、{{ic|pkgname}} および {{ic|provides}} 配列で指定された名前に対してチェックされることに注意してください。したがって、パッケージが {{ic|provides}} に {{ic|''foo''}} 機能を備えている場合、{{ic|conflicts}} 配列に {{ic|''foo''}} を指定すると、あなたのパッケージと、{{ic|provides}} 配列に {{ic|''foo''}} を含む他のすべてのパッケージとの間の競合 (つまり、競合するすべてのパッケージ名を {{ic|flicts}} 配列に指定する必要はありません) 具体的な例を挙げてみましょう。

* {{Pkg|netbeans}} は暗黙的に {{ic|netbeans}} を {{ic|pkgname}} 自身として提供しています。
* {{AUR|netbeans-cpp}} は {{ic|netbeans}} を提供し、{{ic|netbeans}} と衝突します。
* {{AUR|netbeans-php}} は {{ic|netbeans}} を提供し、{{ic|netbeans}} と衝突しますが、同じ機能を提供するパッケージは暗黙のうちに衝突するので、明示的に {{AUR|netbeans-cpp}} と衝突する必要はありません。

パッケージが {{ic|provides}} 配列を介して同じ機能を提供する場合、代替パッケージを {{ic|conflicts}} 配列に明示的に追加する場合と追加しない場合には違いがあります。{{ic|conflicts}} 配列が明示的に宣言されている場合、同じ機能を提供する 2 つのパッケージが ''代替'' とみなされます。{{ic|conflicts}} 配列が欠落している場合、同じ機能を提供する 2 つのパッケージが ''共存している可能性がある'' とみなされます。パッケージャは、{{ic|conflicts}} 変数を宣言するかどうかを決定する際に、{{ic|provides}} 変数の内容を常に無視する必要があります。

=== replaces ===

例えば {{Pkg|wireshark-qt}} は {{ic|1=replaces=('wireshark')}} を使います。同期する時、''pacman'' はインストールされたパッケージがリポジトリで {{ic|replaces}} にマッチする別のパッケージに出会ったら即座に置き換えます。既にあるパッケージの別バージョンを提供したり AUR にアップロードする時は {{ic|conflicts}} と {{ic|provides}} 配列を使ってください。

== その他 ==

=== backup ===
ユーザーが作成した変更を含んだり、パッケージのアップグレードや削除が行われても維持されるファイルの文字列、主に {{ic|/etc}} 内の設定ファイル用。

アップデート時、既存のファイル(ユーザーによって修正されたファイル)を上書きしないために新しいバージョンは {{ic|file.pacnew}} として保存されます。同じく、パッケージの削除時、パッケージを削除するのに {{ic|pacman -Rn}} コマンドを使わなければ、ユーザーが修正したファイルは {{ic|file.pacsave}} として残されます。

この行のファイルパスは絶対パス (例: {{ic|/etc/pacman.conf}}) ではなく相対パス (例: {{ic|etc/pacman.conf}}) にしてください。[[Pacnew と Pacsave ファイル]]も参照。

=== options ===
この文字列を使うと {{Ic|/etc/makepkg.conf}} で定義された {{ic|makepkg}} のデフォルトの挙動の一部を上書きできます。オプションをセットするには、文字列にオプションの名前を入れて下さい。デフォルトの挙動を逆にするには、オプションの前に '''{{ic|!}}''' を付けて下さい。options には以下のオプションを置くことが可能です:

* {{ic|strip}} - バイナリとライブラリからシンボルを除去。プログラムやライブラリでデバッガを頻繁に使う時は、このオプションを無効にすると便利です。
* {{ic|docs}} - {{ic|/doc}} ディレクトリを保存。
* {{ic|libtool}} - パッケージに ''libtool'' ({{ic|.la}}) ファイルを残す。
* {{ic|staticlibs}} - パッケージに静的ライブラリ (.a) のファイルを残す。
* {{ic|emptydirs}} - パッケージに空のディレクトリを残す。
* {{ic|zipman}} - ''man'' と ''info'' ページを ''gzip'' で圧縮。
* {{ic|purge}} - パッケージの {{ic|PURGE_TARGETS}} 変数で指定されたファイルを削除。
* {{ic|upx}} - UPX を使って実行可能バイナリを圧縮。{{ic|UPXFLAGS}} 変数を指定することで UPX に追加オプションを渡せます。
* {{ic|ccache}} - ビルド中の {{ic|ccache}} の使用を許可。{{ic|ccache}} を使ってビルドすると問題が起こるパッケージに無効化の {{ic|!ccache}} を使うと便利です。
* {{ic|distcc}} - ビルド中の {{ic|distcc}} の使用を許可。{{ic|distcc}} を使ってビルドすると問題が起こるパッケージに無効化の {{ic|!distcc}} を使うと便利です。
* {{ic|buildflags}} - ビルド中にユーザー定義の {{ic|buildflags}} (CFLAGS, CXXFLAGS, LDFLAGS) の使用を許可。カスタムした {{ic|buildflags}} を使ってビルドすると問題が起こるパッケージに無効化の {{ic|!buildflags}} を使うと便利です。
* {{ic|makeflags}} - ビルド中にユーザー定義の {{ic|makeflags}} の使用を許可。カスタムした {{ic|makeflags}} を使ってビルドすると問題が起こるパッケージに無効化の {{ic|!makeflags}} を使うと便利です。

=== install ===
パッケージに含まれる {{ic|.install}} スクリプトの名前。{{ic|pkgname}} と同じ名前にしてください。パッケージのインストール・削除・アップグレードの際に、pacman はパッケージごとにスクリプトを保存・実行する機能があります。スクリプトには、実行される段階によって以下の関数を含めることができます:

* {{ic|pre_install}} - ファイルが展開される前にスクリプトを実行。1つの引数が渡されます: 新しいパッケージのバージョン。
* {{ic|post_install}} - ファイルが展開された後にスクリプトを実行。1つの引数が渡されます: 新しいパッケージのバージョン。
* {{ic|pre_upgrade}} - ファイルが展開される前にスクリプトを実行。2つの引数が渡されます: 新しいパッケージのバージョン, 古いパッケージのバージョン。
* {{ic|post_upgrade}} - ファイルが展開された後にスクリプトを実行。2つの引数が渡されます: 新しいパッケージのバージョン, 古いパッケージのバージョン。
* {{ic|pre_remove}} - ファイルが削除される前にスクリプトを実行。1つの引数が渡されます: 古いパッケージのバージョン。
* {{ic|post_remove}} - ファイルが削除された後にスクリプトを実行。1つの引数が渡されます: 古いパッケージのバージョン。

それぞれの関数は pacman のインストールディレクトリの中に [[chroot]] されて実行されます。[https://bbs.archlinux.org/viewtopic.php?pid=913891 このスレッド] を見て下さい。

{{Tip|{{ic|.install}} のプロトタイプが {{ic|/usr/share/pacman/proto.install}} にあります。}}

{{Note|スクリプトの中で {{ic|exit}} を実行しないでください。スクリプト内の関数が実行できなくなってしまいます。}}

=== changelog ===
パッケージの変更履歴の名前。インストールされたパッケージの変更履歴を表示するには:
$ pacman -Qc ''pkgname''

{{Tip|変更履歴ファイルのプロトタイプが {{ic|/usr/share/pacman/ChangeLog.proto}} にあります。}}

== ソース ==

{{Note|アンダーバーとアーキテクチャの名前を追加することで特定のアーキテクチャのソースを追加することができます。例: {{ic|1=source_x86_64=()}}。そのアーキテクチャのソースと対応するチェックサムも指定してください。例: {{ic|1=sha256sums_x86_64=()}}。}}

=== source ===
パッケージをビルドするのに必要なファイルの文字列。ソフトウェアのソースの場所を入れる必要があり、多くの場合 HTTP や FTP の URL です。前に設定した {{ic|pkgname}} や {{ic|pkgver}} 変数をここで使うことができます (例: {{ic|<nowiki>source=(http://example.com/$pkgname-$pkgver.tar.gz)</nowiki>}})。

自作のパッチなど、オンザフライでダウンロードできないファイルを供給する必要があるときは、{{ic|PKGBUILD}} ファイルがあるところと同じディレクトリにそのファイルを入れて source にファイル名を追加するだけです。ここに追加したパスはすべて {{ic|PKGBUILD}} があるディレクトリから相対的に考えられます。本当のビルドプロセスが始まる前に、この行で参照されている全てのファイルがダウンロードされるか存在を確認します。もしファイルが欠けている場合は {{ic|makepkg}} は次に進みません。

{{Tip|ダウンロードされるファイルに異なる名前を指定するには - GET パラメータがある URL などが原因でダウンロードされるファイルの名前が異なる場合 - 次の構文を使って下さい: {{Ic|''filename''::''fileuri''}}, 例えば: {{Ic|1=source=("project_name::<nowiki>hg+https://googlefontdirectory.googlecode.com/hg/</nowiki>"}}。}}

{{Note|''.install'' ファイルは source に記述してはいけません。}}

拡張子が ''.sig'', ''.sign'', ''.asc'' のファイルを source 配列に指定した場合、''makepkg'' はそれを PGP 署名として認識して、ソースファイルの整合性を確認するのに自動的に用います。

=== noextract ===
{{ic|source}} 行で {{ic|makepkg}} によって圧縮フォーマットを展開してはいけないファイルの文字列。{{Pkg|libarchive}} は {{Pkg|unzip}} とは違い全てのファイルをランダムアクセスではなくストリームで処理するので、{{ic|/usr/bin/bsdtar}} によって扱えない圧縮ファイルに noextract を使うのがほとんどです。こういった場合には他の解凍ツール (例: {{ic|lrzip}} など) を {{ic|makedepends}} に追加して [[パッケージの作成#関数 prepare()|prepare()]] 関数の最初の行でソースの圧縮ファイルを手動で展開する必要があります。例えば:

prepare() {
lrzip -d ''source''.tar.lrz
}

{{ic|source}} 行には URL を指定することが可能ですが、{{ic|noextract}} にはファイル名の一部'''だけ'''を指定します。例えば、以下のようにすることができます ([https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/grub grub2 の PKGBUILD] から引用):

source=(<nowiki>"http://ftp.archlinux.org/other/grub2/grub2_extras_lua_r20.tar.xz"</nowiki>)
noextract=("grub2_extras_lua_r20.tar.xz")

''何も展開しない''ようにするには、以下のように工夫してください ([https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/firefox-i18n#n123 firefox-i18n] から引用):

noextract=(${source[@]%%::*})

=== validpgpkeys ===
PGP フィンガープリントの配列。validpgpkeys を使用した場合、''makepkg'' は validpgpkeys に記載されている鍵の署名だけを使うようにして鍵束の値は無視します。ソースファイルが副鍵で署名されていた場合、''makepkg'' は主鍵を使って比較します。

指定できるのは完全なフィンガープリントだけです。全て大文字で空白を含めてはいけません。

{{note|{{ic|gpg --list-keys --fingerprint <KEYID>}} で指定した鍵のフィンガープリントを確認できます。}}

== 整合性 ==

以下の変数はどれもチェックサム文字列を指定するようになっており、[[#source|source]] 配列に書かれたファイルの整合性を確認するのに使われます。{{ic|SKIP}} とすることで特定のファイルのチェックサムを確認しないようにできます。

チェックサムの種類と値は、リリースアナウンスなど上流から提供されたものを常に使用する必要があります。複数のタイプが利用可能な場合は、最も強力なチェックサムが優先されます。{{ic|sha512}} よりも {{ic|b2}}, {{ic|sha384}} よりも {{ic|sha384}}, {{ic|sha256}} よりも {{ic|sha512}} を優先してください, {{ic|sha224}} に対して {{ic|sha256}}、{{ic|sha1}} に対して {{ic|sha224}}、{{ic|md5}} に対して {{ic|sha1}}、および {{ic|md5}} 以上 {{ic|ck}}} があります。これは、上流のアナウンスからパッケージのビルドまで、ダウンロードしたファイルの完全性を保証するために最適な方法です。

{{Note|さらに、上流が [[Wikipedia:ja:デジタル署名|デジタル署名]] を利用可能にしたら、署名ファイルを [[#source|source]] 配列に、PGP 鍵指紋を [[#validpgpkeys|validpgpkeys]] 配列に追加する必要があります。これにより、ビルド時にファイルの認証ができるようになります。}}

これらの変数の値は [[makepkg]] の {{ic|-g}}/{{ic|--geninteg}} オプションで自動生成され、一般に {{ic|makepkg -g >> PKGBUILD}} で追加されます。{{Pkg|pacman-contrib}} の {{man|8|updpkgsums}} コマンドは {{ic|PKGBUILD}} 内のどこにあっても変数を更新することが可能です。どちらのツールも {{ic|PKGBUILD}} に既に設定されている変数を使い、設定されていない場合は {{ic|sha256sums}} にフォールバックします。

使用するファイルの整合性チェックは {{ic|/etc/makepkg.conf}} の {{ic|INTEGRITY_CHECK}} オプションで設定することができます。 {{man|5|makepkg.conf}} を参照してください。

{{Note|追加のアーキテクチャ固有の配列は、アンダースコアとアーキテクチャ名を付加することで追加できます、例えば {{ic|1=sha256sums_x86_64=() }}}}

=== cksums ===
{{ic|source}} 配列にリストされているファイルの [[Wikipedia:ja:巡回冗長検査|CRC32]] チェックサム (UNIX 標準 [[Wikipedia:ja:Cksum_(UNIX)|cksum]] より)

=== md5sums ===
{{ic|source}} 行に含まれるファイルの 128 ビット [[Wikipedia:ja:MD5|MD5]] チェックサムの文字列。

=== sha1sums ===
{{ic|source}} 行に含まれるファイルの 160ビットの [[Wikipedia:SHA-1|SHA-1]] チェックサムの文字列。

=== sha256sums ===
ダイジェストサイズが 256 ビットの [[Wikipedia:ja:SHA-2|SHA-2]] チェックサムの配列。

=== sha224sums, sha384sums, sha512sums ===
それぞれ 224, 384, 512 ビットのダイジェストサイズの SHA-2 チェックサムの文字列。{{ic|sha256sums}} の代替ですが、あまり一般的ではない代替手段です。

=== b2sums ===
[[Wikipedia:ja:BLAKE#BLAKE2|BLAKE2]] チェックサムの配列で、ダイジェストサイズは 512 ビットです。

== 参照 ==
*[https://www.archlinux.org/pacman/PKGBUILD.5.html PKGBUILD(5) マニュアルページ]
*[https://projects.archlinux.org/pacman.git/plain/proto/PKGBUILD.proto サンプル PKGBUILD ファイル]

PKGBUILD

2025-04-19T15:39:03Z

Oech3: 解凍ツールの例をlrzipに合わせる/* noextract */

[[Category:パッケージ開発]]
[[cs:PKGBUILD]]
[[da:PKGBUILD]]
[[el:PKGBUILD]]
[[en:PKGBUILD]]
[[es:PKGBUILD]]
[[fa:PKGBUILD]]
[[fr:PKGBUILD]]
[[it:PKGBUILD]]
[[pl:PKGBUILD]]
[[pt:PKGBUILD]]
[[ru:PKGBUILD]]
[[sr:PKGBUILD]]
[[zh-hans:PKGBUILD]]
[[zh-hant:PKGBUILD]]
{{Related articles start}}
{{Related|Arch パッケージングスタンダード}}
{{Related|Arch Build System}}
{{Related|パッケージの作成}}
{{Related|.SRCINFO}}
{{Related|:カテゴリ:パッケージ開発}}
{{Related|カスタムローカルリポジトリ}}
{{Related|pacman ヒント}}
{{Related|Arch User Repository}}
{{Related|makepkg}}
{{Related|pacman}}
{{Related articles end}}

この記事では {{ic|PKGBUILD}} の中でメンテナが定義できる変数について説明します。{{ic|PKGBUILD}} の関数や一般的なパッケージの作成については [[パッケージの作成]] を参照してください。{{man|5|PKGBUILD}} も読んで下さい。

{{ic|PKGBUILD}} はシェルスクリプトで、[[Arch Linux]] のパッケージが必要とするビルド情報を含んでいます。

Arch Linux のパッケージは [[makepkg]] ユーティリティを使ってビルドされます。''makepkg'' を実行すると、カレントディレクトリにある {{ic|PKGBUILD}} ファイルを探し、その中の指示に従ってコンパイルするか、パッケージアーカイブ ({{ic|''pkgname''.pkg.tar.zst}}) を構築するためのファイルを入手します。出来上がったパッケージにはバイナリファイルとインストール手順が含まれ、[[pacman]] で簡単にインストールできます。

必須の変数は、{{ic|pkgname}}、{{ic|pkgver}}、{{ic|pkgrel}}、および {{ic|arch}} です。 {{ic|license}} は、パッケージをビルドするために厳密に必要というわけではありませんが、''makepkg'' が存在しない場合に警告を生成するため、他のユーザーと共有する {{ic|PKGBUILD}} には推奨されます。

ここで指定された順番で {{ic|PKGBUILD}} の変数を定義するのが一般的なやり方です。しかし、正しい [[Bash]] 構文が使われている限り、これは必須ではありません。

{{Tip|{{ic|PKGBUILD}} によくあるパッケージングの間違いがないかチェックするには [[namcap]] を使って下さい。}}

== パッケージ名 ==

=== pkgbase ===

通常のパッケージをビルドするときは、この変数を {{ic|PKGBUILD}} で明示的に宣言してはいけません:
この変数のデフォルトの値は [[PKGBUILD#pkgname|pkgname]] の値です。

[https://man.archlinux.org/man/PKGBUILD.5#PACKAGE_SPLITTING 分割パッケージ] をビルドするときは、この変数を使って ''makepkg'' の出力やソースだけの tarball の名前付けにパッケージのグループを参照するために使う名前を明示的に指定できます。この値はハイフンで始めることはできません。指定しない場合、値はデフォルトで {{ic|pkgname}} 配列の最初の要素になります。

分割パッケージのすべてのオプションとディレクティブのデフォルトは {{ic|PKGBUILD}} で指定されたグローバルな値です。ただし、以下のものは各分割パッケージのパッケージング関数の中でオーバーライドすることができます。[[PKGBUILD#pkgdesc|pkgdesc]], [[PKGBUILD#arch|arch]], [[PKGBUILD#url|url]], [[PKGBUILD#license|license]], [[PKGBUILD#groups|groups]], [[PKGBUILD#depends|depends]], [[PKGBUILD#optdepends|optdepends]], [[PKGBUILD#provides|provides]], [[PKGBUILD#conflicts|conflicts]], [[PKGBUILD#replaces|replaces]], [[PKGBUILD#backup|backup]], [[PKGBUILD#options|options]], [[PKGBUILD#install|install]] そして [[PKGBUILD#changelog|changelog]]

=== pkgname ===

パッケージの名前、例えば {{ic|1=pkgname='foo'}} か、分割パッケージの場合は名前の配列、例えば {{ic|1=pkgname=('foo' 'bar')}} を指定します。パッケージ名は小文字の英数字と以下の文字のみで構成されている必要があります。{{ic|@._+-}} は小文字の英数字と以下の文字で構成されています。(アットマーク、ドット、アンダースコア、プラス、ハイフン) ハイフンやドットで名前を始めることはできません。一貫性を保つために、{{ic|pkgname}} はソフトウェアのソース tarball の名前と一致させるべきです。例えば、ソフトウェアが {{ic|foobar-2.5.tar.gz}} に入っているならば、{{ic|1=pkgname=foobar}} と記述して下さい。

== バージョン ==

=== pkgver ===
パッケージのバージョン。この値はパッケージの作成者によって公開されたバージョンと同じでなくてはなりません。文字と数字、ピリオドとアンダーバーを使えますがハイフンは使うことができません。パッケージの作成者がバージョンのナンバリングにハイフンを使っている時は、アンダーバーに置き換えてください。例えば、バージョンが ''0.99-10'' の場合、''0.99_10'' に変更してください。{{ic|pkgver}} を後で PKGBUILD で使うときに、ダッシュの代わりにアンダーラインを使うのは簡単にできます例:
source=($pkgname-${pkgver//_/-}.tar.gz)

{{Note|ソフトウェアの開発元が {{ic|30102014}} のようなタイムスタンプによるバージョン付けをしている場合、日付の順序を逆にしてください: {{ic|20141030}} ([[Wikipedia:ISO 8601|ISO 8601]] 形式)。そうしないと新しいバージョンが認識されません。}}

{{Tip|
* [[pacman]] パッケージに含まれている [https://www.archlinux.org/pacman/vercmp.8.html vercmp] を使うことでバージョンの優先度をテストできます。
* PKGBUILD に {{ic|pkgver()}} 関数を定義することで [[makepkg]] は自動的に pkgver 変数を [http://allanmcrae.com/2013/04/pacman-4-1-released/ 更新] します。詳しくは [[VCS パッケージガイドライン#関数 pkgver()]] を見て下さい。}}

=== pkgrel ===
Arch Linux におけるパッケージのリリース番号。パッケージの同じバージョンを続けてビルドするときにそれを区別するためにこの値を使います。新しいバージョンのパッケージが始めてリリースされたとき、'''リリース番号は1からスタートします'''。{{ic|PKGBUILD}} ファイルに修正や最適化が加えられるたびに、パッケージは'''再リリース'''され'''リリース番号'''は1づつ増やされます。新しいバージョンのパッケージが出たら、リリース番号は1にリセットします。

=== epoch ===
{{Warning|{{ic|epoch}} はどうしても必要なときだけ使って下さい。}}

バージョン番号が更新を引き起こさないときでも、(epoch が低い) 以前のバージョンよりもパッケージを新しいものだと強制的に見せるために使用されます。この変数の値は正の整数でなくてはなりません。指定されていない場合、デフォルトの値は 0 になります。パッケージのナンバリングの規則が変更されたり、バージョンの通常の比較ルールを破壊したいときに有用です。例:

{{hc|1=
pkgver=5.13
pkgrel=2
epoch=1
|2=
1:5.13-2
}}

バージョンの比較についての詳細は [https://www.archlinux.org/pacman/pacman.8.html pacman(8)] を見て下さい。

== 汎用 ==

=== pkgdesc ===

パッケージの説明。これは 80 文字以下にすることをお勧めします。また、アプリケーション名がパッケージ名と異なる場合を除き、パッケージ名を自己参照的に含めないでください。たとえば、{{ic|1=pkgdesc="Nedit is a text editor for X11"}} の代わりに {{ic|1=pkgdesc="Text editor for X11"}} を使用します。

また、キーワードを賢く使用して、関連する検索クエリに表示される可能性を高めることも重要です。

=== arch ===
{{ic|PKGBUILD}} がビルド・動作するアーキテクチャの文字列。現在、{{ic|i686}} と {{ic|x86_64}} が使えます。ただし、[https://archlinuxarm.org/ Arch Linux ARM] などのプロジェクトでは他のアーキテクチャもサポートしています: {{ic|arm}} (armv5), {{ic|armv6h}} (armv6 hardfloat), {{ic|armv7h}} (armv7 hardfloat), {{ic|aarch64}} (armv8 64bit)。

アーキテクチャに依存しないパッケージ (シェルスクリプト, フォント, テーマなど) には {{ic|any}} を使うことができます。{{ic|-i686}} や {{ic|-x86_64}} とは対照的に、一度ビルドしたら他のアーキテクチャでも使うことができるようなパッケージには {{ic|-any}} を指定してください。全てのアーキテクチャに対応するようにパッケージをコンパイルすることができても、特定のアーキテクチャに向けてコンパイルされる場合は、Arch によって公式にサポートされているアーキテクチャを指定してください: {{ic|1=arch=('i686' 'x86_64')}}。

{{ic|$CARCH}} 変数を使うことで、ビルドや、変数を定義する時にターゲットとするアーキテクチャを知ることができます。{{bug|16352}} を参照してください。例:

depends=(foobar)
if test "$CARCH" == x86_64; then
depends+=(lib32-glibc)
fi

=== url ===
パッケージされるソフトウェアの公式サイトの URL。

=== license ===

ソフトウェアが配布されるライセンス。{{ic|[core]}} の {{pkg|licenses}} パッケージは {{ic|/usr/share/licenses/common}} によく使われるライセンスを保存しています、例えば {{ic|/usr/share/licenses/common/GPL}} パッケージのライセンスがここに保存されているライセンスのどれかのときは、ディレクトリの名前を設定してください、例えば {{ic|1=license=('GPL')}} 適切なライセンスが公式の {{Pkg|licenses}} パッケージに含まれていない場合は、やる必要があることがいくつかあります:

# ライセンスファイルを次のディレクトリに含めなくてはなりません: {{ic|/usr/share/licenses/''pkgname''/}}, 例 {{ic|/usr/share/licenses/foobar/LICENSE}}
# ソース tarball にライセンスの詳細が含まれずウェブサイトなど他のところで示されている場合は、ライセンスをファイルにコピーしてそのファイルを含めて下さい。
# {{ic|license}} 行に {{ic|custom}} を追加してください。任意で、{{ic|custom}} を {{ic|custom:ライセンスの名前}} にすることができます。あるライセンスが ({{ic|[community] を含む}}) 公式リポジトリの2つ以上のパッケージで使われると、{{Pkg|licenses}} パッケージに入れられます。
* 特別な事例として [[Wikipedia:ja:BSDライセンス|BSD]], [[Wikipedia:ja:MIT License|MIT]], [[Wikipedia:ja:zlib License|zlib/png]], [[Wikipedia:ja:Python Software Foundation License|Python]] ライセンスは {{pkg|licenses}} パッケージに含められていません。{{ic|license}} 行の目的のために、一般的なライセンス ({{ic|1=license=('BSD')}}, {{ic|1=license=('MIT')}}, {{ic|1=license=('ZLIB')}}, {{ic|1=license=('Python')}}) として扱われておきながらそれぞれ固有の copyright 行を持っているために技術的にカスタムライセンスになっています。これら4つのライセンスを使っている全てのパッケージは {{ic|/usr/share/licenses/''pkgname''}} 内にそのライセンスを保存しておく必要があります。パッケージによってはライセンスがひとつだけではないこともあります。そのような場合は、license 行に複数のエントリを書くことができます、例えば {{ic|1=license=('GPL' 'custom:name of license')}}
* さらに、(L)GPL には多くのバージョンと組み合わせが存在します。(L)GPL ソフトウェアで使えるのは:
** (L)GPL - (L)GPLv2 とそれ以降のバージョン
** (L)GPL2 - (L)GPL2 のみ
** (L)GPL3 - (L)GPL3 とそれ以降のバージョン
* license が決められていないと、{{ic|PKGBUILD.proto}} は {{ic|unknown}} を使うことを提案します。ただし、ソフトウェアが利用できるかできないかについてはアップストリームに連絡をすべきです。

{{Tip|ソフトウェアの作者によってはライセンスファイルを作らずに普通の {{ic|ReadMe.txt}} の中に配布ルールについて記述しているかもしれません。{{Ic|build()}} フェイズの時に、次のようにすることでファイルにこの情報を展開することが可能です: {{Ic|sed -n '/'''This software'''/,/''' thereof.'''/p' ReadMe.txt > LICENSE}}}}

こちらも参照 [[ノンフリーアプリケーションパッケージガイドライン]]

フリーおよびオープンソースソフトウェアライセンスに関する追加情報と展望は、次のページで見つけることができます。

* [[Wikipedia:ja:自由ソフトウェアライセンス|自由ソフトウェアライセンス]]
* [[Wikipedia:Comparison of free and open-source software licenses]]
* [https://www.softwarefreedom.org/resources/2008/foss-primer.html オープンソースおよびフリーソフトウェアプロジェクトの法的問題の入門書]
* [https://www.gnu.org/licenses/license-list.html GNU Project - さまざまなライセンスとそれらについての解説]
* [https://www.debian.org/legal/licenses/ Debian - ライセンス情報]
* [https://www.opensource.org/licenses/alphabetical Open Source Initiative - 名前別ライセンス]

=== groups ===

パッケージが属する [[メタパッケージとパッケージグループ|group]] たとえば、{{Grp|plasma}} をインストールすると、そのグループに属するすべてのパッケージがインストールされます。

== 依存関係 ==

{{Note|アンダーバーとアーキテクチャの名前を付けることで、特定のアーキテクチャだけの依存パッケージを追加することができます。例: {{ic|1=depends_x86_64=()}}, {{ic|1=optdepends_x86_64=()}}。}}

=== depends ===
ソフトウェアを実行する前にインストールする必要があるパッケージの名前を示す文字列。ソフトウェアが依存パッケージの最低必要バージョンがあるときは、{{ic|1=>=}} 演算子を使ってこれを表して下さい、例 {{ic|1=depends=('foobar>=1.8.0')}}。あなたのソフトウェアが依存している他のパッケージの依存にすでに含まれているパッケージを depends に加える必要はありません。例えば、{{pkg|gtk2}} は {{pkg|glib2}} と {{pkg|glibc}} に依存しています。しかしながら、{{pkg|glibc}} は {{pkg|glib2}} の依存にあるので {{pkg|gtk2}} の依存として {{pkg|glibc}} を含める必要はありません。

=== optdepends ===
ソフトウェアを機能させるのには必要ないが機能を追加することができるパッケージの名前の文字列。それぞれのパッケージが提供する機能の説明も短く書いておいて下さい。例えば {{ic|optdepends}} は以下のようになります:
optdepends=('cups: printing support'
'sane: scanners support'
'libgphoto2: digital cameras support'
'alsa-lib: sound support'
'giflib: GIF images support'
'libjpeg: JPEG images support'
'libpng: PNG images support')

===makedepends===
ソフトウェアをビルドするためにインストールする必要はあるが、インストール後にソフトウェアを使うために残しておく必要はないパッケージの名前。{{ic|depends}} 行と同じフォーマットを使ってパッケージの最小必要バージョンを指定できます。

{{Note|既に {{ic|depends}} に含まれているパッケージを指定する必要はありません。}}
{{Warning|makepkg でビルドする際 {{Grp|base-devel}} グループは既にインストールされているものと前提されます。"base-devel" のパッケージを {{ic|makedepends}} 行に入れては'''いけません'''。}}

=== checkdepends ===
テストスイートを実行するときに必要だが普通の実行時には必要ないパッケージの文字列。このリストのパッケージは depends と同じフォーマットに従います。[[パッケージの作成#関数 check()|check()]] 関数が makepkg によって実行される時だけこの依存関係が考慮されます。

== パッケージの関係性 ==

{{Note|アンダーバーとアーキテクチャの名前を付けることで、特定のアーキテクチャだけのパッケージの関係性を追加することができます。例: {{ic|1=provides_x86_64=()}}, {{ic|1=conflicts_x86_64=()}}}}

=== provides ===

パッケージの機能を提供するパッケージ (もしくは {{Ic|cron}} や {{Ic|sh}} などの仮想パッケージ) の名前の文字列。同じものを提供するパッケージは互いに衝突しないかぎり同時にインストールすることができます。

{{Note|この変数を使う場合は、バージョンによって影響を受ける依存関係がある場合パッケージが提供するバージョン ({{ic|pkgver}} と恐らく {{ic|pkgrel}}) を追加してください。例えば、''qt'' にモディファイを加えて ''qt'' を提供する ''qt-foobar'' バージョン 3.3.8 という名前で作成するときは、{{ic|provides}} 行は {{ic|1=provides=('qt=3.3.8')}} のようにしてください。{{ic|1=provides=('qt')}} とすると ''qt'' の特定バージョンを必要とする依存関係が破壊されることになります。{{ic|provides}} 行に {{ic|pkgname}} を加えないでください、自動で追加されます。}}

=== conflicts ===

インストールするとパッケージと問題が生じるパッケージの名前の文字列。この名前を持つパッケージとこの名前の仮想パッケージを {{Ic|provides}} に入れている全てのパッケージが削除されます。{{ic|depends}} 行と同じフォーマットを使って衝突するパッケージのバージョンプロパティを指定することもできます。

競合は、{{ic|pkgname}} および {{ic|provides}} 配列で指定された名前に対してチェックされることに注意してください。したがって、パッケージが {{ic|provides}} に {{ic|''foo''}} 機能を備えている場合、{{ic|conflicts}} 配列に {{ic|''foo''}} を指定すると、あなたのパッケージと、{{ic|provides}} 配列に {{ic|''foo''}} を含む他のすべてのパッケージとの間の競合 (つまり、競合するすべてのパッケージ名を {{ic|flicts}} 配列に指定する必要はありません) 具体的な例を挙げてみましょう。

* {{Pkg|netbeans}} は暗黙的に {{ic|netbeans}} を {{ic|pkgname}} 自身として提供しています。
* {{AUR|netbeans-cpp}} は {{ic|netbeans}} を提供し、{{ic|netbeans}} と衝突します。
* {{AUR|netbeans-php}} は {{ic|netbeans}} を提供し、{{ic|netbeans}} と衝突しますが、同じ機能を提供するパッケージは暗黙のうちに衝突するので、明示的に {{AUR|netbeans-cpp}} と衝突する必要はありません。

パッケージが {{ic|provides}} 配列を介して同じ機能を提供する場合、代替パッケージを {{ic|conflicts}} 配列に明示的に追加する場合と追加しない場合には違いがあります。{{ic|conflicts}} 配列が明示的に宣言されている場合、同じ機能を提供する 2 つのパッケージが ''代替'' とみなされます。{{ic|conflicts}} 配列が欠落している場合、同じ機能を提供する 2 つのパッケージが ''共存している可能性がある'' とみなされます。パッケージャは、{{ic|conflicts}} 変数を宣言するかどうかを決定する際に、{{ic|provides}} 変数の内容を常に無視する必要があります。

=== replaces ===

例えば {{Pkg|wireshark-qt}} は {{ic|1=replaces=('wireshark')}} を使います。同期する時、''pacman'' はインストールされたパッケージがリポジトリで {{ic|replaces}} にマッチする別のパッケージに出会ったら即座に置き換えます。既にあるパッケージの別バージョンを提供したり AUR にアップロードする時は {{ic|conflicts}} と {{ic|provides}} 配列を使ってください。

== その他 ==

=== backup ===
ユーザーが作成した変更を含んだり、パッケージのアップグレードや削除が行われても維持されるファイルの文字列、主に {{ic|/etc}} 内の設定ファイル用。

アップデート時、既存のファイル(ユーザーによって修正されたファイル)を上書きしないために新しいバージョンは {{ic|file.pacnew}} として保存されます。同じく、パッケージの削除時、パッケージを削除するのに {{ic|pacman -Rn}} コマンドを使わなければ、ユーザーが修正したファイルは {{ic|file.pacsave}} として残されます。

この行のファイルパスは絶対パス (例: {{ic|/etc/pacman.conf}}) ではなく相対パス (例: {{ic|etc/pacman.conf}}) にしてください。[[Pacnew と Pacsave ファイル]]も参照。

=== options ===
この文字列を使うと {{Ic|/etc/makepkg.conf}} で定義された {{ic|makepkg}} のデフォルトの挙動の一部を上書きできます。オプションをセットするには、文字列にオプションの名前を入れて下さい。デフォルトの挙動を逆にするには、オプションの前に '''{{ic|!}}''' を付けて下さい。options には以下のオプションを置くことが可能です:

* {{ic|strip}} - バイナリとライブラリからシンボルを除去。プログラムやライブラリでデバッガを頻繁に使う時は、このオプションを無効にすると便利です。
* {{ic|docs}} - {{ic|/doc}} ディレクトリを保存。
* {{ic|libtool}} - パッケージに ''libtool'' ({{ic|.la}}) ファイルを残す。
* {{ic|staticlibs}} - パッケージに静的ライブラリ (.a) のファイルを残す。
* {{ic|emptydirs}} - パッケージに空のディレクトリを残す。
* {{ic|zipman}} - ''man'' と ''info'' ページを ''gzip'' で圧縮。
* {{ic|purge}} - パッケージの {{ic|PURGE_TARGETS}} 変数で指定されたファイルを削除。
* {{ic|upx}} - UPX を使って実行可能バイナリを圧縮。{{ic|UPXFLAGS}} 変数を指定することで UPX に追加オプションを渡せます。
* {{ic|ccache}} - ビルド中の {{ic|ccache}} の使用を許可。{{ic|ccache}} を使ってビルドすると問題が起こるパッケージに無効化の {{ic|!ccache}} を使うと便利です。
* {{ic|distcc}} - ビルド中の {{ic|distcc}} の使用を許可。{{ic|distcc}} を使ってビルドすると問題が起こるパッケージに無効化の {{ic|!distcc}} を使うと便利です。
* {{ic|buildflags}} - ビルド中にユーザー定義の {{ic|buildflags}} (CFLAGS, CXXFLAGS, LDFLAGS) の使用を許可。カスタムした {{ic|buildflags}} を使ってビルドすると問題が起こるパッケージに無効化の {{ic|!buildflags}} を使うと便利です。
* {{ic|makeflags}} - ビルド中にユーザー定義の {{ic|makeflags}} の使用を許可。カスタムした {{ic|makeflags}} を使ってビルドすると問題が起こるパッケージに無効化の {{ic|!makeflags}} を使うと便利です。

=== install ===
パッケージに含まれる {{ic|.install}} スクリプトの名前。{{ic|pkgname}} と同じ名前にしてください。パッケージのインストール・削除・アップグレードの際に、pacman はパッケージごとにスクリプトを保存・実行する機能があります。スクリプトには、実行される段階によって以下の関数を含めることができます:

* {{ic|pre_install}} - ファイルが展開される前にスクリプトを実行。1つの引数が渡されます: 新しいパッケージのバージョン。
* {{ic|post_install}} - ファイルが展開された後にスクリプトを実行。1つの引数が渡されます: 新しいパッケージのバージョン。
* {{ic|pre_upgrade}} - ファイルが展開される前にスクリプトを実行。2つの引数が渡されます: 新しいパッケージのバージョン, 古いパッケージのバージョン。
* {{ic|post_upgrade}} - ファイルが展開された後にスクリプトを実行。2つの引数が渡されます: 新しいパッケージのバージョン, 古いパッケージのバージョン。
* {{ic|pre_remove}} - ファイルが削除される前にスクリプトを実行。1つの引数が渡されます: 古いパッケージのバージョン。
* {{ic|post_remove}} - ファイルが削除された後にスクリプトを実行。1つの引数が渡されます: 古いパッケージのバージョン。

それぞれの関数は pacman のインストールディレクトリの中に [[chroot]] されて実行されます。[https://bbs.archlinux.org/viewtopic.php?pid=913891 このスレッド] を見て下さい。

{{Tip|{{ic|.install}} のプロトタイプが {{ic|/usr/share/pacman/proto.install}} にあります。}}

{{Note|スクリプトの中で {{ic|exit}} を実行しないでください。スクリプト内の関数が実行できなくなってしまいます。}}

=== changelog ===
パッケージの変更履歴の名前。インストールされたパッケージの変更履歴を表示するには:
$ pacman -Qc ''pkgname''

{{Tip|変更履歴ファイルのプロトタイプが {{ic|/usr/share/pacman/ChangeLog.proto}} にあります。}}

== ソース ==

{{Note|アンダーバーとアーキテクチャの名前を追加することで特定のアーキテクチャのソースを追加することができます。例: {{ic|1=source_x86_64=()}}。そのアーキテクチャのソースと対応するチェックサムも指定してください。例: {{ic|1=sha256sums_x86_64=()}}。}}

=== source ===
パッケージをビルドするのに必要なファイルの文字列。ソフトウェアのソースの場所を入れる必要があり、多くの場合 HTTP や FTP の URL です。前に設定した {{ic|pkgname}} や {{ic|pkgver}} 変数をここで使うことができます (例: {{ic|<nowiki>source=(http://example.com/$pkgname-$pkgver.tar.gz)</nowiki>}})。

自作のパッチなど、オンザフライでダウンロードできないファイルを供給する必要があるときは、{{ic|PKGBUILD}} ファイルがあるところと同じディレクトリにそのファイルを入れて source にファイル名を追加するだけです。ここに追加したパスはすべて {{ic|PKGBUILD}} があるディレクトリから相対的に考えられます。本当のビルドプロセスが始まる前に、この行で参照されている全てのファイルがダウンロードされるか存在を確認します。もしファイルが欠けている場合は {{ic|makepkg}} は次に進みません。

{{Tip|ダウンロードされるファイルに異なる名前を指定するには - GET パラメータがある URL などが原因でダウンロードされるファイルの名前が異なる場合 - 次の構文を使って下さい: {{Ic|''filename''::''fileuri''}}, 例えば: {{Ic|1=source=("project_name::<nowiki>hg+https://googlefontdirectory.googlecode.com/hg/</nowiki>"}}。}}

{{Note|''.install'' ファイルは source に記述してはいけません。}}

拡張子が ''.sig'', ''.sign'', ''.asc'' のファイルを source 配列に指定した場合、''makepkg'' はそれを PGP 署名として認識して、ソースファイルの整合性を確認するのに自動的に用います。

=== noextract ===
{{ic|source}} 行で {{ic|makepkg}} によって圧縮フォーマットを展開してはいけないファイルの文字列。{{Pkg|libarchive}} は {{Pkg|unzip}} とは違い全てのファイルをランダムアクセスではなくストリームで処理するので、{{ic|/usr/bin/bsdtar}} によって扱えない圧縮ファイルに noextract を使うのがほとんどです。こういった場合には他の解凍ツール (例: {{ic|lrzip}} など) を {{ic|makedepends}} に追加して [[パッケージの作成#関数 prepare()|prepare()]] 関数の最初の行でソースの圧縮ファイルを手動で展開する必要があります。例えば:

prepare() {
lrzip -d ''source''.tar.lrz
}

{{ic|source}} 行には URL を指定することが可能ですが、{{ic|noextract}} にはファイル名の一部'''だけ'''を指定します。例えば、以下のようにすることができます ([https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/grub grub2 の PKGBUILD] から引用):

source=(<nowiki>"http://ftp.archlinux.org/other/grub2/grub2_extras_lua_r20.tar.xz"</nowiki>)
noextract=("grub2_extras_lua_r20.tar.xz")

''何も展開しない''ようにするには、以下のように工夫してください ([https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/firefox-i18n#n123 firefox-i18n] から引用):

noextract=(${source[@]%%::*})

=== validpgpkeys ===
PGP フィンガープリントの配列。validpgpkeys を使用した場合、''makepkg'' は validpgpkeys に記載されている鍵の署名だけを使うようにして鍵束の値は無視します。ソースファイルが副鍵で署名されていた場合、''makepkg'' は主鍵を使って比較します。

指定できるのは完全なフィンガープリントだけです。全て大文字で空白を含めてはいけません。

{{note|{{ic|gpg --list-keys --fingerprint <KEYID>}} で指定した鍵のフィンガープリントを確認できます。}}

== 整合性 ==

以下の変数はどれもチェックサム文字列を指定するようになっており、[[#source|source]] 配列に書かれたファイルの整合性を確認するのに使われます。{{ic|SKIP}} とすることで特定のファイルのチェックサムを確認しないようにできます。

チェックサムの種類と値は、リリースアナウンスなど上流から提供されたものを常に使用する必要があります。複数のタイプが利用可能な場合は、最も強力なチェックサムが優先されます。{{ic|sha512}} よりも {{ic|b2}}, {{ic|sha384}} よりも {{ic|sha384}}, {{ic|sha256}} よりも {{ic|sha512}} を優先してください, {{ic|sha224}} に対して {{ic|sha256}}、{{ic|sha1}} に対して {{ic|sha224}}、{{ic|md5}} に対して {{ic|sha1}}、および {{ic|md5}} 以上 {{ic|ck}}} があります。これは、上流のアナウンスからパッケージのビルドまで、ダウンロードしたファイルの完全性を保証するために最適な方法です。

{{Note|さらに、上流が [[Wikipedia:ja:デジタル署名|デジタル署名]] を利用可能にしたら、署名ファイルを [[#source|source]] 配列に、PGP 鍵指紋を [[#validpgpkeys|validpgpkeys]] 配列に追加する必要があります。これにより、ビルド時にファイルの認証ができるようになります。}}

これらの変数の値は [[makepkg]] の {{ic|-g}}/{{ic|--geninteg}} オプションで自動生成され、一般に {{ic|makepkg -g >> PKGBUILD}} で追加されます。{{Pkg|pacman-contrib}} の {{man|8|updpkgsums}} コマンドは {{ic|PKGBUILD}} 内のどこにあっても変数を更新することが可能です。どちらのツールも {{ic|PKGBUILD}} に既に設定されている変数を使い、設定されていない場合は {{ic|md5sums}} にフォールバックします。

使用するファイルの整合性チェックは {{ic|/etc/makepkg.conf}} の {{ic|INTEGRITY_CHECK}} オプションで設定することができます。 {{man|5|makepkg.conf}} を参照してください。

{{Note|追加のアーキテクチャ固有の配列は、アンダースコアとアーキテクチャ名を付加することで追加できます、例えば {{ic|1=sha256sums_x86_64=() }}}}

=== cksums ===
{{ic|source}} 配列にリストされているファイルの [[Wikipedia:ja:巡回冗長検査|CRC32]] チェックサム (UNIX 標準 [[Wikipedia:ja:Cksum_(UNIX)|cksum]] より)

=== md5sums ===
{{ic|source}} 行に含まれるファイルの 128 ビット [[Wikipedia:ja:MD5|MD5]] チェックサムの文字列。

=== sha1sums ===
{{ic|source}} 行に含まれるファイルの 160ビットの [[Wikipedia:SHA-1|SHA-1]] チェックサムの文字列。

=== sha256sums ===
ダイジェストサイズが 256 ビットの [[Wikipedia:ja:SHA-2|SHA-2]] チェックサムの配列。

=== sha224sums, sha384sums, sha512sums ===
それぞれ 224, 384, 512 ビットのダイジェストサイズの SHA-2 チェックサムの文字列。{{ic|sha256sums}} の代替ですが、あまり一般的ではない代替手段です。

=== b2sums ===
[[Wikipedia:ja:BLAKE#BLAKE2|BLAKE2]] チェックサムの配列で、ダイジェストサイズは 512 ビットです。

== 参照 ==
*[https://www.archlinux.org/pacman/PKGBUILD.5.html PKGBUILD(5) マニュアルページ]
*[https://projects.archlinux.org/pacman.git/plain/proto/PKGBUILD.proto サンプル PKGBUILD ファイル]

ローカリゼーション

2025-04-19T09:16:10Z

Oech3: Add ttf-jigmo/* フォント */

[[category:ローカリゼーション]]
[[en:Localization/Japanese]]
{{Related articles start}}
{{Related|国際化}}
{{Related|インプットメソッド}}
{{Related|Uim を使って日本語を入力}}
{{Related|Mozc}}
{{Related|Fcitx}}
{{Related|Fcitx5}}
{{Related articles end}}
このドキュメントでは、日本語環境の構築方法と入力方法について説明します。ここでは、一般的な推奨ケースのみを取り上げます。代替手段 (例: tty での日本語入力、またはあまり一般的ではない入力メソッドフレームワーク) の詳細については、それぞれを参照してください。コンソール/tty での日本語入力の設定については説明しません。

== フォント ==

日本語の文字を表示するには、日本語 (または中国語) フォントをインストールする必要があります。テキストがめちゃくちゃに表示される場合は、適切な日本語フォント (中国語フォントでも大丈夫です) がシステムにインストールされていることを確認してください。

推奨されている日本語フォントをいくつか以下に挙げます (その他のフォントやフォントの設定については [[フォント]] や [[フォント設定]] を参照してください):

* {{Pkg|adobe-source-han-sans-jp-fonts}} - 日本語のゴシック体 (サンセリフ) OpenType/CFF フォント。
* {{Pkg|adobe-source-han-serif-jp-fonts}} - 日本語の明朝体 (セリフ) OpenType/CFF フォント。
* {{Pkg|noto-fonts-cjk}} - Google Noto CJK フォント。
* {{Pkg|otf-ipafont}} - フォーマルなゴシック体及び明朝体の日本語フォントのセット。オープンソースのフォントとしては最も高品質なものの1つです。openSUSE-ja のデフォルトフォント。
* {{Pkg|otf-ipaexfont}} - ipafont の更新されたフォント.
* {{Pkg|ttf-hanazono}} - フリーの明朝体日本語漢字フォント。
* {{Pkg|ttf-jigmo}} - 漢字のフリーフォント. 花園明朝{{Pkg|ttf-hanazono}}の後継.
* {{Pkg|ttf-sazanami}} - フリーの TrueType 日本語フォント。これは古く、もはやメンテナンスされていませんが、いくつかの環境では代替フォントとして定義されていることがあります。
* {{AUR|ttf-koruri}} - {{AUR|ttf-mplus}} と Open Sans をミックスした TrueType 日本語フォント。
* {{AUR|ttf-monapo}} - [[wikipedia:2channel_Shift_JIS_art|2ちゃんねるの Shift JIS アート]]を適切に表示するための日本語フォント。
* {{AUR|ttf-mplus-git}} - モダンなゴシック体の日本語アウトラインフォント。全てのひらがな・カタカナ、基本ラテン文字、ラテン文字補助、ラテン文字拡張A、IPA 拡張と、ほとんどの日本語漢字、ギリシャ文字、キリル文字、ベトナム語を 7 のウェイト（プロポーショナル）または 5 のウェイト（等幅）で含んでいます。
* {{AUR|ttf-vlgothic}} - 日本語ゴシック体フォント。Debian/Fedora/Vine Linux のデフォルトです。
* {{AUR|ttf-kanjistrokeorders}} - 文字の筆順を示す KanjiStrokeOrders フォント。

== ロケール ==

''詳しくは[[ロケール]]を参照。''

ロケールは、地域固有の、または言語/地域設定に特化した標準を正しく表示するために使用されます。日本語ロケールが有効化されていることを確認するためには、次のコマンドの出力に {{ic|ja_JP.utf8}} が含まれていることを確認してください：

$ locale -a

日本語ロケールを有効化するには、{{ic|/etc/locale.gen}} 内の {{ic|ja_JP.utf8}} のコメントアウトを外します：

{{hc|/etc/locale.gen|
...
#ja_JP.EUC-JP EUC-JP
ja_JP.UTF-8 UTF-8
#ka_GE.UTF-8 UTF-8
...
}}

その後、ロケールを再生成します：
$ locale-gen

{{Note|UTF-8 文字セットは、他の文字セットより一般的に推奨されています。}}

== 日本語入力 ==

=== インプットメソッドフレームワーク (IMF) ===

最も一般的な IMF は [[IBus]]（[[GTK]] ベースの環境でより一般的）と [[Fcitx5]]（[[Qt]] ベースの環境でより一般的）で、これらはすべての日本語 IME に対応しています。IMF と対応する IME の全体的な概要については、[[インプットメソッド#使用可能なインプトメソッドエディターの一覧|この表]]を参照してください。この記事では、[[#Fcitx5]] と [[#IBus]] のインストールと設定について簡単に説明します。

==== Fcitx5 ====

{{Note|
* [[Fcitx]] パッケージは 2020 年 11 月から [[Fcitx5]] に置き換えられており、Fcitx は保守モードに入っています。ユーザーは Fcitx の代わりに Fcitx5 を使用することを推奨します。
* {{Pkg|fcitx5}} は基本的なフレームワークのみを含んでいますが、{{Grp|fcitx5-im}} グループには、[[GTK]] および [[Qt]] アプリケーション用の [[Fcitx5#Input method modules|入力メソッドモジュール]]や、[[Fcitx5#Configuration tool|設定ツール]]も含まれており、ほとんどのケースをカバーします。
}}

ほとんどの場合、{{Grp|fcitx5-im}} グループを[[インストール]]するだけで十分です。詳細および手順については、[[Fcitx5#インストール]]を参照してください。

{{Tip|
* {{Grp|fcitx5-im}} グループは、ほとんどの [[GTK]] および [[Qt]] アプリケーションをサポートしています。問題が発生している場合は、[[Qt|Qt4]]、[[Qt|Qt6]]、および日付と時刻のサポートのために、{{AUR|fcitx5-qt4-git}}、{{AUR|fcitx5-qt6-git}}、および {{Pkg|fcitx5-lua}} をインストールすることができます。
* Fcitx には限られた数のテーマが付属しており、設定ツールを使用して設定できます。テーマと外観の詳細については、[[Fcitx5#Themes]] を参照してください。
}}

Fcitx5 を有効にするには、少なくとも以下の環境変数を設定してください:

{{bc|1=
GTK_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx
}}

{{Note|Fcitx5 を使用している場合でも、{{ic|fcitx}} を {{ic|fcitx5}} に置き換えないでください。}}

==== IBus ====

{{Pkg|ibus}} パッケージを[[インストール]]します。詳細は [[IBus#インストール]]を参照してください。

IBus を有効にするには、少なくとも以下の環境変数を設定してください:

{{bc|1=
GTK_IM_MODULE=ibus
QT_IM_MODULE=ibus
XMODIFIERS=@im=ibus
}}

=== インプットメソッドエディタ (IME) ===

[[Fcitx5]] と [[IBus]] は、すべての日本語 IME に対応しています。お好みの IME をインストールする手順に従ってください。迷った場合は、[[#Mozc]] をお勧めします。

==== Mozc ====

プロジェクトの[https://github.com/google/mozc ホームページ]より:

:'''Mozc''' は、Android OS、Apple OS X、Chromium OS、GNU/Linux、Microsoft Windows などのマルチプラットフォーム向けに設計された日本語[[インプットメソッド]]エディタ (IME) です。このオープンソースプロジェクトは、[https://www.google.com/intl/ja/ime/ Google 日本語入力] に由来しています。

お好みの IMF に対応する Mozc バージョンを[[インストール]]してください（例: Fcitx5 用には {{Pkg|fcitx5-mozc}}、IBus 用には {{AUR|ibus-mozc}}）。

{{Tip|Mozc は、{{AUR|emacs-mozc}} パッケージをインストールすることで、[[Emacs]] でも有効にできます。}}

==== Anthy ====

{{Note|Anthy は 2009 年以降事実上開発が停止しています。[https://osdn.net/projects/anthy/]}}

Anthy はほとんどの IMF に対応しているか、組み込まれていますが、事実上開発が停止しています。

お好みの IMF に対応する Anthy バージョンを[[インストール]]してください（例: Fcitx5 用には {{Pkg|fcitx5-anthy}}、IBus 用には {{Pkg|ibus-anthy}}）。

2021年以降、Takao Fujiwara 氏により「Anthy Unicode」なるプロジェクトが立ち上げられました。

エンジンとして、{{Pkg|anthy}} または {{AUR|anthy-unicode}} があります。

=== SKK (libskk) ===

[https://github.com/ueno/libskk Simple Kana to Kanji (SKK)] は、[[Emacs]] に基づいた基本的な仮名から漢字への変換方法です。これは、京都大学名誉教授である佐藤雅彦博士によって設計され、1987 年に作成されました。[https://flex.phys.tohoku.ac.jp/texi/faq-mule/faq-mule_13.html] SKK の特徴は形態素解析を行わずに一つずつ単語を変換することです (単文節変換)。

お好みの IMF に対応する libskk バージョンを[[インストール]]してください（例: Fcitx5 用には {{Pkg|fcitx5-skk}}、IBus 用には {{Pkg|ibus-skk}}）。

{{Tip|{{Pkg|fcitx5-skk}} または {{Pkg|ibus-skk}} をインストールすると、{{Pkg|skk-jisyo}} 辞書パッケージもインストールされます。SKK 辞書は、オプションの {{Pkg|skktools}} パッケージで管理できます。}}

=== KKC(libkkc) ===

[https://github.com/ueno/libkkc libkkc] は日本語のかなの文章をかな漢字混じりの文章に変換します。GNU Emacs の kkc.el (シンプルな仮名漢字変換器) にあやかって名付けられました。ただし libkkc は N-gram 言語モデルを使って多少複雑な方法で連文節変換を行います。libkkc は Red Hat のエンジニアによって開発されています。

{{Pkg|fcitx-kkc}} (Fcitx の場合) または {{Pkg|ibus-kkc}} (IBus の場合) をインストールしてください。

=== Google CGI API for Japanese input ===

''利用できる IM フレームワーク: uim''

[http://www.google.co.jp/ime/cgiapi.html Google CGI API for Japanese Input] (Google-CGIAPI-Jp) は日本語変換をインターネット上で実現する Google による CGI サービスです。[https://www.google.com/transliterate ウェブブラウザ] で使用することができます。おそらく、変換エンジンは Google 日本語入力と同一のため、Mozc よりも変換品質が優れています。

{{Note|このサービスは確定前の文章や変換候補を平文で送受信します (2012年9月現在)。}}

Google-CGIAPI-Jp は uim で使うことができます。uim-im-switcher-gtk/gtk3/qt4 または uim-pref-gtk/gtk3/qt4 で "Google-CGIAPI-Jp" を選択してください。

= 参照 =

* [https://wiki.gentoo.org/wiki/How_to_read_and_write_in_Japanese/ja 日本語を使った読み書きの方法]

{{TranslationStatus|Localization/Japanese|2024-08-28|815536}}

ノンフリーアプリケーションパッケージガイドライン

2025-04-15T10:11:57Z

Oech3: libarchive,bsdunzip/* 展開 */

[[Category:パッケージ開発]]
[[en:Nonfree applications package guidelines]]
{{Package Guidelines}}

アプリケーションによっては (特に Windows のアプリケーション) ソースや tarball が手に入らない場合があります。そのようなアプリケーションの多くはライセンスの制約があったり、あるいは無料で合法的にインストーラーを取得する方法が存在せず、自由に再配布することができません。当然それらのソフトウェアを[[公式リポジトリ]]に入れることはできませんが、[[AUR]] であれば私的にソフトウェアの[[makepkg|パッケージをビルド]]して [[pacman]] で管理するということが不可能ではありません。
{{Note|この記事に書かれている情報はパッケージに依存しません。一般的なフリーではないソフトウェアに関する情報は [[Wine パッケージガイドライン]]を見てください。}}

== 根拠 ==
パッケージになっていないソフトウェアもパッケージ化する理由は複数あります:
* インストールやアンインストールの平易化
:{{Ic|/usr/bin}} にスクリプトをインストールするだけのシンプルなアプリでも意味があります。通常は以下のコマンドを実行するところを:
:{{bc|<nowiki>
$ chmod +x filename
# chown root:root filename
# cp filename /usr/bin/
</nowiki>}}
:以下のコマンドだけでパッケージを作成できます:
:{{bc|$ makepkg -i}}
:フリーでないアプリケーションは大抵複雑ですが、パッケージスクリプトを書くことで、ホームページから圧縮ファイルやインストーラをダウンロードして、展開・復号化してから、ランチャースクリプトを手動で書くような作業の負担を少なくすることができます。
* pacman の機能の利用
:ソフトウェアの状態の追跡、インストール済みのソフトウェアの自動アップデート、全てのファイルの所有権管理、管理が行き届いたキャッシュに圧縮パッケージを保存することなどが可能になり GNU/Linux ディストリビューションの強みを活かせます。
* コードや知識の共有
:プロプライエタリの開発者にパッチを送信したり普遍的なフォーラムで質問を投げるよりも AUR のような場所のほうが設定を変更したりバグフィックスを当てたり助けを得ることが楽になります。

== 一般的なルール ==
=== 可能なかぎりフリーでないソフトウェアは避ける ===

このガイドは脇に置いて、パッケージ化したいアプリケーションの代わりとなるアプリケーションが存在しないか検索 (あるいは作成) するのに時間を費やしたほうが有益です:

* 一企業によって所有されているソフトウェアよりも全員で共有しているソフトウェアを支援したほうが有益です
* 活発に開発されているソフトウェアを支援したほうが有益です
* ユーザーのだれか一人でも面倒をみることができれば修正が可能なソフトウェアを支持するほうが有益です

=== 可能なかぎりオープンソースのソフトウェアを使う ===
多くの商用ゲーム ([[ゲーム一覧]]) はオープンソースのエンジンを使っており古いゲームの多くは [[Wikipedia:ScummVM|ScummVM]] などのエミュレータで遊ぶことができます。オープンソースエンジンとオリジナルのゲームアセットを使うことで、バイナリパッケージによる問題を回避したりバグを解決することが可能です。

=== Keep it simple ===
オリジナルのバージョンを購入して使用するのと比べてパッケージ化するために複雑な作業やハックが必要な場合、簡単なほうの方法を使ってください。

== パッケージの命名 ==
勝手に名前を付ける前に、パッケージ化したいソフトウェアが AUR に既に存在しないか検索してください。パッケージが存在する場合、それらの命名規則に従うようにしてください (例えば {{AUR|aquaria-hib}}, {{AUR|penumbra-overture-hib}}, {{AUR|uplink-hib}} というパッケージが存在するのに ''gish-hb'' という名前のパッケージを作成するのは止めてください)。ソースベースのパッケージが絶対に存在しないという確信がないかぎり、必ず {{Ic|-bin}} をパッケージの後ろに付けてください。

== ファイルの置き場所 ==
既存のパッケージを解析して、ファイルが衝突しないように注意してください。パッケージディレクトリの所有権を {{Ic|root:games}} にするような汚いハックを使う必要がないのであれば、ファイルを {{Ic|/opt}} には配置しないでください。

== 欠けているファイル ==

ほとんどの商用ゲームはゲームファイルを (合法的に) ダウンロードする手段を用意しておらず、通常パッケージからインストールするようになっています。([[Wikipedia:Humble Indie Bundle|Humble Indie Bundle]] のゲームのように) パスワードを入力すればファイルをダウンロードすることが可能な場合でも、{{Ic|build}} 関数の中でダウンロードを行うことは様々な理由で推奨できません (例えば、ユーザーはインターネットに接続できない環境でローカルにファイルを全てダウンロード・保存している場合などが考えられます) そのような場合、以下の方法があります:

以下のサブセクションでは、遭遇する可能性のあるいくつかの状況に対する推奨事項を示します。

=== ファイルは分散アーカイブ/インストーラーでのみ入手できます ===

ソフトウェアは、そのアーカイブ/インストーラーファイル経由でのみ利用可能であり、不足しているファイルを取得するには、アーカイブ/インストーラーファイルを取得する必要があります。

必要なアーカイブ/インストーラーを {{ic|source}} 配列に追加し、AUR Web インターフェイス内のソースのリンクがソース tarball に含まれるファイルの名前と異なるように見えるように、ソースファイル名を変更します。

{{bc|1=sources=(... "''originalname''::'''local:'''//''originalname''")}}

また、以下のような固定コメントを AUR のパッケージページに追加し、PKGBUILD で詳細を説明します。

{{bc|Need archive/installer to work.}}

==== スキームを選択 ====

ソース配列で ''local://'' スキームを使用する場合、makepkg はスキームが指定されていないかのように動作するため、ファイルは PKGBUILD と同じディレクトリに手動で配置する必要があります。

''file://'' スキームを使用する場合は、ファイルプロトコルに DLAGENTS を追加で指定できるため、特別な方法で取得できます。例 [[ノンフリーアプリケーションパッケージガイドライン#カスタム DLAGENTS|下記]] を参照してください。

ただし、これらのスキームのどれを使用する必要があるかという明確なルールはまだありません。

=== ファイルは、配布された CD または他のタイプの光ディスクメディアでのみの場合 ===

ソフトウェアが、光ディスクメディア (CD、DVD、Bluray など) 経由でのみの場合。不足しているファイルを取得するには、光ディスクドライブにメディアを挿入する必要があります。

インストーラースクリプトと {{ic|.install}} ファイルをパッケージのコンテンツに追加します。

=== ファイルはいくつかの方法で取得できます ===

{{ic|build}} フェーズ中にディスクからファイルをコピーしたり、ネットからダウンロードしたり、アーカイブから取得したりすることは良いアイデアのように見えるかもしれませんが、ユーザーの可能性が制限され、パッケージのインストールが対話型になるため、お勧めできません (これは一般的に推奨されず、ただ迷惑なだけです)繰り返しになりますが、適切なインストーラースクリプトと {{ic|.install}} ファイルを代わりに使用できます。

パッケージに必要なファイルを取得するためのさまざまな戦略の例をいくつか示します。

* {{AUR|worldofgoo}} – ユーザー提供のファイルへの依存関係

{{Expansion|This page used to link to umineko-en and ut2004-anthology as examples, but they have been removed since they are no longer on the AUR, different examples should be provided.}}

== 高度なトピック ==

=== カスタム DLAGENTS ===

ソフトウェアによっては自動ダウンロードからソフトウェアが積極的に保護されている場合もあります: 特定の "User-Agent" 文字列のアクセスを拒否したり、ファイルの一時リンクを作成することなどが挙げられます。そういった場合でも、PKGBUILD で {{Ic|DLAGENTS}} 変数を使うことでファイルを楽にダウンロードすることができます ({{man|5|makepkg.conf}} を参照){{Pkg|ttf-baekmuk}} など、[[公式リポジトリ]]のパッケージでも使われているものがあります。

ユーザーエージェント文字列をカスタマイズする場合、空白や括弧、スラッシュが含まれていると動作しなくなります。Bash の制限のため解決方法はありません。例えば以下の例は機能しません:

DLAGENTS=("http::/usr/bin/curl -A 'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)' -fLC - --retry 3 --retry-delay 3 -o %o %u")

以下のようにすることで機能します:

DLAGENTS=("http::/usr/bin/curl -A 'Mozilla' -fLC - --retry 3 --retry-delay 3 -o %o %u")

また、以下を使うことでダウンロードページからファイルの一時リンクを抽出することが可能です:

DLAGENTS=("http::/usr/bin/wget -r -np -nd -H %u")

=== 展開 ===

プロプライエタリなプログラムの多くは扱いにくいインストーラーを使っており Wine でも動作しないことがしばしばです。以下のツールを使うことで展開できる場合があります:
* {{Pkg|libarchive}}は''bsdtar''をもち、{{ic|.iso}}や{{ic|.AppImage}}(実はiso9660ファイル)を展開できます. ''bsdunzip''も提供し、''unzip''の代わりにできます. {{ic|bsdunzip -O}}をUTF-8でないzipファイルに使えます.
** libarchive is required by pacman and so it is part of a base install.
* {{Pkg|unzip}} と {{Pkg|unrar}} は実行ファイルの SFX アーカイブを展開できます。
* {{Pkg|cabextract}} は大抵の {{Ic|.cab}} ファイルを展開できます ({{Ic|.exe}} 拡張子のファイルも展開可能です)
* {{Pkg|unshield}} は InstallShield インストーラーから CAB ファイルを抽出できます。
* {{Pkg|p7zip}} は大抵の圧縮形式を展開できるだけでなく [[Wikipedia:ja:Nullsoft Scriptable Install System|NSIS]] ベースの {{Ic|.exe}} インストーラーも展開できます。
** 一般的な PE ({{Ic|.exe}} & {{Ic|.dll}}) ファイルから一部だけを抽出することも可能です。
* 実行ファイルが暗号化されている場合 {{Pkg|upx}} によって復号化できることがあります。
* {{Pkg|innoextract}} は [[Wikipedia:Inno Setup|Inno Setup]] によって作成された {{Ic|.exe}} インストーラーを展開できます (GOG.com のゲームなどで使われています)
ファイルのタイプを確認するには {{Ic|file ''file_of_unknown_type''}} を実行してください。

=== .desktop ファイル用のアイコンの取得 ===

プロプライエタリなソフトウェアはアイコンファイルを用意してないことが少なくなく、[[デスクトップエントリ|.desktop]] ファイルを作成するときに使えるアイコンがないことがあります。{{Pkg|icoutils}} パッケージに含まれているプログラムを使うことで実行ファイルから {{Ic|.ico}} ファイルは簡単に抽出できます。{{Ic|build}} 関数の中で抽出をすることもできます:
$ wrestool -x --output=''icon.ico'' -t14 ''executable.exe''

=== pkgver の自動バンピング ===

非フリーソフトウェアベンダーは、ダウンロードソース URL にバージョン番号を含めないことがよくあります。

source=(<nowiki>'https://downloads.example.com/NonFreePackageWithPoorFileName.exe'</nowiki>)

そのため、リリースアップストリームのパッケージが予告なく変更される可能性があり、これがパッケージ化の問題となります。 [[VCS パッケージガイドライン|VCS パッケージ]] と同様に、[[VCS パッケージガイドライン#関数 pkgver()|auto-bump]] {{ic|pkgver}} を使用してこれを処理することもできます。

==== インストーラーパッケージから ====

たとえば、一部の ''.exe'' インストーラーでは、[[Wikipedia:ja:Portable Executable|PE]] に [製品バージョン] フィールドが設定されています。{{AUR|pev}} パッケージの {{ic|peres}} コマンドは、その値を抽出して使用して、{{ic|pkgver}} を自動バンプするのに役立ちます。

{{bc|<nowiki>
pkgver=VERSION
makedepends=('pev')

pkgver() {
peres -v -f csv "${srcdir}/NonFreePackageWithPoorFileName.exe" \
| awk -F , '/^Product Version,/ { print $2 }'
}</nowiki>
}}

==== メインの実行可能ファイルから ====

場合によっては、''.exe'' インストーラーには ''製品バージョン'' の意味のある値が含まれていないが、メインの実行可能ファイルには含まれていることがあります。その場合、{{ic|prepare}} ステップを使用して、ネストされたメイン実行可能ファイルを抽出し (詳細については [[ノンフリーアプリケーションパッケージガイドライン#解凍|解凍]] を参照)、その後、{{ic|pkgver}} を自動バンプすることができます。

例えば:

{{bc|<nowiki>
pkgver=VERSION
makedepends=('p7zip' 'pev')

prepare() {
mkdir -p "${srcdir}/${pkgname}-unpacked"
7z x -o"${srcdir}/${pkgname}-unpacked" "${srcdir}/NonFreePackageWithPoorFileName.exe"
}

pkgver() {
peres -v -f csv "${srcdir}/${pkgname}-unpacked/NonFreeApp.exe" \
| awk -F , '/^Product Version,/ { print $2 }'
}</nowiki>
}}

Labwc

2025-04-11T14:46:15Z

Oech3: 英語版と同じに変更/* Xwayland */

[[Category:Wayland コンポジタ]]
[[en:Labwc]]
{{Related articles start}}
{{Related|ウィンドウマネージャ}}
{{Related|Wayland#コンポジタ}}
{{Related articles end}}
Labwc は Lab Wayland Compositor[https://github.com/labwc/labwc/blob/master/README.md] の略です。
[https://labwc.github.io/ 公式ウェブサイト]によると：

:Labwc は wlroots ベースのウィンドウスタッキングコンポジターで、Wayland 用に開発されました。openbox に触発されています。
:軽量で独立しており、ウィンドウを効果的にスタックし、いくつかのウィンドウ装飾を描画することに焦点を当てています。パネル、スクリーンショット、壁紙などをクライアントに依存して、フルデスクトップ環境を作成します。
:Labwc は、一般的なアプローチとコーディングスタイルの点で wlroots や sway と一致しようと試みています。
:Labwc は、wayland-protocols と wlr-protocols のみを理解し、dbus や sway/i3-IPC などの他の技術で制御することはできません。その理由は、カスタム IPC とプロトコルが Wayland の一般的な採用を妨げるフラグメンテーションを作り出すと考えているからです。

== インストール ==

Labwc は、パッケージ {{Pkg|labwc}} または {{AUR|labwc-git}} で[[インストール]]できます。

デフォルトの[[ターミナルエミュレータ]]は {{Pkg|foot}} です。''labwc'' を開始する前に、それをインストールするか、設定で新しいターミナルを設定することが推奨されます。

== Configuration ==

Openbox 3.6 の仕様を設定とテーマの構文に使用します。
~/.config/labwc/ の設定レイアウト：

:- autostart
:- environment
:- menu.xml
:- rc.xml
:- themerc-override
:- shutdown

詳細は `man labwc-config` と `man labwc-theme` を参照してください。rc.xml.all には、すべてのオプションを含むデフォルト設定が含まれています。

サンプル設定ファイルを {{ic|/usr/share/doc/labwc/}} から {{ic|~/.config/labwc/}} にコピーしてください。

より多くの設定については、[https://labwc.github.io/integration.html integration] を参照してください。

=== 自動起動 ===

~/.config/labwc/autostart を自動起動として使用します。

=== キーマップ ===

~/.config/labwc/environment にて

以下のキーボード設定変数がサポートされています：XKB_DEFAULT_RULES, XKB_DEFAULT_MODEL, XKB_DEFAULT_LAYOUT, XKB_DEFAULT_VARIANT, XKB_DEFAULT_OPTIONS：
XKB_DEFAULT_LAYOUT=us
XKB_DEFAULT_LAYOUT=us,de
XKB_DEFAULT_OPTIONS=grp:alt_shift_toggle
XKB_DEFAULT_OPTIONS=grp:shift_caps_toggle
詳細は {{man|7|xkeyboard-config}} を参照してください。

=== キーリピートの遅延と速度 ===

キーリピートの遅延と速度を変更するには、入力セクションに以下の行を追加します。これらはデフォルト値です：
{{hc|~/.config/labwc/rc.xml|
<keyboard>
<repeatRate>25</repeatRate>
<repeatDelay>600</repeatDelay>
</keyboard>
}}

=== ステータスバー ===

{{Pkg|waybar}} が使用できます。
{{hc|~/.config/labwc/autostart|
waybar >/dev/null 2>&1 &
}}
{{man|5|waybar-wlr-taskbar}} でトップレベルフォーリンプロトコルを通じてタスクバーを有効にします。
{{hc|~/.config/waybar/config|
"modules-left": ["wlr/taskbar"],

"wlr/taskbar": {
"format": "{app_id}",
"on-click": "minimize-raise",
},
}}

=== 出力 ===

外部ツールとして {{Pkg|wlr-randr}},{{Pkg|kanshi}} を使用することができます。{{hc|~/.config/labwc/autostart|
wlr-randr --output HDMI-A-2 --preferred --pos 0,0 --output HDMI-A-1 --preferred --pos -1920,0

}}

==== 壁紙 ====

自動起動と壁紙セッター [https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway#wallpaper setter] として {{Pkg|swaybg}}, {{Pkg|wallutils}}, {{Pkg|wpaperd}}, {{Aur|wbg}} などを使用します
{{hc|~/.config/labwc/autostart|
swaybg -c '#113344' >/dev/null 2>&1 &
}}

=== カスタムキーバインド ===

{{hc|~/.config/labwc/rc.xml|
2=
<keyboard>
<keybind key="W-d"> <action name="Execute" command="fuzzel"/> </keybind>
<keybind key="XF86_AudioLowerVolume"> <action name="Execute" command="wpctl set-volume @DEFAULT_AUDIO_SINK@ 5%-"/> </keybind>
<keybind key="XF86_AudioRaiseVolume"> <action name="Execute" command="wpctl set-volume @DEFAULT_AUDIO_SINK@ 5%+"/> </keybind>
<keybind key="XF86_AudioMute"> <action name="Execute" command="wpctl set-mute @DEFAULT_AUDIO_SINK@ toggle "/> </keybind>
<keybind key="XF86_MonBrightnessUp"> <action name="Execute" command="brightnessctl -e set 5%+"/> </keybind>
<keybind key="XF86_MonBrightnessDown"> <action name="Execute" command="brightnessctl -e set 5%-"/> </keybind>
</keyboard>
}}

==== ワークスペース ====

{{hc|~/.config/labwc/rc.xml|
2=
<labwc_config>
<desktops number="4" />
<keyboard>
<keybind key="W-1"> <action name="GoToDesktop" to="1" /> </keybind>
<keybind key="W-2"> <action name="GoToDesktop" to="2" /> </keybind>
<keybind key="W-3"> <action name="GoToDesktop" to="3" /> </keybind>
<keybind key="W-4"> <action name="GoToDesktop" to="4" /> </keybind>
</keyboard>

</labwc_config>
}}

=== メニュー ===

Openbox の仕様に基づくメニューを使用します。/usr/share/doc/labwc/menu.xml と man labwc-menu を参照してください。また、Openbox 用の自動メニュージェネレーターとして {{Pkg|archlinux-xdg-menu}}, {{Aur|obmenu-generator}} などが使用できます。

例：
<?xml version="1.0" ?>
<openbox_menu>
<menu id="root-menu" label="">
<item label="󰈹 Firefox">
<action name="Execute" command="firefox" />
</item>
<item label=" Terminal">
<action name="Execute" command="foot" />
</item>
</menu>
</openbox_menu>

=== Xwayland ===

{{Pkg|xorg-xwayland}} は、ビルド時に Xwayland サポートが有効な場合、自動的に起動します。
それを無効にするには、以下を設定します：
{{hc|~/.config/labwc/enviroment|
2=WLR_XWAYLAND=
}}

== 起動方法 ==

seat 用のすべての wlroots ベースのコンポジターと同様に、ユーザーが {{ic|seat}}[[ユーザーグループ]]に追加された systemd-logind または {{Pkg|seatd}} サービスを使用する場合は、{{Pkg|polkit}} が必要です

Labwc を起動するには、Linux コンソールで {{ic|labwc}} と入力します。

{{ic|labwc -s foot}} で foot を実行しながら labwc を開始します。

== 参照 ==

* [https://github.com/labwc/labwc GitHub プロジェクト]
* [https://labwc.github.io/ ウェブサイト]

{{TranslationStatus|Labwc|2024-6-24|809219}}

セキュリティ

2025-04-09T15:33:20Z

Oech3: 同期/* SUID ファイルと SGID ファイル */

[[Category:セキュリティ]]
[[Category:ファイルシステム]]
[[Category:ネットワーク]]
[[en:Security]]
[[fa:امنیت]]
[[ru:Security]]
[[zh-hans:Security]]
{{Related articles start}}
{{Related|PAM}}
{{Related|ケイパビリティ}}
{{Related|アプリケーション一覧/セキュリティ}}
{{Related|:カテゴリ:セキュリティ}}
{{Related articles end}}
この記事には、Arch Linux システムを[[Wikipedia:ja:ハードニング|ハードニング]]するための推奨事項とベストプラクティスを並べています。

== 概念 ==

* システムのセキュリティを厳重にしすぎると、使い物にならなくなることもある。セキュリティと利便性のバランスを取ることが重要だ。重要なのは、安全で ''かつ'' 使いやすいシステムを作ること。
* 最大の脅威は常にユーザー自身である。
* [[Wikipedia:ja:最小権限の原則|最小権限の原則]]: システムの各部分は、必要最小限の権限のみを持つべきであり、それ以上のアクセスは許可されるべきではない。
* 多層防御 (Defense in Depth): セキュリティは独立した複数の層で成り立つべきである。一つの層が突破されても、次の層が攻撃を食い止める仕組みが必要です。
* 少しだけ疑い深くなること。常に警戒すること。うますぎる話には注意すべきだ。それが本当である可能性は低いと思うこと。
* システムを100%安全にする方法はただ一つ。それはネットワークから切り離し、電源を切り、金庫に入れ、コンクリートで固め、二度と使用しないこと。
* 失敗を想定せよ。セキュリティが破られたときに備え、あらかじめ対応策を準備しておくこと。

==パスワード==
パスワードは安全な linux システムのかぎです。パスワードは[[ユーザーとグループ|ユーザーアカウント]], [[ディスク暗号化|暗号化されたファイルシステム]], [[SSH 鍵|SSH]]/[[GPG]] 鍵などを守ります。コンピュータを使用する人を信頼するのに使う主要な手段なので、安全なパスワードを選んでそれを保護するというのがセキュリティの大部分と言っても過言ではありません。

=== 安全なパスワードの選び方 ===

パスワードは、個人情報などから簡単に推測されないよう十分に複雑であり、また、ソーシャルエンジニアリングやブルートフォース攻撃などの手法で[[Wikipedia:Password cracking|クラック]]されないようにする必要があります。強力なパスワードの基本原則は、''長さ''と''ランダム性''に基づいています。暗号学では、パスワードの品質はその[[Wikipedia:Password strength#Entropy as a measure of password strength|エントロピー]]によって測られます。

安全でないパスワードには、以下のようなものが含まれます。また、以下のようなものを元に変更や置き換えを行った場合も同様に危険です。

* 個人を特定できる情報(例:ペットの名前、生年月日、市外局番、好きなビデオゲームなど)
* 単純な文字の置き換えを行った単語(例:{{ic|k1araj0hns0n}})最新の辞書攻撃ではこれらも簡単に解析可能
* 既存の "単語" や一般的な文字列の前後に数字・記号・文字を追加したもの(例:{{ic|DG091101%}})
* 一般的なフレーズや辞書にある単語を短く組み合わせたもの(例:{{ic|photocopyhauntbranchexpose}})文字の置き換えを行っても(例:{{ic|Ph0toc0pyh4uN7br@nch3xp*se}})、安全とは限らない(ただし、後述の "Diceware" を利用した場合は例外あり)
* [[Wikipedia:List of the most common passwords|最も一般的なパスワード]]のいずれか

最も安全なパスワードは、十分に長く(長いほど良い)ランダムなソースから生成されたものです。長いパスワードを使用することが重要です。[https://www.theregister.com/2019/02/14/password_length 弱いハッシュアルゴリズムを使用すると、8文字のパスワードハッシュはわずか数時間で解読可能] です。

{{Pkg|pwgen}} や {{AUR|apg}} のようなツールを使用すると、ランダムなパスワードを生成できます。しかし、これらのパスワードは覚えにくいことがあります。覚えやすくするための1つの方法は、長いパスワードを生成し、最初は最低限の安全な文字数だけを暗記し、完全な文字列を一時的に書き留めることです。時間をかけて入力する文字数を増やしていけば、最終的にはパスワードが筋肉の記憶として定着し、完全に覚える必要がなくなります。この方法は難易度が高いものの、辞書攻撃や "知的" ブルートフォース攻撃(単語の組み合わせや文字の置き換えを考慮する攻撃)に対して非常に強力です。

パスワード管理とは別に、{{Pkg|keepassxc}} はパスワード/パスフレーズの生成機能を提供します。GUI でカスタマイズ可能なパスワード生成機能があり、辞書ベースのパスフレーズもサポートされています。

パスワードを覚えるための1つの方法として、**記憶術(ニーモニック)**を利用することが挙げられます。
例えば、"the girl is walking down the rainy street" というフレーズは、以下のようなパスワードに変換できます。簡単な例:{{ic|t6!WdtR5}} より複雑な例:{{ic|t&6!RrlW@dtR,57}}
この方法は、パスワードを覚えやすくすることができますが、英単語の最初の文字には偏りがあることに注意が必要です([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]] を参照)

また、ランダムに生成したパスワードを紙に書いて安全な場所に保管するという方法も有効です。例えば、財布、カバン、金庫などに保管するのがよいでしょう。ほとんどの人は、デジタルセキュリティよりも物理的な貴重品の保護に関しては理解しやすいため、この方法は現実的です。

さらに、記憶術とランダム生成を組み合わせる方法も効果的です。例えば、長くランダムに生成したパスワードを[[パスワードマネージャ]]に保存し、それをマスターパスワードで管理する方法です。マスターパスワードは記憶し、絶対に保存しないようにします。この方法では、パスワードマネージャーがインストールされているシステムでのみパスワードにアクセスできるようになり、状況によっては不便にもなりますが、セキュリティ強化の側面もあります。一部のパスワードマネージャーにはスマートフォンアプリもあり、手入力が必要な場合にパスワードを表示することができます(この場合、完全にランダムなものではなく、タイピングしやすいが安全なパスワードを使うことも検討できます)ただし、マスターパスワードを忘れるとすべてのパスワードにアクセスできなくなるため、単一障害点になり得ることに注意が必要です。
また、一部のパスワードマネージャーは、保存するパスワードを暗号化するのではなく、マスターパスワードとサービス名から計算する方式を採用しており、新しいシステムでもデータ同期なしで使用できます。

覚えやすく、それでいて強力なパスワードの作成方法として、無関係な単語を複数組み合わせたパスフレーズを使うという方法もあります。この方法では、十分に長いフレーズを使用することで、辞書単語を使うことによるエントロピーの損失を補うことができます。この手法のエントロピーのトレードオフについては、[https://xkcd.com/936/ xkcdのコミック] に示されています。この方法の安全性は、選択可能な単語の集合が大きい(数千語以上)ことと、5〜7語以上のランダムな単語を選択することによって保証されます。攻撃者が選択可能な単語の集合と、使用する単語数を知っていたとしても、(選択可能な単語数) の (選択する単語数) 乗の通りのパスフレーズが生成可能であり、安全性が確保されます。詳細については [https://www.rempe.us/diceware/ Diceware] を参照してください。

さらに詳しい情報については、[https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] や [[Wikipedia:Password strength]] も参考になります。

=== パスワードの管理 ===

強力なパスワードを選んだら、それを安全に保管することが重要です。[[Wikipedia:Keylogger|キーロガー]] (ソフトウェアおよびハードウェア)、スクリーンロガー、[[Wikipedia:Social engineering (security)|ソーシャルエンジニアリング]]、[[Wikipedia:Shoulder surfing (computer security)|ショルダースーフィング]]に注意し、パスワードの使い回しを避けて、セキュリティの低いサーバーから不要な情報が漏れないようにしましょう。[[アプリケーション一覧/セキュリティ#パスワードマネージャ|パスワードマネージャ]]を使用すると、大量の複雑なパスワードを管理できます。パスワードマネージャーからアプリケーションに保存されたパスワードをコピー&ペーストして使用する場合は、毎回コピーした内容をクリアし、ログに保存されないようにしてください(例:プレーンテキストのターミナルコマンドにペーストしないようにし、{{ic|.bash_history}} などのファイルに保存されないようにします)ブラウザ拡張として実装されたパスワードマネージャは、[https://www.spookjs.com サイドチャネル攻撃]に脆弱である可能性があります。これを回避するためには、別のアプリケーションとして実行されるパスワードマネージャーを使用することが推奨されます。

原則として、強力なパスワードを覚えにくいからといって、セキュリティが低いパスワードを選んではいけません。パスワードはバランスを取る必要があります。強力なマスターパスワードと鍵で守られた暗号化された安全なパスワードデータベースを持つ方が、多くの似たような弱いパスワードを使うよりも優れています。パスワードを紙に書いて保管することも、[https://www.schneier.com/blog/archives/2005/06/write_down_your.html] で示されているように、ソフトウェアの脆弱性を避けつつ物理的なセキュリティを確保できるため、非常に効果的です。

パスフレーズの強度のもう一つの側面は、それが他の場所から簡単に回復できないことです。

ディスク暗号化のパスフレーズをログインパスワードと同じに使用する場合(例えば、ログイン時に暗号化されたパーティションやフォルダを自動マウントする場合)、{{ic|/etc/shadow}} が暗号化されたパーティションに保存されるか、または強力な鍵導出関数 (i.e. yescrypt/argon2 や sha512 を PBKDF2 で使用、md5 や低回数の PBKDF2 は避ける) を使用して保存されたパスワードハッシュを使うようにしてください (詳細については [[SHA hashes#SHA パスワードハッシュ|SHA パスワードハッシュ]] を参照してください)

{{Tip|Arch Linux は [https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのハッシュアルゴリズム]を yescrypt に変更しました。もしデフォルトをカスタマイズしていない場合は、{{ic|passwd}} を実行してパスワード変更を行うなどして下さい。}}

パスワードデータベースをバックアップする場合、そのコピーが他のパスフレーズで保護されていないことを確認してください。例えば、暗号化されたドライブや認証されたリモートストレージサービスなどです。もしそのような保護が施されている場合、必要なときにアクセスできなくなります。役立つ方法としては、データベースがバックアップされているドライブやアカウントをマスターパスワードの簡単な暗号学的ハッシュで保護することです。バックアップ場所のリストを保持してください。もしもマスターパスワードが漏洩したと疑われる場合、その場所すべてでパスワードを即座に変更し、マスターパスワードから導出された鍵で保護されたすべてのバックアップと場所も変更する必要があります。

データベースをセキュアにバージョン管理するのは非常に複雑な場合があります。もしその方法を選択するなら、すべてのデータベースバージョンでマスターパスワードを更新する手段を持っている必要があります。マスターパスワードが漏洩したときにそれを即座に知るのは難しいことがあります。他の人がパスワードを発見するリスクを減らすために、定期的にパスワードを変更することを選ぶかもしれません。もしデータベースのコピーの管理が失われたと感じた場合、そのコピーがブルートフォース攻撃によってマスターパスワードを解読される前に、そのデータベース内のすべてのパスワードを変更する必要があります。

=== パスワードのハッシュ ===

ハッシュは一方向の関数です。つまり、入力を計算せずにそのハッシュを解読することは不可能になるように設計されています (例:MD5、SHA)

パスワードハッシュ関数は、ユーザー入力 (パスワード) を計算せずに解読することが不可能になるように設計されています(例:bcrypt)[[Wikipedia:Key derivation function|鍵導出関数]] (KDF; 例:yescrypt、scrypt、PBKDF2) は、入力 (マスターキーやパスワード) から秘密鍵 (例:AESキー、パスワードハッシュ) を導出するために設計された暗号アルゴリズムです。したがって、KDF はパスワードハッシュ関数としても使用できる複数の用途に対応します。

デフォルトでは、Arch Linux はユーザーパスワードをルート専用の読み取り可能な {{ic|/etc/shadow}} ファイルにハッシュ化して保存します。これは、他のユーザーのパラメータが保存される世界に読み取り可能な {{ic|/etc/passwd}} ファイルから分離されています。詳細は [[ユーザーとグループ#ユーザーデータベース]] を参照してください。また、[[#root の制限]] も参照してください。

パスワードは '''passwd''' コマンドを使用して設定され、このコマンドはシステムの暗号化関数でパスワードを[[Wikipedia:Key stretching|ストレッチ]]し、その後 {{ic|/etc/shadow}} に保存されます。パスワードは[[Wikipedia:Salt (cryptography)|ソルト]]も施され、[[Wikipedia:Rainbow table|レインボーテーブル]]攻撃に対して防御されます。詳細は[https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils Linux でパスワードがどのように保存されているか(Shadow ユーティリティを使ったハッシュの理解)]を参照してください。

パスワードハッシュは定義されたフォーマットに従って保存されるため、新たな ''passwd'' コマンドの実行に対してメソッドとパラメータを設定することができます。したがって、{{ic|/etc/shadow}} ファイルに保存された個々のハッシュは、システムでサポートされているハッシュ関数の異種混合になる可能性があります。

フォーマット、ハッシュメソッド、およびパラメータに関する詳細は、{{man|5|crypt}} を参照してください。

{{ic|/etc/login.defs}} ファイルでは、[https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのパスワードハッシュメソッド]{{ic|ENCRYPT_METHOD YESCRYPT}} とそのパラメータ {{ic|YESCRYPT_COST_FACTOR}} が設定されます。

例えば、デフォルトの {{ic|YESCRYPT_COST_FACTOR}} パラメータを増加させると、パスワードからハッシュを導き出すために必要な計算時間が対数的に増加します。これは、システムがユーザーのログインを認証する際や、第三者がパスワードの秘密を取得しようとする場合にも適用されます。

これに対して、SHA-512 ハッシュ関数の計算時間は、パラメータにより線形的に影響されます。以前の Arch のデフォルトについては [[SHA パスワードハッシュ]] を参照してください。yescrypt アルゴリズムは内部で SHA-256、HMAC、およびPBKDF2 を使用してパスワードハッシュを計算することに注意してください。主な理由は、これらの広く使用され、テストされた関数の良い特性を組み合わせ、攻撃への耐性を強化することです。例えば、SHA の多用途性が原因で、この関数のハードウェアサポートが提供され、SHA ハッシュの計算性能が著しく向上したため、パスワードハッシュ関数としての使用が次第に時代遅れになりつつあります。

=== pam_cracklib を用いた強力なパスワードの強制 ===

''pam_pwquality'' は、[[Wikipedia:Dictionary attack|辞書攻撃]]に対する保護を提供し、システム全体で強制できるパスワードポリシーを設定するのに役立ちます。これは ''pam_cracklib'' をベースにしており、そのオプションとの後方互換性があります。

{{Pkg|libpwquality}} パッケージを[[インストール]]してください。

{{Warning|デフォルトでは、''root'' アカウントはこのポリシーの影響を受けません。}}

{{Note|
* ''root'' アカウントを使用すると、設定したパスワードポリシーをバイパスするユーザーパスワードを設定できます。これは一時的なパスワードを設定する際に便利です。
* 現在のパスワードに関するセキュリティガイドライン(例:NISTなど)では、特別な文字を強制することは推奨されていません。なぜなら、それらはしばしば予測可能な変更を引き起こすだけだからです。
}}

例えば、以下のポリシーを強制したい場合:

* エラーが発生した場合にパスワードを2回入力する (retry オプション)
* 最小長10文字 (minlen オプション)
* 新しいパスワードを入力する際、古いパスワードとは少なくとも6文字異なること (difok オプション)
* 最低1桁の数字 (dcredit オプション)
* 最低1つの大文字 (ucredit オプション)
* 最低1つの小文字 (lcredit オプション)
* 最低1つのその他の文字 (ocredit オプション)
* "myservice" および "mydomain" という単語を含めない
* root にもこのポリシーを強制する

{{ic|/etc/pam.d/passwd}}ファイルを以下のように編集します:

{{bc|1=
#%PAM-1.0
password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root
password required pam_unix.so use_authtok sha512 shadow
}}

{{ic|password required pam_unix.so use_authtok}} は、''pam_unix'' モジュールに対してパスワードの入力を促さず、代わりに ''pam_pwquality'' で提供されたものを使用するように指示します。

詳細については、{{man|8|pam_pwquality}} および {{man|8|pam_unix}} のマニュアルページを参照してください。

== CPU ==

=== マイクロコード ===

CPU のマイクロコードに対する重要なセキュリティ更新プログラムをインストールする方法については、[[マイクロコード]] を参照してください。

=== ハードウェアの脆弱性 ===

CPU の中には、ハードウェアの脆弱性を含んでいるものがあります。これらの脆弱性の一覧と、特定の使用シナリオに合わせてこれらの脆弱性を緩和するためにカーネルをカスタマイズするのに役立つ緩和策の選択ガイドについては、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/ kernel documentation on hardware vulnerabilities] を参照してください。

既知の脆弱性の影響を受けているかどうかを確認するには、以下を実行してください。

$ grep -r . /sys/devices/system/cpu/vulnerabilities/

ほとんどの場合、カーネルとマイクロコードを更新することで、脆弱性を軽減することができます。

==== 同時マルチスレッディング (ハイパースレッディング) ====

[https://ja.wikipedia.org/wiki/%E5%90%8C%E6%99%82%E3%83%9E%E3%83%AB%E3%83%81%E3%82%B9%E3%83%AC%E3%83%83%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0 同時マルチスレッディング]] (SMT) は、インテル CPU のハイパースレッディングとも呼ばれ、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html L1 Terminal Fault] および [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html Microarchitectural Data Sampling] 脆弱性の原因となる可能性のあるハードウェア機能です。Linux カーネルとマイクロコードのアップデートには、既知の脆弱性に対する緩和策が含まれていますが、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html#virtualization-with-untrusted-guests 信頼できない仮想化ゲストが存在する場合、特定の CPU で SMT を無効にしたほうが良い場合があります。]

SMT は、システムのファームウェアで無効にできることがよくあります。詳細については、マザーボードまたはシステムのドキュメントを参照してください。また、以下の [[カーネルパラメータ]] を追加することで、カーネルで SMT を無効にすることができます。

l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force

== メモリ ==

===ハード化された malloc ===

[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened_malloc}}, {{AUR|hardened-malloc-git}}) は [https://ja.wikipedia.org/wiki/GNU_C%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA glibc] の malloc() をハード化した代替品です。元々は Android の [[Wikipedia:Bionic (software)|Bionic]] と [https://ja.wikipedia.org/wiki/Musl musl] に組み込むために開発されましたが、 x86_64 アーキテクチャの標準 Linux ディストリビューションのサポートにも組み込みました。

hardened_malloc はまだ glibc に統合されていませんが(支援とプルリクエストは歓迎します)、LD_PRELOAD と一緒に簡単に使用することができます。これまでのテストでは、 {{ic|/etc/ld.so.preload}} でグローバルに有効にすると、一握りのアプリケーションにしか問題を起こしません。例えば、{{ic|getrandom}} が標準のホワイトリストにないため、{{ic|seccomp}} 環境フラグが無効でないと {{ic|man}} は正常に動作しませんが、これはシステムコールを追加して再構築すれば簡単に修正可能です。hardened_malloc は性能上のコストがあるので、どの実装を使うかは攻撃対象領域と性能上の必要性に基づいてケースバイケースで決めるとよいでしょう。

スタンドアロンで試すには、hardened-malloc-preload ラッパースクリプトを使用するか、適切なプリロード値でアプリケーションを手動で開始します。

LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox

[[Firejail]] の正しい使い方は、その wiki ページにあります。また、hardened_malloc の設定可能なビルドオプションは、githubレポで見つけることができます。

== ストレージ ==

===ディスク暗号化===

[[ディスク暗号化]]、特に [[#パスワード|強力なパスフレーズ]] を使用したフルディスク暗号化は、物理的な回復からデータを守る唯一の方法です。これにより、コンピュータの電源がオフになっている場合や、対象のディスクがアンマウントされている場合にデータの機密性が保たれます。

ただし、コンピュータの電源が入っており、ドライブがマウントされている場合、そのデータは暗号化されていないドライブと同様に脆弱です。そのため、データパーティションがもう必要なくなったら、できるだけ早くアンマウントすることが最良の実践です。

また、[[Trusted Platform Module#LUKS による保存データの暗号化|TPMにキーを保存してドライブを暗号化]] することもできますが、過去に [https://tpm.fail 脆弱性] があり、キーは [https://pulsesecurity.co.nz/articles/TPM-sniffing TPMバススニッフィング攻撃] によって抽出される可能性があります。

[[dm-crypt]] のような特定のプログラムは、ユーザーが仮想ボリュームとしてループファイルを暗号化できるようにします。これは、システムの特定の部分だけを安全に保護する必要がある場合、フルディスク暗号化の合理的な代替手段です。

[[ディスク暗号化]] の記事で比較されているブロックデバイスやファイルシステムベースの暗号化方法は、物理メディア上のデータ保護には有効ですが、リモートシステム(例えば [[保存データ暗号化#クラウドストレージの最適化|クラウドストレージ]])に保存されたデータを保護するためには使用できません。そのため、個々のファイル暗号化が役立つ場合もあります。

ファイルを暗号化するためのいくつかの方法は次の通りです:

* 一部の [[アーカイブと圧縮|アーカイブおよび圧縮]] ツールは基本的な暗号化も提供します。例としては、[[7-Zip]] ({{ic|-p}} フラグ)、{{Pkg|zip}} ({{ic|-e}}フラグ) があります。これらのツールはクロスプラットフォームの互換性のためにカスタムアルゴリズムを使用している場合があるため、特別な注意を払って使用するべきです。[https://math.ucr.edu/~mike/zipattacks.pdf]
* [[GnuPG]] を使用してファイルを [[GnuPG#Encrypt and decrypt|暗号化]] できます。
* {{Pkg|age}} は、シンプルで使いやすいファイル暗号化ツールです。複数の受信者をサポートしており、SSH キーを使用した暗号化もサポートしているため、安全なファイル共有に役立ちます。

=== ファイルシステム ===

現在カーネルは {{ic|fs.protected_hardlinks}} や {{ic|fs.protected_symlinks}} sysctl スイッチが有効になっていればハードリンクやシンボリックリンクに関するセキュリティの問題を解決するので、world-writable なディレクトリを分離させるセキュリティ的な利点はもはや存在しません。

それでもディスク容量が消耗したときのダメージを低減させる荒っぽい方法として world-writable なディレクトリを含むパーティションが分割されることがあります。しかしながら、サービスを落とすには {{ic|/var}} や {{ic|/tmp}} などのパーティションを一杯にするだけで十分です。この問題の対処についてはもっと柔軟性のある方法が存在します (クォータなど)、またファイルシステムによっては関連する機能を持っていることがあります (btrfs はサブボリュームにクォータを設定できます)。

====マウントオプション====

最小特権の原則に従い、ファイルシステムは可能な限り制限の厳しいマウントオプションを使用してマウントするべきです(機能を失わない範囲で)

関連するマウントオプションは以下の通りです:

* {{ic|nodev}}: ファイルシステム上のキャラクタデバイスやブロックデバイスを解釈しない。
* {{ic|nosuid}}: set-user-identifier や set-group-identifier ビットを無効にする。
* {{ic|noexec}}: マウントされたファイルシステム上のバイナリを直接実行できないようにする。
** {{ic|/home}} に {{ic|noexec}} を設定すると、実行可能なスクリプトが禁止され、[[Wine]]、[[Steam]]、PyCharm、[[.NET]] などが動作しなくなります。
*** Wine は Windows バイナリの実行に {{ic|exec}} フラグを必要としません。ただし、Wine 自体を {{ic|/home}} にインストールする場合は必要です。
*** [[Steam]] を動作させるには、{{ic|/home/user/.local/share/Steam}} を [[fstab]] で {{ic|exec}} としてマウントできます。以下の設定を追加してください: {{bc|/home/user/.local/share/Steam /home/user/.local/share/Steam none defaults,bind,user,exec,nofail 0 0}}
** 一部のパッケージ(例:{{Pkg|nvidia-dkms}} のビルド)では、{{ic|/var}} に {{ic|exec}} が必要な場合があります。

データ用のファイルシステムは、常に {{ic|nodev}}、{{ic|nosuid}}、{{ic|noexec}} を指定してマウントするべきです。

マウントを検討すべきファイルシステム:

* {{ic|/var}}
* {{ic|/home}}
* {{ic|/dev/shm}}
* {{ic|/tmp}}
* {{ic|/boot}}

{{Tip|[[systemd#GPT パーティションの自動マウント|GPT パーティションの自動マウント]] を使用する場合、ESP および XBOOTLDR パーティションは [https://github.com/systemd/systemd-stable/commit/49804cfb71d3a79f433096e4cfb5616980171336 常に {{ic|noexec,nosuid,nodev}} で強化] されます。}}

==== スナップショット ====

ファイルシステムのスナップショットを利用する場合(例えば [[Btrfs]]、[[LVM]]、[[ZFS]] など)、スナップショットがユーザーが削除したと期待している機密情報を保持する可能性があることを理解することが重要です。特に、[[Snapper]] のような自動スナップショットツールを設定している場合、定期的またはシステムイベントに応じてスナップショットが作成されるため、この問題が発生しやすくなります。

以下は、{{ic|/home/}} 内の機密情報がスナップショットに残存する例です:

* 削除されたファイルやディレクトリ: ファイルシステム上から削除されたとしても、古いスナップショット内には残存している可能性があります。これは通常想定される動作ですが、{{ic|.local/share/Trash/}}、{{ic|.history}} などのファイルやディレクトリを保持する必要があるかどうかを検討すべきです。
* 一時ファイルやキャッシュ: アプリケーションによって生成された一時ファイルやキャッシュデータもスナップショットに含まれる可能性があります。例えば、暗号化されたディレクトリ内のファイルを開くと、サムネイル({{ic|.cache/thumbnails}})や作業用のコピーが作成され、それらがスナップショットに含まれる可能性があります。同様に、ブラウザの履歴({{ic|.mozilla/}}、{{ic|.config/chromium/}} など)も、削除される前にスナップショットに記録されている場合があります。

対応可能であれば、これらのディレクトリをスナップショットの対象から完全に除外することを検討してください。例えば、[[Btrfs]] を使用している場合、{{ic|.cache/}}、{{ic|.config/}}、{{ic|.local/}}、{{ic|.var/}} など、用途に応じたディレクトリをサブボリュームとして作成することで、スナップショットの影響を受けにくくできます。

{{Note|{{ic|.local/share/Trash}} を別のサブボリュームに移動すると、場合によっては [[GNOME/Files]] などでゴミ箱の機能が正常に動作しなくなる可能性があります。}}

===ファイルシステムのパーミッション===

デフォルトの [[パーミッション]] では、ほとんどのファイルが読み取り可能になっていますが、これを変更することで、{{ic|http}} ユーザーや {{ic|nobody}} ユーザーなどの非 root アカウントに侵入した攻撃者から貴重な情報を隠すことができます。[[chmod]] を使用して、グループやその他のユーザーからすべてのアクセス権を削除できます。

# chmod go-r ''path_to_hide''

{{Warning|この設定を広範囲に適用しないでください。1つの設定ファイルごとに適用し、非表示にする価値があるか、プログラムの動作に影響しないかを確認してください。グループが必要な場合は、{{ic|g}} をコマンドから削除するか、既に実行してしまった場合は {{ic|chmod g+r path}} で再度許可を追加する必要があるかもしれません。}}

考慮すべきパスの例:

* {{ic|/boot}}: [[パーティショニング#/boot|ブートディレクトリ]]、[[vmlinuz]] や [[initramfs]] image、または [[ユニファイドカーネルイメージ]] が含まれる場合があります。なお、[[systemd# GPT パーティションの自動マウント]] を使用する場合、デフォルトで安全なパーミッションが適用されます。
* {{ic|/etc/nftables.conf}}: [[nftables]] の設定ファイル({{Pkg|nftables}} および {{Pkg|iptables-nft}} に適用)
* {{ic|/etc/iptables}}: レガシーな [[iptables]] の設定ファイル({{Pkg|iptables}} に適用)

また、新しく作成されるファイルのセキュリティを向上させるために、デフォルトの [[umask]] 値 {{ic|0022}} を変更することも可能です。[https://apps.nsa.gov/iaarchive/library/ia-guidance/security-configuration/operating-systems/guide-to-the-secure-configuration-of-red-hat-enterprise.cfm NSA RHEL5 Security Guide] では最大限のセキュリティを確保するために、{{ic|0077}} を推奨しており、これにより所有者以外のユーザーが新しいファイルを読み取れなくなります。変更方法については [[Umask#マスクの値を設定]] を参照してください。

さらに、[[sudo]] を使用する場合、[[Sudo#Permissive umask|デフォルトの root umask]] を適用するよう設定することを検討してください。

=== SUID ファイルと SGID ファイル ===

[[Wikipedia:ja:Setuid|Setuid]] ビットや Setgid ビットが設定されたファイルには注意しましょう。このようなファイルの例としては、以下があります。

* [[PAM|unix_chkpwd]]
* chage expiry gpasswd groupmems [[passwd]] sg ({{Pkg|shadow}} パッケージ)
* [[FUSE|fusermount3]]
* pkexec polkit-agent-helper-1[https://github.com/polkit-org/polkit/pull/501] ([[polkit]] パッケージ)
* [[OpenSSH|ssh-keysign]]
* chfn chsh mount newgrp umount wall write ({{Pkg|util-linux}} パッケージ)
* [[sudo]] [[doas]] [[su]] [[Kerberos|ksu]]
* [[firejail]]
* [[Dbus|dbus-daemon-launch-helper]]
* [[Chromium|chromium-sandbox]]

このような実行ファイルの主なリスクとして、特権昇格の脆弱性があります。例えば [[Wikipedia:Setuid#Security impact]] を参照してください。[https://www.cvedetails.com/vulnerability-list/vendor_id-16224/product_id-36412/Calibre-ebook-Calibre.html][https://www.cvedetails.com/product/32625/Sudo-Project-Sudo.html?vendor_id=15714][https://www.cvedetails.com/vulnerability-list/vendor_id-16191/Firejail-Project.html]

SUID ビットが設定されているが root によって所有されていないファイル、または SGID ビットが設定されているファイルは、''典型的には''潜在的なリスクがより小さいですが、理論上、そのようなファイルに脆弱性が存在している場合は、依然として損害を与える可能性があります。通常、代わりに[[ケイパビリティ]]を割り当てることによって、Setuid や Setgid の使用を回避することが可能です。

{{Tip|SUID/SGID 実行ファイルを含むパッケージを最新に保って、脆弱性からシステムを守ることが肝心です。}}

SUID ビットか SGID ビットを持つファイルを {{ic|/usr/bin}} から探すには:

$ find /usr/bin -perm "/u=s,g=s"

== ユーザー設定 ==

=== root アカウントを日常的に使用しない ===

最小特権の原則に従い、root ユーザーを日常的に使用しないようにしてください。システムを使用する各人に非特権ユーザーアカウントを作成するか。一時的な特権アクセスには、必要に応じて [[sudo]] を使用する。

=== ログイン失敗後の遅延時間の設定 ===

以下の行を {{ic|/etc/pam.d/system-login}} に追加し、ログインに失敗した際に最低4秒の遅延を追加します。

{{hc|/etc/pam.d/system-login|2=
auth optional pam_faildelay.so delay=4000000
}}

{{ic|4000000}} は遅延させる時間をマイクロ秒単位で指定します。

===3回ログインを失敗したユーザーをロックアウトする===

{{Pkg|pambase}} 20200721.1-2 の時点では、デフォルトで {{ic|pam_faillock.so}} が有効になっており、15分間に3回ログインに失敗すると10分間ユーザをロックアウトします ({{Bug|67644}} を参照してください) このロックアウトはパスワード認証 (例:ログインと ''sudo'') にのみ適用され、SSH 経由の公開鍵認証はそのまま利用可能です。完全なサービス拒否を防ぐために、このロックアウトは root では無効になっています。

ユーザーをロック解除するには、次のようにします。

$ faillock --reset --user ''username''

デフォルトでは、ロック機構は {{ic|/run/faillock/}} にあるユーザーごとのファイルです。ディレクトリの所有者は root ですが、ファイルの所有者はユーザーなので、 {{ic|faillock}} コマンドはファイルを空にするだけで、root は必要ありません。

モジュール {{ic|pam_faillock.so}} は、ファイル {{ic|1=/etc/security/faillock.conf}} で設定することが可能です。ロックアウトのパラメータです。

* {{ic|unlock_time}} - ロックアウト時間 (秒単位、デフォルトは10分)
* {{ic|fail_interval}} - ロックアウトに失敗するとロックアウトされる時間 (秒単位、デフォルトは15分)
* {{ic|deny}} - ロックアウトするまでに何回ログインに失敗するか (デフォルトは 3)

{{Note|{{ic|1=deny = 0}} はロックアウトを無効化します}}

デフォルトでは、すべてのユーザーロックは再起動後に失われます。攻撃者がマシンをリブートできるのであれば、ロックは持続させた方が安全です。ロックを持続させるには、{{ic|1=/etc/security/faillock.conf}} の {{ic|dir}} パラメータを {{ic|/var/lib/faillock}} に変更する必要があります。

変更を反映させるために再起動する必要はありません。root アカウントのロックアウトを有効にする、集中ログイン (LDAP など) を無効にするなど、さらなる設定オプションについては {{man|5|faillock.conf}} を参照してください。

=== プロセスの数を制限する ===

信頼できないユーザーが大量に存在するシステムでは、一度に実行できるプロセスの数を制限して、[[Wikipedia:ja:Fork爆弾|フォーク爆弾]]などのサービス拒否攻撃を予防することが重要です。ユーザーやグループごとに実行できるプロセスの数は {{ic|/etc/security/limits.conf}} で定義することができ、デフォルトでは空になっています。以下の値をファイルに追加すると、実行できるプロセスが100個までに制限されます。{{ic|prlimit}} コマンドを使って一時的に上げられる最大数も200個までに制限します。ユーザーが普段実行するプロセスの数や、管理するハードウェアにあわせて適切な値に変更してください。

* soft nproc 100
* hard nproc 200

=== Wayland を使用する ===

[[Xorg]] よりも [[Wayland]] を使用することをお勧めします。Xorg の設計は現代のセキュリティ慣行より古く、多くの人が [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 は安全でないと考えています] 例えば、Xorg のアプリケーションは非アクティブな状態でもキーストロークを記録することがあります。

もし Xorg を実行しなければならないなら、[[Xorg#Rootless_Xorg|root での実行を避ける]]ことが推奨されます。Wayland 内では、XWayland 互換レイヤーは自動的に root レス Xorg を使用します。

== root の制限 ==
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。

=== su の代わりに sudo を使う ===
[[Su#セキュリティ|色々な理由]]から特権アクセスには [[su]] よりも [[sudo]] を使うほうが好ましいとされます。

* 通常の権限しか持たないユーザーが実行した特権コマンドのログを保持します。
* root アクセスを必要とする各ユーザーに root ユーザーのパスワードを与える必要がありません。
* 完全な root ターミナルは作成されないため、{{ic|sudo}} は root アクセスが必要ないコマンドを偶発的に ''root'' で実行してしまうことを防止します。これは[[Wikipedia:ja:最小権限の原則|最小権限の原則]]と合っています。
* 一つのコマンドを実行するためだけに完全な root アクセスを与える代わりに、ユーザーごとに個々のプログラムを有効にすることができます。例えば、ユーザー ''alice'' に特定のプログラムへのアクセス権限を与えるには:

# visudo

{{hc|/etc/sudoers|
alice ALL = NOPASSWD: /path/to/program}}

また、全てのユーザーに個別のコマンドを許可することも可能です。通常ユーザーでサーバーから Samba 共有をマウントするには:

%users ALL=/sbin/mount.cifs,/sbin/umount.cifs

これによって users グループのメンバーである全てのユーザーが全てのマシン (ALL) から {{ic|/sbin/mount.cifs}} や {{ic|/sbin/umount.cifs}} コマンドを実行できるようになります。

{{Tip|{{ic|visudo}} で {{ic|vi}} の代わりに {{ic|nano}} を使うには:

{{hc|/etc/sudoers|
2=Defaults editor=/usr/bin/rnano
}}
{{ic|1=# EDITOR=nano visudo}} のエクスポートは何にでも {{ic|EDITOR}} として使うことができるためにセキュリティリスクとされています。
}}

==== sudo を使ってファイルを編集する ====
root で {{ic|vim}} などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:

export SUDO_EDITOR=rvim

ファイルの編集には {{ic|sudoedit filename}} または {{ic|sudo -e filename}} を使って下さい。自動的に {{ic|rvim}} によって {{ic|filename}} が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。

=== root ログインの制限 ===
[[sudo]] を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。[[sudo]] を使える状態のまま root を無効化したい場合、{{ic|passwd -l root}} を使用します。

==== 特定のユーザーだけに許可を与える ====
[[Wikipedia:Pluggable authentication module|PAM]] の {{ic|pam_wheel.so}} は {{ic|wheel}} グループに入っているユーザーだけに {{ic|su}} を使用したログインを許可します。{{ic|/etc/pam.d/su}} と {{ic|/etc/pam.d/su-l}} の両方を編集して次の行をアンコメントしてください:
{{bc|<nowiki>
# Uncomment the following line to require a user to be in the "wheel" group.
auth required pam_wheel.so use_uid
</nowiki>}}
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。

==== ssh ログインを拒否する ====
ローカルユーザーの root ログインを拒否したくない場合でも、[[SSH#root ログインを拒否する|SSH による root ログインを拒否]]するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。

==== access.conf で許容されるログインの組み合わせを指定する ====

誰かが [[PAM]] でログインしようとすると、 {{ic|/etc/security/access.conf}} がそのログインプロパティに一致する最初の組み合わせをチェックします。そして、その組み合わせのルールに基づいて、試行が失敗するか成功するかが決まります。

+:root:LOCAL
-:root:ALL

特定のグループやユーザーに対してルールを設定することができます。この例では、ユーザー archie は、wheel および adm グループに属するすべてのユーザーと同様に、ローカルでのログインを許可されています。それ以外のログインは拒否されます。

+:archie:LOCAL
+:(wheel):LOCAL
+:(adm):LOCAL
-:ALL:ALL

詳しくは {{man|5|access.conf}} で確認してください。

==強制アクセス制御==

[[Wikipedia:ja:強制アクセス制御|強制アクセス制御]] (Mandatory Access Control, MAC) は Arch やほとんどの Linux ディストリビューションで使われている[[Wikipedia:ja:任意アクセス制御|任意アクセス制御]] (Discretionary Access Control, DAC) とは大きく異なるタイプのセキュリティポリシーです。原則的に MAC ではシステムに影響を与えるプログラムの行動は全てセキュリティルールセットによってチェックを受けます。このルールセットは、DAC とは対照的に、ユーザーが変更することは不可能です。実装方法は色々と異なるタイプが存在しますが、強制アクセス制御を使うことで実質的にコンピュータのセキュリティを著しく向上させることになります。

===パス名 MAC===
パス名ベースのアクセス制御は指定されたファイルのパスに基づいてパーミッションを与えるというシンプルな形式のアクセス制御です。この形式のアクセス制御の欠点としてはファイルが移動されてもパーミッションはファイルと一緒に付いていかないということが挙げられます。プラス面となるのは、パス名ベースの MAC はラベルベースの MAC と異なり、幅広いファイルシステムに実装できることです。

*[[AppArmor]] は [[Wikipedia:ja:カノニカル|Canonical]] によって開発されている MAC 実装で SELinux に比べて"簡単"になっています。
*[[TOMOYO Linux|Tomoyo]] はもうひとつのシンプルで、使いやすい強制アクセス制御を提供するシステムです。利用と実装の両面でシンプルになるように設計されており、依存するライブラリがとても少なくなっています。

===ラベル MAC===
ラベルベースのアクセス制御ではファイルの拡張属性を使ってセキュリティパーミッションを管理します。このシステムはセキュリティの機能においてパス名ベースの MAC よりも間違いなく柔軟性が高い一方、拡張属性をサポートしているファイルシステムでしか動作しません。

*[[SELinux]] は、Linux セキュリティを向上させる [[Wikipedia:ja:アメリカ国家安全保障局|NSA]] プロジェクトに基づいており、システムユーザーやロールとは完全に独立して MAC を実装しています。成長してオリジナルの設定が変わっていくシステムのコントロールを簡単に維持できる、極めて強固なマルチレベル MAC ポリシー実装を提供します。

=== アクセス制御リスト ===
[[アクセス制御リスト]] (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。

== カーネルの堅牢化 ==

=== カーネルの自己防衛機能/脆弱性攻撃対策 ===

{{pkg|linux-hardened}} パッケージは、[https://github.com/anthraxx/linux-hardened 基本的なカーネル堅牢化パッチセット]と、{{pkg|linux}} パッケージよりもセキュリティに重点を置いたコンパイル時設定オプションを使用します。カスタムビルドでは、セキュリティ寄りのデフォルトとは異なる、セキュリティと性能の妥協点を選択することができます。

しかし、このカーネルを使うといくつかのパッケージが動かなくなることに注意する必要があります。例えば

* {{AUR|skypeforlinux-preview-bin}}
* {{AUR|skypeforlinux-stable-bin}}
* {{pkg|throttled}}

[[NVIDIA]] などのアウトオブツリードライバを使用している場合、その [[DKMS]] パッケージに切り替える必要があるかもしれません。

==== ユーザー空間 ASLR の比較 ====

{{pkg|linux-hardened}} パッケージは、アドレス空間配置ランダム化の改善された実装をユーザ空間のプロセスに対して提供します。{{pkg|paxtest}} コマンドを使うことで、提供されるエントロピーの推定値を得ることができます:

===== 64 ビットプロセス =====

{{hc|linux-hardened 5.4.21.a-1-hardened|
Anonymous mapping randomization test : 32 quality bits (guessed)
Heap randomization test (ET_EXEC) : 40 quality bits (guessed)
Heap randomization test (PIE) : 40 quality bits (guessed)
Main executable randomization (ET_EXEC) : 32 quality bits (guessed)
Main executable randomization (PIE) : 32 quality bits (guessed)
Shared library randomization test : 32 quality bits (guessed)
VDSO randomization test : 32 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)
Randomization under memory exhaustion @~0: 32 bits (guessed)
Randomization under memory exhaustion @0 : 32 bits (guessed)
}}

{{hc|linux 5.5.5-arch1-1|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 20 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 29 bits (guessed)
Randomization under memory exhaustion @0 : 29 bits (guessed)
}}

{{hc|linux-lts 4.19.101-1-lts|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 19 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 28 bits (guessed)
Randomization under memory exhaustion @0 : 28 bits (guessed)
}}

===== 32 ビットプロセス (x86_64 カーネル上) =====

{{hc|linux-hardened|
Anonymous mapping randomization test : 16 quality bits (guessed)
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)
Heap randomization test (PIE) : 27 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 18 quality bits (guessed)
Shared library randomization test : 16 quality bits (guessed)
VDSO randomization test : 16 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)
Randomization under memory exhaustion @~0: 18 bits (guessed)
Randomization under memory exhaustion @0 : 18 bits (guessed)
}}

{{hc|linux|
Anonymous mapping randomization test : 8 quality bits (guessed)
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)
Heap randomization test (PIE) : 13 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 8 quality bits (guessed)
Shared library randomization test : 8 quality bits (guessed)
VDSO randomization test : 8 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)
Randomization under memory exhaustion @~0: No randomization
Randomization under memory exhaustion @0 : No randomization
}}

=== proc ファイルシステム内のカーネルポインタへのアクセスを制限する ===

{{ic|kernel.kptr_restrict}} を 1 に設定すると、{{ic|CAP_SYSLOG}} を持たない通常ユーザから {{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが秘匿され、カーネルのエクスプロイトで動的にアドレス/シンボルを解決することが困難になります。これは、事前にコンパイルされた Arch Linux カーネルではあまり意味がありません。周到な攻撃者はカーネルパッケージをダウンロードして、そこから手動でシンボルを取得することができるからです。しかしながら、自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし、一部の {{Pkg|perf}} コマンドの機能が、root 以外のユーザによって使用されば場合に破壊されます (しかし、いずれにせよ多くの {{Pkg|perf}} コマンドは root アクセスを必要とします)。詳細は {{Bug|34323}} を参照してください。

{{ic|kernel.kptr_restrict}} を 2 に設定すると、{{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが権限に依らず隠されます。

{{hc|/etc/sysctl.d/51-kptr-restrict.conf|2=
kernel.kptr_restrict = 1
}}

{{Note|{{pkg|linux-hardened}} はデフォルトで {{ic|0}} ではなく {{ic|1=kptr_restrict=2}} を設定します。}}

=== BPF の堅牢化 ===

BPF は、実行時にカーネル内のバイトコードを動的にロードして実行するために使用されるシステムです。ネットワーク (XDP, tc など)、トレース (kprobes, uprobes, tracepoints など)、セキュリティ (seccomp など) など、多くの Linux カーネルサブシステムで使用されています。また、高度なネットワークセキュリティ、パフォーマンスプロファイリング、ダイナミックトレースにも有効です。

BPF はもともと [[Wikipedia:ja:Berkeley Packet Filter|Berkeley Packet Filter]] の頭文字をとったもので、オリジナルの古典的な BPF は BSD 用のパケットキャプチャツールに使われていたためです。これは最終的に拡張 BPF (eBPF) に発展し、その後まもなくただの BPF (頭字語ではありません) に改名されました。BPFはパケットフィルタリングツールの実装に使われることがありますが、 iptables や netfilter のようなパケットフィルタリングツールと混同しないでください。

BPF のコードは解釈されるか、[[Wikipedia:ja:実行時コンパイラ|Just-In-Time (JIT) コンパイラ]]を使ってコンパイルされるかのどちらかです。Arch のカーネルは {{ic|CONFIG_BPF_JIT_ALWAYS_ON}} でビルドされており、BPF インタープリタを無効にして全ての BPF を JIT コンパイラでコンパイルするよう強制しています。これにより、攻撃者が BPF を使って SPECTRE 型の脆弱性を悪用した特権昇格攻撃をすることが難しくなります。詳しくは、[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290af86629b25ffd1ed6232c4e9107da031705cb CONFIG_BPF_JIT_ALWAYS_ON を導入したカーネルパッチ]を参照してください。

カーネルは JIT コンパイルされた BPF に対して、パフォーマンスと多くの BPF プログラムをトレース・デバッグする能力を犠牲にして、ある種の JIT スプレー攻撃を軽減するための堅牢化機能を備えています。この機能は、{{ic|net.core.bpf_jit_harden}} を {{ic|1}} (非特権コードの堅牢化を有効化する) か {{ic|2}} (全てのコードの堅牢化を有効化する) に設定することで有効化できます。

詳しくは、[https://docs.kernel.org/admin-guide/sysctl/net.html カーネルドキュメント] の {{ic|net.core.bpf_*}} 設定を参照してください。

{{Tip|
* {{Pkg|linux-hardened}} では、デフォルトで {{ic|1=net.core.bpf_jit_harden=2}} が設定されており、{{ic|0}} ではありません。
* デフォルトでは、BPF プログラムは非特権ユーザでも実行可能です。この挙動を変更するには {{ic|1=kernel.unprivileged_bpf_disabled=1}} を設定してください [https://access.redhat.com/security/cve/cve-2021-33624]。
}}

=== ptrace スコープ ===

{{man|2|ptrace}} システムコールは、あるプロセス ("tracer") が他のプロセス ("tracee") の実行を監視、制御し、tracee のメモリとレジスタを検査、変更するための手段を提供します。通常、{{ic|ptrace}} は ''gdb'' や ''strace''、''perf''、''reptyr'' などのデバッグツールによって使用されます。しかし、他のプロセスからデータを読んだり、他のプロセスの制御を奪ったりする手段を悪意のあるプロセスにも提供してしまいます。

Arch では、{{ic|kernel.yama.ptrace_scope}} [[カーネルパラメータ]]を提供する [https://docs.kernel.org/admin-guide/LSM/Yama.html Yama LSM] がデフォルトで有効化されています。このパラメータはデフォルトで {{ic|1}} (制限) に設定されており、{{ic|CAP_SYS_PTRACE}} [[ケイパビリティ]]も特権も持たない tracer が制限されたスコープ外で {{ic|ptrace}} コールを実行できないようにしています。これは、古典的なパーミッションと比べてセキュリティ上大きな改善です。このモジュールが無いと、同じユーザとして実行されているプロセスを隔てるものがなくなってしまいます ({{man|7|pid_namespaces}} などの他のセキュリティレイヤーがない場合)。

{{Note|デフォルトでは、[[sudo]] を使うなどして、{{ic|ptrace}} を必要とするツールを特権プロセスとして実行することができます。}}

デバッグツールを使う必要がない場合は、システムを堅牢化するために {{ic|kernel.yama.ptrace_scope}} を {{ic|2}} (管理者限定) や {{ic|3}} ({{ic|ptrace}} を禁止) に設定することを検討してください。

=== hidepid ===

{{Warning|
* これは、サンドボックスと [[Xorg]] 内で実行するアプリケーションなど、特定のアプリケーションで問題を発生させる場合があります (回避策を見てください)。
* {{Pkg|systemd}} > 237.64-1 を使用している場合、これは [[D-Bus]]、[[Polkit]]、[[PulseAudio]]、そして [[bluetooth]] で問題を発生させます。
}}

カーネルには、{{ic|proc}} ファイルシステムを {{ic|1=hidepid=}} オプションと {{ic|1=gid=}} オプションを使ってマウントすることで、他のユーザのプロセス (通常、{{ic|/proc}} でアクセス可能) を非特権ユーザから秘匿する機能があります。これらのマウントオプションは https://docs.kernel.org/filesystems/proc.html でドキュメント化されています。

これにより、侵入者が動作中のプロセスの情報 (特権で動作しているデーモンがあるか、他のユーザが機密情報を扱うプログラムを実行しているか、他のユーザがプログラムを実行しているか) を得る作業を複雑化し、ユーザが特定のプログラムを実行しているかどうかを知るのを不可能にし (ただし、そのプログラムがそれ自体の挙動で存在を他者に知られることがないとする)、さらに、貧弱に書かれたプログラムが機密情報をプログラム引数を介して渡したとしてもローカルの盗聴者から守られます。

{{ic|proc}} [[ユーザーとグループ#システムグループ#グループ]] ({{Pkg|filesystem}} パッケージによって提供されています) は、他のユーザのプロセス情報を得ることのできるユーザのホワイトリストとして機能します。ユーザやサービスが自身以外の {{ic|/proc/<pid>}} ディレクトリにアクセスする必要がある場合、そのユーザまたはサービスを[[ユーザーとグループ#グループ管理|proc グループに追加してください]]。

例えば、プロセスの情報を {{ic|proc}} グループに属さない他のユーザから隠すには:

{{hc|/etc/fstab|2=
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
}}

ユーザのセッションを正しく動作させるために、''systemd-logind'' を例外として追加する必要があります:

{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=
[Service]
SupplementaryGroups=proc
}}

=== モジュールのロードを制限する ===

デフォルトの Arch カーネルは {{ic|CONFIG_MODULE_SIG_ALL}} が有効で、{{Pkg|linux}} パッケージの一部としてビルドされた全てのカーネルモジュールに署名します。これにより、カーネルは有効なキーで署名されたモジュールだけをロードするように制限できます。実際、これはローカルでコンパイルされた、もしくは {{Pkg|virtualbox-host-modules-arch}} などのパッケージによって提供された、ツリー外のモジュールは全てロードできないことを意味します。

カーネルモジュールの読み込みは {{ic|1=module.sig_enforce=1}} [[カーネルパラメータ]]を設定することで制限することができます。詳細は[https://docs.kernel.org/admin-guide/module-signing.html カーネルドキュメント]で見られます。

=== kexec を無効にする ===

Kexec は、現在実行中のカーネルを置き換えることを可能にします。

{{hc|/etc/sysctl.d/51-kexec-restrict.conf|2=
kernel.kexec_load_disabled = 1
}}

{{Tip|kexec は {{pkg|linux-hardened}} でデフォルトで無効になっています。}}

=== カーネルロックダウンモード ===

Linux 5.4 から、オプションの[https://mjg59.dreamwidth.org/55105.html ロックダウン機能]がカーネルに[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d 追加されました]。これは、UID 0 (root) とカーネルの間の境界を強化することを目的としています。この機能を有効にすると、ハードウェアやカーネルへの低レベルなアクセスに依存している一部のアプリケーションは動作しなくなる可能性があります。

ロックダウンを使用するには、LSM が初期化され、ロックダウンモードが設定されている必要があります。

[[カーネル#公式サポートカーネル|公式にサポートされているカーネル]]は全て LSM を初期化しますが、ロックダウンモードを強制しません。

{{Tip|有効化されている LSM は {{ic|cat /sys/kernel/security/lsm}} を実行することで確認することができます。}}

ロックダウンには2つの動作モードがあります:

* {{ic|integrity}}: ユーザーランドが実行中のカーネルを変更できるカーネル機能 (kexec、bpf) は無効化されます。
* {{ic|confidentiality}}: ユーザーランドがカーネルから機密情報を抽出するためのカーネルの機能も無効化されます。

特定の脅威モデルで指示がない限り、{{ic|integrity}} を使用することが推奨されます。

実行時にカーネルのロックダウンを有効にするには、以下を実行してください:

# echo ''mode'' > /sys/kernel/security/lockdown

起動時にカーネルのロックダウンを有効にするには、{{ic|1=lockdown=''mode''}} [[カーネルパラメータ]]を使用してください:

{{Note|
* カーネルロックダウンを実行時に無効化することはできません。
* カーネルロックダウンは、[[ハイバネート]]を無効化します。
}}

{{man|7|kernel_lockdown}} も参照してください。

=== Linux Kernel Runtime Guard (LKRG) ===

[https://www.openwall.com/lkrg/ LKRG] ({{AUR|lkrg-dkms}}) は、カーネルの整合性チェックとエクスプロイト行為の検出を行うカーネルモジュールです。

== アプリケーションのサンドボックス化 ==

こちらも参照 [[Wikipedia:ja:サンドボックス (セキュリティ)]]

{{Note|ユーザー名前空間の設定項目 {{ic|CONFIG_USER_NS}} は、現在 {{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}}、および {{Pkg|linux-hardened}} で有効になっています。これが無効だと、一部のアプリケーションで特定のサンドボックス機能が利用できなくなる可能性があります。}}

{{Warning|非特権ユーザー名前空間の使用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) は、{{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}} でデフォルトで有効になっています。これにより、ローカル特権昇格の攻撃対象が大幅に拡大します([https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction AppArmorのWiki] および {{Bug|36969}} を参照。}}

これを軽減するためには、次のいずれかを行ってください:

* 安全なデフォルトを持つ {{Pkg|linux-hardened}} カーネルを使用する、または
* {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] を {{ic|0}} に設定する。

これにより、[[Zoom Meetings|Zoom]] や {{pkg|nsjail}} などのアプリケーションが動作しなくなる場合があることに注意してください。また、システムに {{pkg|bubblewrap}} がインストールされている場合は、{{pkg|bubblewrap-suid}} に置き換える必要があります。詳細は [[Bubblewrap#インストール]] を参照してください。

=== Firejail ===

[[Firejail]] は、アプリケーションやサーバーをサンドボックス化するための使いやすいツールです。元々はブラウザやインターネット向けアプリケーションのために作成されましたが、現在では多くのアプリケーションに対応しています。さまざまな機能を備えたサンドボックス環境を構築するために、suid バイナリとしてインストールされ、ブラックリストとホワイトリストに基づいてターゲットアプリケーションのサンドボックス化された実行環境を構築します。

=== bubblewrap ===

[[bubblewrap]] は、[[Flatpak]] などの非特権コンテナツール向けに開発されたサンドボックスアプリケーションで、Firejail よりもリソース消費と複雑さが大幅に小さいです。ファイルパスのホワイトリスト機能は欠けていますが、bubblewrap はバインドマウントのほか、ユーザー/IPC/PID/ ネットワーク /cgroup 名前空間の作成をサポートしており、シンプルなものから複雑なサンドボックスまで対応可能です。

[[Bubblejail]] サンドボックスは [[bubblewrap]] を基にしており、リソース指向の権限モデルと、権限を調整するためのグラフィカルインターフェースを提供します。

=== chroot ===

手動で [[chroot]] してサンドボックス化されたプロセス環境を作成できます。しかし、これは他のサンドボックス技術に比べて非常に制限されています。そのサンドボックス化の範囲はファイルパスの隔離に限られています。

=== Linux Containers ===

[[Linux Containers]] は、他のオプション([[#完全な仮想化オプション|完全な仮想化オプション]] を除く) よりも多くの隔離が必要な場合に適した選択肢です。LXC は、既存のカーネルの上で擬似 chroot 内で実行され、独自の仮想ハードウェアを持っています。

=== 完全な仮想化オプション ===

[[VirtualBox]]、[[KVM]]、[[Xen]]、または [https://www.qubes-os.org/ Qubes OS](Xen ベース)などの完全仮想化オプションを使用することで、リスクの高いアプリケーションを実行したり、危険なウェブサイトを閲覧したりする場合に、隔離とセキュリティを強化することができます。

==ネットワークとファイアウォール==

===ファイアウォール===

標準の Arch カーネルは [[Wikipedia:Netfilter|Netfilter]] の [[iptables]] および [[nftables]] を使用できますが、これらのサービスはデフォルトで [[有効化]] されていません。システム上で実行されているサービスを保護するために、何らかの形のファイアウォールを設定することを強く推奨します。多くのリソース(ArchWiki など)では、どのサービスを保護するべきかが明示的に記載されていないため、ファイアウォールを有効にすることは良い予防措置となります。

* 一般的な情報については [[iptables]] および [[nftables]] を参照してください。
* iptables ファイアウォールの設定方法については [[シンプルなステートフルファイアウォール]] を参照してください。
* netfilter の設定方法については [[ファイアウォール]] を参照してください。
* Bluetack などの IP アドレスリストをブロックするには [[Ipset]] を参照してください。
* {{Pkg|opensnitch}} は、アプリケーション、ポート、ホストなどによる設定可能なルールをサポートする、構成可能なインバウンドおよびアウトバウンドファイアウォールです。

==== ポートを開く ====

一部のサービスは、開かれたネットワークポートでインバウンドトラフィックを待ち受けます。これらのサービスは、必要最低限のアドレスとインターフェースにのみバインドすることが重要です。リモート攻撃者が [https://samy.pl/slipstream/ ネットワークプロトコルの欠陥を悪用して公開されたサービスにアクセスする] 可能性があります。これは、[https://nvd.nist.gov/vuln/detail/CVE-2019-13450 localhost にバインドされたプロセス] にも発生することがあります。

一般的に、サービスがローカルシステムのみでアクセス可能であれば、非ループバックアドレス(例えば {{ic|0.0.0.0/0}})ではなく、Unix ドメインソケット({{man|7|unix}})や {{ic|localhost}} のようなループバックアドレスにバインドするべきです。

サービスがネットワーク越しに他のシステムからアクセス可能である必要がある場合、厳格な [[ファイアウォール]] ルールでアクセスを制御し、可能な限り認証、認可、暗号化を構成することが重要です。

現在のすべてのオープンポートをリストするには、{{ic|ss -l}} を使用できます。すべてのリスニング中のプロセスとその数値的な TCP および UDP ポート番号を表示するには:

# ss -lpntu

その他のオプションについては、{{man|8|ss}}を参照してください。

===カーネルパラメータ===
ネットワークに影響を与えるカーネルパラメータは [[sysctl]] を使って設定できます。設定方法は [[sysctl#TCP/IP スタックの防御]] を見て下さい。

===SSH===
[[SSH 鍵#パスワードログインの無効化|SSH 鍵を必要]]としない [[Secure Shell]] を使うのは避けましょう。これは[[Wikipedia:ja:総当たり攻撃|総当たり攻撃]]を防ぎます。また、[[Fail2ban]] や [[Sshguard]] はログを監視して [[iptables|iptables ルール]]を書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。

二段階認証によって認証を強化することができます。[[Google Authenticator]] はワンタイムパスコード (OTP) を使用する二段階認証方式を提供します。

[[Secure Shell#root ログインを拒否する|root ログインを拒否する]]のは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。

===DNS===

[[DNSSEC]] や [[DNSCrypt]] を見て下さい。

=== プロキシ ===

プロキシはアプリケーションとネットワークの間に挟まる追加レイヤーとして使われ、信頼できないソースからのデータをサニタイズします。少ない権限でプロキシを動作させることで、エンドユーザー権限で複雑なアプリケーションを実行するよりも攻撃対象を小さくすることができます。

例えば {{Pkg|glibc}} の中に実装されている DNS リゾルバを考えてみてください。(root で実行することもある) アプリケーションにリンクされている DNS リゾルバにバグが存在した場合、リモートコード実行につながる危険があります。[[dnsmasq]] などの DNS キャッシュサーバーをインストールしてプロキシとして使うことで問題を防ぐことが可能です [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]。

=== SSL 証明書の管理 ===

サーバーサイドの SSL 証明書の管理については [[OpenSSL]] や [[Network Security Services]] (NSS) を参照してください。また、関連する [[Let’s Encrypt]] プロジェクトも見てください。

デフォルトのインターネット SSL 証明書のトラストチェーンは {{Pkg|ca-certificates}} パッケージによって提供されています。Arch はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: {{AUR|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) に依存しています。

デフォルトの証明書を変えたいと思うことがあるかもしれません。例えば、[http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ ニュース] を読んで証明書を信頼しないようにしたい場合 (ソースのプロバイダーによって無効になるのを待てない場合)、Arch のインフラを使うことで簡単に設定できます:
# {{ic|.crt}} 形式の証明書を入手してください (例: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; 既存のルート認証局の場合、システム内にあるはずです)。
# {{ic|/etc/ca-certificates/trust-source/blacklist/}} にコピーしてください。
# root で ''update-ca-trust'' を実行してください。

お好きなブラウザを開いて'''信頼できない'''サイトとして表示されれば、ブラックリストが上手く機能しています。

== 物理セキュリティ ==

{{Note|リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。}}

十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで''実用的で''高いレベルのセキュリティを得ることができます。

攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [http://www.breaknenter.org/projects/inception/]。これを防ぐためにできることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識がなく実行されることはほとんどありません。

[[#ディスク暗号化|ディスク暗号化]]はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。

===BIOS をロックダウンする===

BIOS にパスワードを追加することによってリムーバブルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。

=== ブートローダー ===

[[Arch ブートプロセス#ブートローダー|ブートローダー]] を保護することは非常に重要です。保護されていないブートローダは、例えば {{ic|1=init=/bin/sh}} を設定することでログインの制限を回避することができます。[[カーネルパラメータ]] でシェルに直接ブートするようにします。

==== Syslinux ====

Syslinux は[[Syslinux#セキュリティ|ブートローダーのパスワード保護]]をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。

==== GRUB ====

[[GRUB]] はブートローダのパスワードもサポートしています。詳しくは [[GRUB/ヒントとテクニック#GRUB メニューのパスワード保護|GRUB メニューのパスワード保護]] を参照してください。[[GRUB/ヒントとテクニック# GRUB メニューのパスワード保護|暗号化 /boot]] もサポートしていますが、これはブートローダコードの一部だけを暗号化しないままにしています。GRUB の設定、[[カーネル]]、[[initramfs]] は暗号化されています。

==== systemd-boot ====

[[systemd-boot]] は [[#セキュアブート]] が有効な場合、カーネルパラメータの編集を無効にします。代わりの方法として、[[systemd-boot#パスワードで保護されたカーネルパラメータエディタ]] を参照して下さい、より伝統的なパスワードベースのオプションを使用できます。

=== セキュアブート ===

[[セキュアブート]] は [[UEFI]] の機能で、コンピュータが起動するファイルの認証を可能にするものです。これは、起動パーティション内のファイルを置き換えるような、いくつかの [https://ja.wikipedia.org/wiki/%E6%82%AA%E6%84%8F%E3%81%82%E3%82%8B%E3%83%A1%E3%82%A4%E3%83%89%E6%94%BB%E6%92%83 悪意あるメイド攻撃] を防止するのに役立つ。通常、コンピュータにはベンダー (OEM) によって登録されたキーが付属しています。しかし、これを取り外して、コンピュータを「セットアップモード」にし、ユーザーが自分のキーを登録・管理できるようにすることができます。

セキュアブートのページでは、[https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Implementing_Secure_Boot using your own keys] によってセキュアブートを設定する方法を案内しています。

=== トラステッドプラットフォームモジュール(TPM) ===

[[Trusted Platform Module|TPM]] は、暗号鍵が埋め込まれたハードウェア・マイクロプロセッサです。これは、最近のほとんどのコンピュータの基本的な信頼性の根源を形成し、ブートチェーンのエンドツーエンドの検証を可能にします。内部スマートカードとして使用したり、コンピュータ上で動作するファームウェアを証明したり、改ざん防止とブルートフォース耐性のあるストアにユーザーがシークレットに挿入することができます。

=== リムーバブルフラッシュドライブ上のブートパーティション ===

ブートパーティションをフラッシュドライブに置き、それがないとシステムが起動しないようにする、というのはよくあるアイデアです。このアイデアの支持者はしばしば [[セキュリティ#ディスク暗号化|ディスク暗号化]] を併用し、ブートパーティションに置かれた [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USBdetached encryption headers] を使っている人もいます。

この方法は [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USB encrypting /boot] と統合することも可能です。

=== 自動ログアウト ===
[[Bash]] または [[Zsh]] を使っている場合、{{ic|TMOUT}} によってタイムアウトによるシェルからの自動ログアウトを設定できます。

例えば、以下は仮想コンソールから自動でログアウトします (X11 のターミナルエミュレータからはログアウトしません):

{{hc|/etc/profile.d/shell-timeout.sh|<nowiki>
TMOUT="$(( 60*10 ))";
[ -z "$DISPLAY" ] && export TMOUT;
case $( /usr/bin/tty ) in
/dev/tty[0-9]*) export TMOUT;;
esac
</nowiki>}}

(X のコンソールも含めて) 全ての Bash/Zsh プロンプトでタイムアウトさせたい場合は、次を使って下さい:

$ export TMOUT="$(( 60*10 ))";

シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや {{ic|TMOUT}} をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。

=== 不正なUSBデバイスから保護する ===

[[Usbguard]] は、デバイスの属性に基づく基本的なホワイトリストおよびブラックリスト機能を実装することで、不正な USB デバイス (別名 [https://ja.wikipedia.org/wiki/BadUSB BadUSB], [https://github.com/samyk/poisontap PoisonTap] または [https://lanturtle.com/ LanTurtle]) からコンピューターを保護できるソフトウェアフレームワークです。

=== 揮発性データの収集 ===

電源が入っているコンピュータは、[https://fedvte.usalearning.gov/courses/CSI/course/videos/pdf/CSI_D01_S05_T01_STEP.pdf volatile data collection] に対して脆弱である可能性があります。コンピュータの電源を入れる必要がない時や、コンピュータの物理的な安全性が一時的に損なわれる場合(例:セキュリティチェックポイントを通過する時)には、コンピュータの電源を完全に切ることがベストプラクティスです。

== パッケージ ==

=== パッケージの認証 ===
パッケージの署名が適正に使われていないと [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview パッケージマネージャへの攻撃] が考えられ、さらに [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html 適切な署名システム] を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは [[Pacman-key]] を見て下さい。

=== アップグレード ===

定期的に [[システムメンテナンス#システムのアップグレード|システムのアップグレード]] を行うことが重要です。

=== 脆弱性アラートの確認 ===

National Vulnerability Database が提供する Common Vulnerabilities and Exposure (CVE) Security Alert の更新を購読し、[https://nvd.nist.gov/download.cfm NVD Download webpage] で見つけてください。[https://security.archlinux.org/ Arch Linux Security Tracker] は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットを表形式でまとめた、特に有用なリソースです。ツール {{Pkg|arch-audit}} は実行中のシステムに影響を与える脆弱性をチェックするために使われます。グラフィカルなシステムトレイである {{Pkg|arch-audit-gtk}} も使うことができます。[https://wiki.archlinux.org/title/Arch_Security_Team Arch Security Team]も参照してください。

特にメインレポジトリや AUR 以外の手段でソフトウェアをインストールしている場合は、あなたが使っているソフトウェアのリリース通知を購読することも検討すべきです。いくつかのソフトウェアには、セキュリティに関する通知を受け取るために購読できるメーリングリストがあります。ソースコードホスティングサイトはしばしば新しいリリースの RSS フィードを提供しています。

=== パッケージの再ビルド ===

攻撃対象領域を減らす手段として、パッケージをリビルドし、不要な関数や機能を削除することができます。例えば、{{Pkg|bzip2}} は [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189] を回避するために {{ic|bzip2recover}} を使わずにリビルドすることが可能です。カスタムハードニングフラグは、手動またはラッパーを介して適用することもできます。

{| class="wikitable"
! フラグ !! 目的
|-
| -D_FORTIFY_SOURCE=2 || ランタイムバッファオーバーフローの検出
|-
| -D_GLIBCXX_ASSERTIONS || C++ の文字列とコンテナのランタイム境界チェック
|-
| -fasynchronous-unwind-tables || バックトレースの信頼性向上
|-
| -fexceptions || テーブルベースのスレッドキャンセルを有効にする
|-
| -fpie -Wl,-pie || 実行可能ファイルに対する完全な ASLR
|-
| -fpic -shared || 共有ライブラリのテキスト再配置を行わない
|-
| -fplugin=annobin || ハードニング品質管理用データの作成
|-
| -fstack-clash-protection || スタックオーバーフロー検出の信頼性向上
|-
| -fstack-protector or -fstack-protector-all || スタックスマッシュプロテクター
|-
| -fstack-protector-strong || 同様に
|-
| -g || デバッグ情報を生成する
|-
| -grecord-gcc-switches || デバッグ情報にコンパイラのフラグを格納する
|-
| -mcet -fcf-protection || 制御フローの完全性保護
|-
| -O2 || 推奨される最適化
|-
| -pipe || 一時ファイルを回避し、ビルドを高速化します。
|-
| -Wall || 推奨されるコンパイラの警告
|-
| -Werror=format-security || 安全でない可能性のあるフォーマット文字列の引数を拒否する
|-
| -Werror=implicit-function-declaration || 関数プロトタイプの欠落を却下する
|-
| -Wl,-z,defs || アンダーリンクの検出と拒否
|-
| -Wl,-z,now || 遅延バインディングを無効にする
|-
| -Wl,-z,relro || 移設後の読み出し専用セグメント
|}

* [https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/ Flags and info ソース]

== 参照 ==

* [https://security.archlinux.org/ Arch Linux セキュリティトラッカー]
* ArchWiki のセキュリティアプリケーションのリスト: [[アプリケーション一覧/セキュリティ]]
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux ワークステーションのセキュリティチェックリスト]
* [https://www.privacytools.io/ privacytools.io Privacy Resources]
* [https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/index.html Red Hat Enterprise Linux 7 セキュリティガイド]
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Debian 安全化マニュアル (PDF)]
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]

Booster

2025-04-09T07:30:08Z

Oech3: テンプレートの修正/* モジュールをstripする */

[[Category:initramfs]]
[[Category:カーネル]]
[[en:Booster]]
{{Related articles start}}
{{Related|カーネルモジュール}}
{{Related|Initramfs の最小化}}
{{Related|ブートデバッグ}}
{{Related|Mkinitcpio}}
{{Related|dracut}}
{{Related|Clevis}}
{{Related articles end}}

[https://github.com/anatol/booster Booster] は高速な [[initramfs]] ジェネレータで、[[mkinitcpio]] や [[dracut]] と似ています。
Booster は [https://michael.stapelberg.ch/posts/2020-01-21-initramfs-from-scratch-golang/ distri プロジェクト] に着想を得ており、小型で高速な init イメージを生成することを目指しています。

Booster は、initramfs イメージの生成を担当する {{ic|/usr/bin/booster}} ユーザー空間ツールを提供します。生成されたイメージは、デフォルトでは {{ic|/boot/}} にあります。

== インストール ==

{{AUR|booster-git}} パッケージを[[インストール]]してください。パッケージのインストールフックによって initramfs イメージが生成されます (インストールされているカーネル (例: {{Pkg|linux}}, {{Pkg|linux-lts}}) ごとにひとつずつ)。イメージは {{ic|/boot}} ディレクトリに配置されます:

{{hc|$ ls -lh /boot/booster*|
-rwxr-xr-x 1 root root 4.0M Dec 16 16:20 /boot/booster-linux.img
}}

また、イメージは手動で生成することもできます:

$ booster -output mybooster.img

== 設定 ==

Booster ジェネレータの設定は {{ic|/etc/booster.yaml}} にあります。設定ファイルがない場合は、デフォルトの設定(ホスト固有の画像、ネットワークなし)が使用されます。

設定ファイルを使用することで、デフォルトの動作を上書きすることができます。詳しくは {{man|1|booster|CONFIG FILE}} を参照してください。

=== モジュールの早期ロード ===

いくつかのカーネルモジュールは、initramfs の段階で早期にロードされる必要がある場合があります。

例えば、{{ic|nvidia}} モジュールをロードする必要がある場合、以下の設定を使用します:

{{hc|/etc/booster.yaml|
modules_force_load: nvidia
}}

そして、[[Booster#booster イメージの再生成|booster イメージの再生成]] を実行します。

=== 暗号化 ===

Booster は、[[Clevis]] のような [[LUKS]] ベースのフルディスク暗号化をすぐに使用できるようにサポートしています。ジェネレーターには追加の設定は必要ありません。ただし、initramfs の場合は、ルートが存在する LUKS パーティションに関する情報を追加する必要があります。これは、{{ic|1=rd.luks.uuid=''LUKSUUID''}} または {{ic|1=rd.luks.name=''LUKSUUID''=''LUKSNAME''}} [[カーネルパラメータ]] のいずれかを使用して行われます。{{ic|''LUKSUUID''}} は、Booster によってロックを解除する必要があり、暗号化された LUKS パーティションの [[UUID]] を指定します。{{man|1|booster|UUID パラメータ}} マニュアルでは、UUID に引用符を含めないことを推奨しています。{{ic|''LUKSNAME''}} は、ロック解除されたパーティションの名前を指定します ({{ic|/dev/mapper/''LUKSNAME''}} のように) 関連オプションについては、{{man|1|booster|BOOT TIME KERNEL PARAMETERS}} を参照してください。

イメージの再構築は必要ありません。ブートローダーの設定が完了したら、コンピューターを再起動します。その後、起動時に暗号化されたルートパーティションのパスワードを求める {{ic|Enter passphrase for ''YOURROOT'':}} プロンプトが表示されます。

==== systemd スタイルのバインディング ====

Booster はパーティションもサポートします [https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html bound with systemd] {{ic|systemd-fido2}} や {{ic|systemd-tpm2}} など。

'systemd-fido2' を使用する場合は、{{Pkg|libfido2}} パッケージをインストールし、次の設定を使用してイメージに fido2-assert を追加してください。

{{hc|/etc/booster.yaml|
extra_files: fido2-assert
}}

[[#booster イメージの再生成|booster イメージの再生成します]] Booster は起動中にこの設定を検出し、現在の YubiKey を使用してドライブのロックを解除します。

{{Note|コミット 1b65577 より前に、Booster が FIDO2 キーを使用して暗号化されたパーティションのロックを解除するのに十分な早さで必要なカーネルモジュールの一部をロードできない可能性があることが報告されています。この場合、強制的にロードされる以下のモジュールを追加します。}}

{{hc|/etc/booster.yaml|
modules_force_load: '''usbhid''','''hid_sensor_hub'''
extra_files: fido2-assert
}}

=== booster イメージの再生成 ===

Booster の設定が完了したら、{{ic|/boot}} にある Booster images を更新する必要があります。イメージは、{{ic|booster build booster-foo.img}} を使用して手動で生成するか、インストールされているすべてのカーネルを反復処理してカーネルごとに Booster イメージを生成する便利なスクリプト {{ic|/usr/lib/booster/regenerate_images}} もあります。

=== モジュールを除外する ===

{{ic|-}}によってモジュールをinitramfsから除外できます。

起動時間を短縮するために、[[Mkinitcpio/Initramfs_%E3%81%AE%E6%9C%80%E5%B0%8F%E5%8C%96]] のように手動で全てのモジュールを選ぶ例として、
{{hc|/etc/booster.yaml|
modules: -*,btrfs,nvme
}}

=== モジュールをstripする ===

モジュールをstripする事でinitramfsのサイズを減らせます。
{{hc|/etc/booster.yaml|
strip: true
}}

{{Warning|この設定は[[セキュリティ#カーネルロックダウンモード]]に必要なモジュールの署名を消します。}}

== ブートローダーの設定 ==

イメージを生成したら、次に[[Arch_ブートプロセス#ブートローダー|ブートローダー]]を設定します。

=== マイクロコードの更新 ===

[[mkinitcpio]] や [[dracut]] と異なり、Booster [https://github.com/anatol/booster/issues/40 は] 生成されたイメージにマイクロコードの更新を含めることをサポートしていません。
詳細については [[マイクロコード#別個のマイクロコード initramfs ファイルを使う]] を参照し、適切なマイクロコードイメージを追加で読み込むようにブートローダーを設定する方法を確認してください。

=== rEFInd ===

すでに [[rEFInd# rEFInd によってカーネルが自動で検出される場合|自動検出]] に依存した設定になっている場合、追加の設定変更は必要ありません。[[rEFInd]] は [https://sourceforge.net/p/refind/code/ci/778878f7f30f68b7fa0282074e5dd8fc5894a212/ initrd files named booster*] をサポートしています。

initramfs のパスを [[rEFInd#refind_linux.conf|refind.conf]] や [[rEFInd#手動でブートエントリを記述する|手動でブートエントリを記述する]] する場合、正しいファイル名を使っているか確認してください。例えば {{ic|'''booster''-linux.img}} の代わりに {{ic|'''initramfs''-linux.img}} とします。

=== systemd-boot ===

新しい initramfs イメージを [[systemd-boot]] で使うには以下のようにブートローダーエントリを作成します:

{{hc|/boot/loader/entries/booster.conf|2=
title Arch Linux with booster
linux /vmlinuz-linux
initrd /intel-ucode.img
initrd /booster-linux.img
options root=UUID=08f83949-bcbb-47bb-bc17-089aaa59e17e rw
}}

上記でルートファイルシステムは {{ic|1=UUID=08f83949-bcbb-47bb-bc17-089aaa59e17e}} と指定しています。{{ic|blkid /dev/''ROOTDEVICE''}} を実行して、あなたのデバイスの UUID を確認してください。

== トラブルシューティング ==

=== デバッグ ===

Booster が上手く動かない場合、デバッグ出力を有効にすることで何が起こっているか情報を得ることができます:

* ジェネレータのデバッグは {{ic|-debug}} コマンドラインフラグを使ってください: {{ic|booster -debug}}
* init のデバッグは {{ic|1=booster.debug=1}} [[カーネルパラメータ]] が存在します。

Booster 自体に問題があると思われる場合は、[https://github.com/anatol/booster/issues GitHub でチケットを作成してください]

=== Booster ジェネレータが "too many open files" エラーで失敗する ===

もし {{ic|strip}} と {{ic|universal}} を有効にしていて {{ic|/usr/lib/modules/glue_helper.ko: pipe2: too many open files}} というエラーが出た場合は、プロセスごとのオープンファイルの上限を上げる必要があります。[[limits.conf#nofile]] を参照してください。

== 参照 ==

* [https://github.com/anatol/booster/blob/develop/README.md upstream README]

Booster

2025-04-09T07:29:44Z

Oech3: 同期/* モジュールをstripする */

[[Category:initramfs]]
[[Category:カーネル]]
[[en:Booster]]
{{Related articles start}}
{{Related|カーネルモジュール}}
{{Related|Initramfs の最小化}}
{{Related|ブートデバッグ}}
{{Related|Mkinitcpio}}
{{Related|dracut}}
{{Related|Clevis}}
{{Related articles end}}

[https://github.com/anatol/booster Booster] は高速な [[initramfs]] ジェネレータで、[[mkinitcpio]] や [[dracut]] と似ています。
Booster は [https://michael.stapelberg.ch/posts/2020-01-21-initramfs-from-scratch-golang/ distri プロジェクト] に着想を得ており、小型で高速な init イメージを生成することを目指しています。

Booster は、initramfs イメージの生成を担当する {{ic|/usr/bin/booster}} ユーザー空間ツールを提供します。生成されたイメージは、デフォルトでは {{ic|/boot/}} にあります。

== インストール ==

{{AUR|booster-git}} パッケージを[[インストール]]してください。パッケージのインストールフックによって initramfs イメージが生成されます (インストールされているカーネル (例: {{Pkg|linux}}, {{Pkg|linux-lts}}) ごとにひとつずつ)。イメージは {{ic|/boot}} ディレクトリに配置されます:

{{hc|$ ls -lh /boot/booster*|
-rwxr-xr-x 1 root root 4.0M Dec 16 16:20 /boot/booster-linux.img
}}

また、イメージは手動で生成することもできます:

$ booster -output mybooster.img

== 設定 ==

Booster ジェネレータの設定は {{ic|/etc/booster.yaml}} にあります。設定ファイルがない場合は、デフォルトの設定(ホスト固有の画像、ネットワークなし)が使用されます。

設定ファイルを使用することで、デフォルトの動作を上書きすることができます。詳しくは {{man|1|booster|CONFIG FILE}} を参照してください。

=== モジュールの早期ロード ===

いくつかのカーネルモジュールは、initramfs の段階で早期にロードされる必要がある場合があります。

例えば、{{ic|nvidia}} モジュールをロードする必要がある場合、以下の設定を使用します:

{{hc|/etc/booster.yaml|
modules_force_load: nvidia
}}

そして、[[Booster#booster イメージの再生成|booster イメージの再生成]] を実行します。

=== 暗号化 ===

Booster は、[[Clevis]] のような [[LUKS]] ベースのフルディスク暗号化をすぐに使用できるようにサポートしています。ジェネレーターには追加の設定は必要ありません。ただし、initramfs の場合は、ルートが存在する LUKS パーティションに関する情報を追加する必要があります。これは、{{ic|1=rd.luks.uuid=''LUKSUUID''}} または {{ic|1=rd.luks.name=''LUKSUUID''=''LUKSNAME''}} [[カーネルパラメータ]] のいずれかを使用して行われます。{{ic|''LUKSUUID''}} は、Booster によってロックを解除する必要があり、暗号化された LUKS パーティションの [[UUID]] を指定します。{{man|1|booster|UUID パラメータ}} マニュアルでは、UUID に引用符を含めないことを推奨しています。{{ic|''LUKSNAME''}} は、ロック解除されたパーティションの名前を指定します ({{ic|/dev/mapper/''LUKSNAME''}} のように) 関連オプションについては、{{man|1|booster|BOOT TIME KERNEL PARAMETERS}} を参照してください。

イメージの再構築は必要ありません。ブートローダーの設定が完了したら、コンピューターを再起動します。その後、起動時に暗号化されたルートパーティションのパスワードを求める {{ic|Enter passphrase for ''YOURROOT'':}} プロンプトが表示されます。

==== systemd スタイルのバインディング ====

Booster はパーティションもサポートします [https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html bound with systemd] {{ic|systemd-fido2}} や {{ic|systemd-tpm2}} など。

'systemd-fido2' を使用する場合は、{{Pkg|libfido2}} パッケージをインストールし、次の設定を使用してイメージに fido2-assert を追加してください。

{{hc|/etc/booster.yaml|
extra_files: fido2-assert
}}

[[#booster イメージの再生成|booster イメージの再生成します]] Booster は起動中にこの設定を検出し、現在の YubiKey を使用してドライブのロックを解除します。

{{Note|コミット 1b65577 より前に、Booster が FIDO2 キーを使用して暗号化されたパーティションのロックを解除するのに十分な早さで必要なカーネルモジュールの一部をロードできない可能性があることが報告されています。この場合、強制的にロードされる以下のモジュールを追加します。}}

{{hc|/etc/booster.yaml|
modules_force_load: '''usbhid''','''hid_sensor_hub'''
extra_files: fido2-assert
}}

=== booster イメージの再生成 ===

Booster の設定が完了したら、{{ic|/boot}} にある Booster images を更新する必要があります。イメージは、{{ic|booster build booster-foo.img}} を使用して手動で生成するか、インストールされているすべてのカーネルを反復処理してカーネルごとに Booster イメージを生成する便利なスクリプト {{ic|/usr/lib/booster/regenerate_images}} もあります。

=== モジュールを除外する ===

{{ic|-}}によってモジュールをinitramfsから除外できます。

起動時間を短縮するために、[[Mkinitcpio/Initramfs_%E3%81%AE%E6%9C%80%E5%B0%8F%E5%8C%96]] のように手動で全てのモジュールを選ぶ例として、
{{hc|/etc/booster.yaml|
modules: -*,btrfs,nvme
}}

=== モジュールをstripする ===

モジュールをstripする事でinitramfsのサイズを減らせます。
{{hc|/etc/booster.yaml|
strip: true
}}

{{WWarning|この設定は[[セキュリティ#カーネルロックダウンモード]]に必要なモジュールの署名を消します。}}

== ブートローダーの設定 ==

イメージを生成したら、次に[[Arch_ブートプロセス#ブートローダー|ブートローダー]]を設定します。

=== マイクロコードの更新 ===

[[mkinitcpio]] や [[dracut]] と異なり、Booster [https://github.com/anatol/booster/issues/40 は] 生成されたイメージにマイクロコードの更新を含めることをサポートしていません。
詳細については [[マイクロコード#別個のマイクロコード initramfs ファイルを使う]] を参照し、適切なマイクロコードイメージを追加で読み込むようにブートローダーを設定する方法を確認してください。

=== rEFInd ===

すでに [[rEFInd# rEFInd によってカーネルが自動で検出される場合|自動検出]] に依存した設定になっている場合、追加の設定変更は必要ありません。[[rEFInd]] は [https://sourceforge.net/p/refind/code/ci/778878f7f30f68b7fa0282074e5dd8fc5894a212/ initrd files named booster*] をサポートしています。

initramfs のパスを [[rEFInd#refind_linux.conf|refind.conf]] や [[rEFInd#手動でブートエントリを記述する|手動でブートエントリを記述する]] する場合、正しいファイル名を使っているか確認してください。例えば {{ic|'''booster''-linux.img}} の代わりに {{ic|'''initramfs''-linux.img}} とします。

=== systemd-boot ===

新しい initramfs イメージを [[systemd-boot]] で使うには以下のようにブートローダーエントリを作成します:

{{hc|/boot/loader/entries/booster.conf|2=
title Arch Linux with booster
linux /vmlinuz-linux
initrd /intel-ucode.img
initrd /booster-linux.img
options root=UUID=08f83949-bcbb-47bb-bc17-089aaa59e17e rw
}}

上記でルートファイルシステムは {{ic|1=UUID=08f83949-bcbb-47bb-bc17-089aaa59e17e}} と指定しています。{{ic|blkid /dev/''ROOTDEVICE''}} を実行して、あなたのデバイスの UUID を確認してください。

== トラブルシューティング ==

=== デバッグ ===

Booster が上手く動かない場合、デバッグ出力を有効にすることで何が起こっているか情報を得ることができます:

* ジェネレータのデバッグは {{ic|-debug}} コマンドラインフラグを使ってください: {{ic|booster -debug}}
* init のデバッグは {{ic|1=booster.debug=1}} [[カーネルパラメータ]] が存在します。

Booster 自体に問題があると思われる場合は、[https://github.com/anatol/booster/issues GitHub でチケットを作成してください]

=== Booster ジェネレータが "too many open files" エラーで失敗する ===

もし {{ic|strip}} と {{ic|universal}} を有効にしていて {{ic|/usr/lib/modules/glue_helper.ko: pipe2: too many open files}} というエラーが出た場合は、プロセスごとのオープンファイルの上限を上げる必要があります。[[limits.conf#nofile]] を参照してください。

== 参照 ==

* [https://github.com/anatol/booster/blob/develop/README.md upstream README]

セキュリティ

2025-04-07T07:14:19Z

Oech3: sg/* SUID ファイルと SGID ファイル */

[[Category:セキュリティ]]
[[Category:ファイルシステム]]
[[Category:ネットワーク]]
[[en:Security]]
[[fa:امنیت]]
[[ru:Security]]
[[zh-hans:Security]]
{{Related articles start}}
{{Related|PAM}}
{{Related|ケイパビリティ}}
{{Related|アプリケーション一覧/セキュリティ}}
{{Related|:カテゴリ:セキュリティ}}
{{Related articles end}}
この記事には、Arch Linux システムを[[Wikipedia:ja:ハードニング|ハードニング]]するための推奨事項とベストプラクティスを並べています。

== 概念 ==

* システムのセキュリティを厳重にしすぎると、使い物にならなくなることもある。セキュリティと利便性のバランスを取ることが重要だ。重要なのは、安全で ''かつ'' 使いやすいシステムを作ること。
* 最大の脅威は常にユーザー自身である。
* [[Wikipedia:ja:最小権限の原則|最小権限の原則]]: システムの各部分は、必要最小限の権限のみを持つべきであり、それ以上のアクセスは許可されるべきではない。
* 多層防御 (Defense in Depth): セキュリティは独立した複数の層で成り立つべきである。一つの層が突破されても、次の層が攻撃を食い止める仕組みが必要です。
* 少しだけ疑い深くなること。常に警戒すること。うますぎる話には注意すべきだ。それが本当である可能性は低いと思うこと。
* システムを100%安全にする方法はただ一つ。それはネットワークから切り離し、電源を切り、金庫に入れ、コンクリートで固め、二度と使用しないこと。
* 失敗を想定せよ。セキュリティが破られたときに備え、あらかじめ対応策を準備しておくこと。

==パスワード==
パスワードは安全な linux システムのかぎです。パスワードは[[ユーザーとグループ|ユーザーアカウント]], [[ディスク暗号化|暗号化されたファイルシステム]], [[SSH 鍵|SSH]]/[[GPG]] 鍵などを守ります。コンピュータを使用する人を信頼するのに使う主要な手段なので、安全なパスワードを選んでそれを保護するというのがセキュリティの大部分と言っても過言ではありません。

=== 安全なパスワードの選び方 ===

パスワードは、個人情報などから簡単に推測されないよう十分に複雑であり、また、ソーシャルエンジニアリングやブルートフォース攻撃などの手法で[[Wikipedia:Password cracking|クラック]]されないようにする必要があります。強力なパスワードの基本原則は、''長さ''と''ランダム性''に基づいています。暗号学では、パスワードの品質はその[[Wikipedia:Password strength#Entropy as a measure of password strength|エントロピー]]によって測られます。

安全でないパスワードには、以下のようなものが含まれます。また、以下のようなものを元に変更や置き換えを行った場合も同様に危険です。

* 個人を特定できる情報(例:ペットの名前、生年月日、市外局番、好きなビデオゲームなど)
* 単純な文字の置き換えを行った単語(例:{{ic|k1araj0hns0n}})最新の辞書攻撃ではこれらも簡単に解析可能
* 既存の "単語" や一般的な文字列の前後に数字・記号・文字を追加したもの(例:{{ic|DG091101%}})
* 一般的なフレーズや辞書にある単語を短く組み合わせたもの(例:{{ic|photocopyhauntbranchexpose}})文字の置き換えを行っても(例:{{ic|Ph0toc0pyh4uN7br@nch3xp*se}})、安全とは限らない(ただし、後述の "Diceware" を利用した場合は例外あり)
* [[Wikipedia:List of the most common passwords|最も一般的なパスワード]]のいずれか

最も安全なパスワードは、十分に長く(長いほど良い)ランダムなソースから生成されたものです。長いパスワードを使用することが重要です。[https://www.theregister.com/2019/02/14/password_length 弱いハッシュアルゴリズムを使用すると、8文字のパスワードハッシュはわずか数時間で解読可能] です。

{{Pkg|pwgen}} や {{AUR|apg}} のようなツールを使用すると、ランダムなパスワードを生成できます。しかし、これらのパスワードは覚えにくいことがあります。覚えやすくするための1つの方法は、長いパスワードを生成し、最初は最低限の安全な文字数だけを暗記し、完全な文字列を一時的に書き留めることです。時間をかけて入力する文字数を増やしていけば、最終的にはパスワードが筋肉の記憶として定着し、完全に覚える必要がなくなります。この方法は難易度が高いものの、辞書攻撃や "知的" ブルートフォース攻撃(単語の組み合わせや文字の置き換えを考慮する攻撃)に対して非常に強力です。

パスワード管理とは別に、{{Pkg|keepassxc}} はパスワード/パスフレーズの生成機能を提供します。GUI でカスタマイズ可能なパスワード生成機能があり、辞書ベースのパスフレーズもサポートされています。

パスワードを覚えるための1つの方法として、**記憶術(ニーモニック)**を利用することが挙げられます。
例えば、"the girl is walking down the rainy street" というフレーズは、以下のようなパスワードに変換できます。簡単な例:{{ic|t6!WdtR5}} より複雑な例:{{ic|t&6!RrlW@dtR,57}}
この方法は、パスワードを覚えやすくすることができますが、英単語の最初の文字には偏りがあることに注意が必要です([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]] を参照)

また、ランダムに生成したパスワードを紙に書いて安全な場所に保管するという方法も有効です。例えば、財布、カバン、金庫などに保管するのがよいでしょう。ほとんどの人は、デジタルセキュリティよりも物理的な貴重品の保護に関しては理解しやすいため、この方法は現実的です。

さらに、記憶術とランダム生成を組み合わせる方法も効果的です。例えば、長くランダムに生成したパスワードを[[パスワードマネージャ]]に保存し、それをマスターパスワードで管理する方法です。マスターパスワードは記憶し、絶対に保存しないようにします。この方法では、パスワードマネージャーがインストールされているシステムでのみパスワードにアクセスできるようになり、状況によっては不便にもなりますが、セキュリティ強化の側面もあります。一部のパスワードマネージャーにはスマートフォンアプリもあり、手入力が必要な場合にパスワードを表示することができます(この場合、完全にランダムなものではなく、タイピングしやすいが安全なパスワードを使うことも検討できます)ただし、マスターパスワードを忘れるとすべてのパスワードにアクセスできなくなるため、単一障害点になり得ることに注意が必要です。
また、一部のパスワードマネージャーは、保存するパスワードを暗号化するのではなく、マスターパスワードとサービス名から計算する方式を採用しており、新しいシステムでもデータ同期なしで使用できます。

覚えやすく、それでいて強力なパスワードの作成方法として、無関係な単語を複数組み合わせたパスフレーズを使うという方法もあります。この方法では、十分に長いフレーズを使用することで、辞書単語を使うことによるエントロピーの損失を補うことができます。この手法のエントロピーのトレードオフについては、[https://xkcd.com/936/ xkcdのコミック] に示されています。この方法の安全性は、選択可能な単語の集合が大きい(数千語以上)ことと、5〜7語以上のランダムな単語を選択することによって保証されます。攻撃者が選択可能な単語の集合と、使用する単語数を知っていたとしても、(選択可能な単語数) の (選択する単語数) 乗の通りのパスフレーズが生成可能であり、安全性が確保されます。詳細については [https://www.rempe.us/diceware/ Diceware] を参照してください。

さらに詳しい情報については、[https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] や [[Wikipedia:Password strength]] も参考になります。

=== パスワードの管理 ===

強力なパスワードを選んだら、それを安全に保管することが重要です。[[Wikipedia:Keylogger|キーロガー]] (ソフトウェアおよびハードウェア)、スクリーンロガー、[[Wikipedia:Social engineering (security)|ソーシャルエンジニアリング]]、[[Wikipedia:Shoulder surfing (computer security)|ショルダースーフィング]]に注意し、パスワードの使い回しを避けて、セキュリティの低いサーバーから不要な情報が漏れないようにしましょう。[[アプリケーション一覧/セキュリティ#パスワードマネージャ|パスワードマネージャ]]を使用すると、大量の複雑なパスワードを管理できます。パスワードマネージャーからアプリケーションに保存されたパスワードをコピー&ペーストして使用する場合は、毎回コピーした内容をクリアし、ログに保存されないようにしてください(例:プレーンテキストのターミナルコマンドにペーストしないようにし、{{ic|.bash_history}} などのファイルに保存されないようにします)ブラウザ拡張として実装されたパスワードマネージャは、[https://www.spookjs.com サイドチャネル攻撃]に脆弱である可能性があります。これを回避するためには、別のアプリケーションとして実行されるパスワードマネージャーを使用することが推奨されます。

原則として、強力なパスワードを覚えにくいからといって、セキュリティが低いパスワードを選んではいけません。パスワードはバランスを取る必要があります。強力なマスターパスワードと鍵で守られた暗号化された安全なパスワードデータベースを持つ方が、多くの似たような弱いパスワードを使うよりも優れています。パスワードを紙に書いて保管することも、[https://www.schneier.com/blog/archives/2005/06/write_down_your.html] で示されているように、ソフトウェアの脆弱性を避けつつ物理的なセキュリティを確保できるため、非常に効果的です。

パスフレーズの強度のもう一つの側面は、それが他の場所から簡単に回復できないことです。

ディスク暗号化のパスフレーズをログインパスワードと同じに使用する場合(例えば、ログイン時に暗号化されたパーティションやフォルダを自動マウントする場合)、{{ic|/etc/shadow}} が暗号化されたパーティションに保存されるか、または強力な鍵導出関数 (i.e. yescrypt/argon2 や sha512 を PBKDF2 で使用、md5 や低回数の PBKDF2 は避ける) を使用して保存されたパスワードハッシュを使うようにしてください (詳細については [[SHA hashes#SHA パスワードハッシュ|SHA パスワードハッシュ]] を参照してください)

{{Tip|Arch Linux は [https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのハッシュアルゴリズム]を yescrypt に変更しました。もしデフォルトをカスタマイズしていない場合は、{{ic|passwd}} を実行してパスワード変更を行うなどして下さい。}}

パスワードデータベースをバックアップする場合、そのコピーが他のパスフレーズで保護されていないことを確認してください。例えば、暗号化されたドライブや認証されたリモートストレージサービスなどです。もしそのような保護が施されている場合、必要なときにアクセスできなくなります。役立つ方法としては、データベースがバックアップされているドライブやアカウントをマスターパスワードの簡単な暗号学的ハッシュで保護することです。バックアップ場所のリストを保持してください。もしもマスターパスワードが漏洩したと疑われる場合、その場所すべてでパスワードを即座に変更し、マスターパスワードから導出された鍵で保護されたすべてのバックアップと場所も変更する必要があります。

データベースをセキュアにバージョン管理するのは非常に複雑な場合があります。もしその方法を選択するなら、すべてのデータベースバージョンでマスターパスワードを更新する手段を持っている必要があります。マスターパスワードが漏洩したときにそれを即座に知るのは難しいことがあります。他の人がパスワードを発見するリスクを減らすために、定期的にパスワードを変更することを選ぶかもしれません。もしデータベースのコピーの管理が失われたと感じた場合、そのコピーがブルートフォース攻撃によってマスターパスワードを解読される前に、そのデータベース内のすべてのパスワードを変更する必要があります。

=== パスワードのハッシュ ===

ハッシュは一方向の関数です。つまり、入力を計算せずにそのハッシュを解読することは不可能になるように設計されています (例:MD5、SHA)

パスワードハッシュ関数は、ユーザー入力 (パスワード) を計算せずに解読することが不可能になるように設計されています(例:bcrypt)[[Wikipedia:Key derivation function|鍵導出関数]] (KDF; 例:yescrypt、scrypt、PBKDF2) は、入力 (マスターキーやパスワード) から秘密鍵 (例:AESキー、パスワードハッシュ) を導出するために設計された暗号アルゴリズムです。したがって、KDF はパスワードハッシュ関数としても使用できる複数の用途に対応します。

デフォルトでは、Arch Linux はユーザーパスワードをルート専用の読み取り可能な {{ic|/etc/shadow}} ファイルにハッシュ化して保存します。これは、他のユーザーのパラメータが保存される世界に読み取り可能な {{ic|/etc/passwd}} ファイルから分離されています。詳細は [[ユーザーとグループ#ユーザーデータベース]] を参照してください。また、[[#root の制限]] も参照してください。

パスワードは '''passwd''' コマンドを使用して設定され、このコマンドはシステムの暗号化関数でパスワードを[[Wikipedia:Key stretching|ストレッチ]]し、その後 {{ic|/etc/shadow}} に保存されます。パスワードは[[Wikipedia:Salt (cryptography)|ソルト]]も施され、[[Wikipedia:Rainbow table|レインボーテーブル]]攻撃に対して防御されます。詳細は[https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils Linux でパスワードがどのように保存されているか(Shadow ユーティリティを使ったハッシュの理解)]を参照してください。

パスワードハッシュは定義されたフォーマットに従って保存されるため、新たな ''passwd'' コマンドの実行に対してメソッドとパラメータを設定することができます。したがって、{{ic|/etc/shadow}} ファイルに保存された個々のハッシュは、システムでサポートされているハッシュ関数の異種混合になる可能性があります。

フォーマット、ハッシュメソッド、およびパラメータに関する詳細は、{{man|5|crypt}} を参照してください。

{{ic|/etc/login.defs}} ファイルでは、[https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのパスワードハッシュメソッド]{{ic|ENCRYPT_METHOD YESCRYPT}} とそのパラメータ {{ic|YESCRYPT_COST_FACTOR}} が設定されます。

例えば、デフォルトの {{ic|YESCRYPT_COST_FACTOR}} パラメータを増加させると、パスワードからハッシュを導き出すために必要な計算時間が対数的に増加します。これは、システムがユーザーのログインを認証する際や、第三者がパスワードの秘密を取得しようとする場合にも適用されます。

これに対して、SHA-512 ハッシュ関数の計算時間は、パラメータにより線形的に影響されます。以前の Arch のデフォルトについては [[SHA パスワードハッシュ]] を参照してください。yescrypt アルゴリズムは内部で SHA-256、HMAC、およびPBKDF2 を使用してパスワードハッシュを計算することに注意してください。主な理由は、これらの広く使用され、テストされた関数の良い特性を組み合わせ、攻撃への耐性を強化することです。例えば、SHA の多用途性が原因で、この関数のハードウェアサポートが提供され、SHA ハッシュの計算性能が著しく向上したため、パスワードハッシュ関数としての使用が次第に時代遅れになりつつあります。

=== pam_cracklib を用いた強力なパスワードの強制 ===

''pam_pwquality'' は、[[Wikipedia:Dictionary attack|辞書攻撃]]に対する保護を提供し、システム全体で強制できるパスワードポリシーを設定するのに役立ちます。これは ''pam_cracklib'' をベースにしており、そのオプションとの後方互換性があります。

{{Pkg|libpwquality}} パッケージを[[インストール]]してください。

{{Warning|デフォルトでは、''root'' アカウントはこのポリシーの影響を受けません。}}

{{Note|
* ''root'' アカウントを使用すると、設定したパスワードポリシーをバイパスするユーザーパスワードを設定できます。これは一時的なパスワードを設定する際に便利です。
* 現在のパスワードに関するセキュリティガイドライン(例:NISTなど)では、特別な文字を強制することは推奨されていません。なぜなら、それらはしばしば予測可能な変更を引き起こすだけだからです。
}}

例えば、以下のポリシーを強制したい場合:

* エラーが発生した場合にパスワードを2回入力する (retry オプション)
* 最小長10文字 (minlen オプション)
* 新しいパスワードを入力する際、古いパスワードとは少なくとも6文字異なること (difok オプション)
* 最低1桁の数字 (dcredit オプション)
* 最低1つの大文字 (ucredit オプション)
* 最低1つの小文字 (lcredit オプション)
* 最低1つのその他の文字 (ocredit オプション)
* "myservice" および "mydomain" という単語を含めない
* root にもこのポリシーを強制する

{{ic|/etc/pam.d/passwd}}ファイルを以下のように編集します:

{{bc|1=
#%PAM-1.0
password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root
password required pam_unix.so use_authtok sha512 shadow
}}

{{ic|password required pam_unix.so use_authtok}} は、''pam_unix'' モジュールに対してパスワードの入力を促さず、代わりに ''pam_pwquality'' で提供されたものを使用するように指示します。

詳細については、{{man|8|pam_pwquality}} および {{man|8|pam_unix}} のマニュアルページを参照してください。

== CPU ==

=== マイクロコード ===

CPU のマイクロコードに対する重要なセキュリティ更新プログラムをインストールする方法については、[[マイクロコード]] を参照してください。

=== ハードウェアの脆弱性 ===

CPU の中には、ハードウェアの脆弱性を含んでいるものがあります。これらの脆弱性の一覧と、特定の使用シナリオに合わせてこれらの脆弱性を緩和するためにカーネルをカスタマイズするのに役立つ緩和策の選択ガイドについては、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/ kernel documentation on hardware vulnerabilities] を参照してください。

既知の脆弱性の影響を受けているかどうかを確認するには、以下を実行してください。

$ grep -r . /sys/devices/system/cpu/vulnerabilities/

ほとんどの場合、カーネルとマイクロコードを更新することで、脆弱性を軽減することができます。

==== 同時マルチスレッディング (ハイパースレッディング) ====

[https://ja.wikipedia.org/wiki/%E5%90%8C%E6%99%82%E3%83%9E%E3%83%AB%E3%83%81%E3%82%B9%E3%83%AC%E3%83%83%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0 同時マルチスレッディング]] (SMT) は、インテル CPU のハイパースレッディングとも呼ばれ、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html L1 Terminal Fault] および [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html Microarchitectural Data Sampling] 脆弱性の原因となる可能性のあるハードウェア機能です。Linux カーネルとマイクロコードのアップデートには、既知の脆弱性に対する緩和策が含まれていますが、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html#virtualization-with-untrusted-guests 信頼できない仮想化ゲストが存在する場合、特定の CPU で SMT を無効にしたほうが良い場合があります。]

SMT は、システムのファームウェアで無効にできることがよくあります。詳細については、マザーボードまたはシステムのドキュメントを参照してください。また、以下の [[カーネルパラメータ]] を追加することで、カーネルで SMT を無効にすることができます。

l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force

== メモリ ==

===ハード化された malloc ===

[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened_malloc}}, {{AUR|hardened-malloc-git}}) は [https://ja.wikipedia.org/wiki/GNU_C%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA glibc] の malloc() をハード化した代替品です。元々は Android の [[Wikipedia:Bionic (software)|Bionic]] と [https://ja.wikipedia.org/wiki/Musl musl] に組み込むために開発されましたが、 x86_64 アーキテクチャの標準 Linux ディストリビューションのサポートにも組み込みました。

hardened_malloc はまだ glibc に統合されていませんが(支援とプルリクエストは歓迎します)、LD_PRELOAD と一緒に簡単に使用することができます。これまでのテストでは、 {{ic|/etc/ld.so.preload}} でグローバルに有効にすると、一握りのアプリケーションにしか問題を起こしません。例えば、{{ic|getrandom}} が標準のホワイトリストにないため、{{ic|seccomp}} 環境フラグが無効でないと {{ic|man}} は正常に動作しませんが、これはシステムコールを追加して再構築すれば簡単に修正可能です。hardened_malloc は性能上のコストがあるので、どの実装を使うかは攻撃対象領域と性能上の必要性に基づいてケースバイケースで決めるとよいでしょう。

スタンドアロンで試すには、hardened-malloc-preload ラッパースクリプトを使用するか、適切なプリロード値でアプリケーションを手動で開始します。

LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox

[[Firejail]] の正しい使い方は、その wiki ページにあります。また、hardened_malloc の設定可能なビルドオプションは、githubレポで見つけることができます。

== ストレージ ==

===ディスク暗号化===

[[ディスク暗号化]]、特に [[#パスワード|強力なパスフレーズ]] を使用したフルディスク暗号化は、物理的な回復からデータを守る唯一の方法です。これにより、コンピュータの電源がオフになっている場合や、対象のディスクがアンマウントされている場合にデータの機密性が保たれます。

ただし、コンピュータの電源が入っており、ドライブがマウントされている場合、そのデータは暗号化されていないドライブと同様に脆弱です。そのため、データパーティションがもう必要なくなったら、できるだけ早くアンマウントすることが最良の実践です。

また、[[Trusted Platform Module#LUKS による保存データの暗号化|TPMにキーを保存してドライブを暗号化]] することもできますが、過去に [https://tpm.fail 脆弱性] があり、キーは [https://pulsesecurity.co.nz/articles/TPM-sniffing TPMバススニッフィング攻撃] によって抽出される可能性があります。

[[dm-crypt]] のような特定のプログラムは、ユーザーが仮想ボリュームとしてループファイルを暗号化できるようにします。これは、システムの特定の部分だけを安全に保護する必要がある場合、フルディスク暗号化の合理的な代替手段です。

[[ディスク暗号化]] の記事で比較されているブロックデバイスやファイルシステムベースの暗号化方法は、物理メディア上のデータ保護には有効ですが、リモートシステム(例えば [[保存データ暗号化#クラウドストレージの最適化|クラウドストレージ]])に保存されたデータを保護するためには使用できません。そのため、個々のファイル暗号化が役立つ場合もあります。

ファイルを暗号化するためのいくつかの方法は次の通りです:

* 一部の [[アーカイブと圧縮|アーカイブおよび圧縮]] ツールは基本的な暗号化も提供します。例としては、[[7-Zip]] ({{ic|-p}} フラグ)、{{Pkg|zip}} ({{ic|-e}}フラグ) があります。これらのツールはクロスプラットフォームの互換性のためにカスタムアルゴリズムを使用している場合があるため、特別な注意を払って使用するべきです。[https://math.ucr.edu/~mike/zipattacks.pdf]
* [[GnuPG]] を使用してファイルを [[GnuPG#Encrypt and decrypt|暗号化]] できます。
* {{Pkg|age}} は、シンプルで使いやすいファイル暗号化ツールです。複数の受信者をサポートしており、SSH キーを使用した暗号化もサポートしているため、安全なファイル共有に役立ちます。

=== ファイルシステム ===

現在カーネルは {{ic|fs.protected_hardlinks}} や {{ic|fs.protected_symlinks}} sysctl スイッチが有効になっていればハードリンクやシンボリックリンクに関するセキュリティの問題を解決するので、world-writable なディレクトリを分離させるセキュリティ的な利点はもはや存在しません。

それでもディスク容量が消耗したときのダメージを低減させる荒っぽい方法として world-writable なディレクトリを含むパーティションが分割されることがあります。しかしながら、サービスを落とすには {{ic|/var}} や {{ic|/tmp}} などのパーティションを一杯にするだけで十分です。この問題の対処についてはもっと柔軟性のある方法が存在します (クォータなど)、またファイルシステムによっては関連する機能を持っていることがあります (btrfs はサブボリュームにクォータを設定できます)。

====マウントオプション====

最小特権の原則に従い、ファイルシステムは可能な限り制限の厳しいマウントオプションを使用してマウントするべきです(機能を失わない範囲で)

関連するマウントオプションは以下の通りです:

* {{ic|nodev}}: ファイルシステム上のキャラクタデバイスやブロックデバイスを解釈しない。
* {{ic|nosuid}}: set-user-identifier や set-group-identifier ビットを無効にする。
* {{ic|noexec}}: マウントされたファイルシステム上のバイナリを直接実行できないようにする。
** {{ic|/home}} に {{ic|noexec}} を設定すると、実行可能なスクリプトが禁止され、[[Wine]]、[[Steam]]、PyCharm、[[.NET]] などが動作しなくなります。
*** Wine は Windows バイナリの実行に {{ic|exec}} フラグを必要としません。ただし、Wine 自体を {{ic|/home}} にインストールする場合は必要です。
*** [[Steam]] を動作させるには、{{ic|/home/user/.local/share/Steam}} を [[fstab]] で {{ic|exec}} としてマウントできます。以下の設定を追加してください: {{bc|/home/user/.local/share/Steam /home/user/.local/share/Steam none defaults,bind,user,exec,nofail 0 0}}
** 一部のパッケージ(例:{{Pkg|nvidia-dkms}} のビルド)では、{{ic|/var}} に {{ic|exec}} が必要な場合があります。

データ用のファイルシステムは、常に {{ic|nodev}}、{{ic|nosuid}}、{{ic|noexec}} を指定してマウントするべきです。

マウントを検討すべきファイルシステム:

* {{ic|/var}}
* {{ic|/home}}
* {{ic|/dev/shm}}
* {{ic|/tmp}}
* {{ic|/boot}}

{{Tip|[[systemd#GPT パーティションの自動マウント|GPT パーティションの自動マウント]] を使用する場合、ESP および XBOOTLDR パーティションは [https://github.com/systemd/systemd-stable/commit/49804cfb71d3a79f433096e4cfb5616980171336 常に {{ic|noexec,nosuid,nodev}} で強化] されます。}}

==== スナップショット ====

ファイルシステムのスナップショットを利用する場合(例えば [[Btrfs]]、[[LVM]]、[[ZFS]] など)、スナップショットがユーザーが削除したと期待している機密情報を保持する可能性があることを理解することが重要です。特に、[[Snapper]] のような自動スナップショットツールを設定している場合、定期的またはシステムイベントに応じてスナップショットが作成されるため、この問題が発生しやすくなります。

以下は、{{ic|/home/}} 内の機密情報がスナップショットに残存する例です:

* 削除されたファイルやディレクトリ: ファイルシステム上から削除されたとしても、古いスナップショット内には残存している可能性があります。これは通常想定される動作ですが、{{ic|.local/share/Trash/}}、{{ic|.history}} などのファイルやディレクトリを保持する必要があるかどうかを検討すべきです。
* 一時ファイルやキャッシュ: アプリケーションによって生成された一時ファイルやキャッシュデータもスナップショットに含まれる可能性があります。例えば、暗号化されたディレクトリ内のファイルを開くと、サムネイル({{ic|.cache/thumbnails}})や作業用のコピーが作成され、それらがスナップショットに含まれる可能性があります。同様に、ブラウザの履歴({{ic|.mozilla/}}、{{ic|.config/chromium/}} など)も、削除される前にスナップショットに記録されている場合があります。

対応可能であれば、これらのディレクトリをスナップショットの対象から完全に除外することを検討してください。例えば、[[Btrfs]] を使用している場合、{{ic|.cache/}}、{{ic|.config/}}、{{ic|.local/}}、{{ic|.var/}} など、用途に応じたディレクトリをサブボリュームとして作成することで、スナップショットの影響を受けにくくできます。

{{Note|{{ic|.local/share/Trash}} を別のサブボリュームに移動すると、場合によっては [[GNOME/Files]] などでゴミ箱の機能が正常に動作しなくなる可能性があります。}}

===ファイルシステムのパーミッション===

デフォルトの [[パーミッション]] では、ほとんどのファイルが読み取り可能になっていますが、これを変更することで、{{ic|http}} ユーザーや {{ic|nobody}} ユーザーなどの非 root アカウントに侵入した攻撃者から貴重な情報を隠すことができます。[[chmod]] を使用して、グループやその他のユーザーからすべてのアクセス権を削除できます。

# chmod go-r ''path_to_hide''

{{Warning|この設定を広範囲に適用しないでください。1つの設定ファイルごとに適用し、非表示にする価値があるか、プログラムの動作に影響しないかを確認してください。グループが必要な場合は、{{ic|g}} をコマンドから削除するか、既に実行してしまった場合は {{ic|chmod g+r path}} で再度許可を追加する必要があるかもしれません。}}

考慮すべきパスの例:

* {{ic|/boot}}: [[パーティショニング#/boot|ブートディレクトリ]]、[[vmlinuz]] や [[initramfs]] image、または [[ユニファイドカーネルイメージ]] が含まれる場合があります。なお、[[systemd# GPT パーティションの自動マウント]] を使用する場合、デフォルトで安全なパーミッションが適用されます。
* {{ic|/etc/nftables.conf}}: [[nftables]] の設定ファイル({{Pkg|nftables}} および {{Pkg|iptables-nft}} に適用)
* {{ic|/etc/iptables}}: レガシーな [[iptables]] の設定ファイル({{Pkg|iptables}} に適用)

また、新しく作成されるファイルのセキュリティを向上させるために、デフォルトの [[umask]] 値 {{ic|0022}} を変更することも可能です。[https://apps.nsa.gov/iaarchive/library/ia-guidance/security-configuration/operating-systems/guide-to-the-secure-configuration-of-red-hat-enterprise.cfm NSA RHEL5 Security Guide] では最大限のセキュリティを確保するために、{{ic|0077}} を推奨しており、これにより所有者以外のユーザーが新しいファイルを読み取れなくなります。変更方法については [[Umask#マスクの値を設定]] を参照してください。

さらに、[[sudo]] を使用する場合、[[Sudo#Permissive umask|デフォルトの root umask]] を適用するよう設定することを検討してください。

=== SUID ファイルと SGID ファイル ===

[[Wikipedia:ja:Setuid|Setuid]] ビットや Setgid ビットが設定されたファイルには注意しましょう。このようなファイルの例としては、以下があります。

* [[PAM|unix_chkpwd]]
* chage expiry gpasswd groupmems [[passwd]] sg ({{Pkg|shadow}} パッケージ)
* [[FUSE|fusermount3]]
* pkexec polkit-agent-helper-1 ([[polkit]] パッケージ)
* [[OpenSSH|ssh-keysign]]
* chfn chsh mount newgrp umount wall write ({{Pkg|util-linux}} パッケージ)
* [[sudo]] [[doas]] [[su]] [[Kerberos|ksu]]
* [[firejail]]
* [[Dbus|dbus-daemon-launch-helper]]
* [[Chromium|chromium-sandbox]]

このような実行ファイルの主なリスクとして、特権昇格の脆弱性があります。例えば [[Wikipedia:Setuid#Security impact]] を参照してください。[https://www.cvedetails.com/vulnerability-list/vendor_id-16224/product_id-36412/Calibre-ebook-Calibre.html][https://www.cvedetails.com/product/32625/Sudo-Project-Sudo.html?vendor_id=15714][https://www.cvedetails.com/vulnerability-list/vendor_id-16191/Firejail-Project.html]

SUID ビットが設定されているが root によって所有されていないファイル、または SGID ビットが設定されているファイルは、''典型的には''潜在的なリスクがより小さいですが、理論上、そのようなファイルに脆弱性が存在している場合は、依然として損害を与える可能性があります。通常、代わりに[[ケイパビリティ]]を割り当てることによって、Setuid や Setgid の使用を回避することが可能です。

{{Tip|SUID/SGID 実行ファイルを含むパッケージを最新に保って、脆弱性からシステムを守ることが肝心です。}}

SUID ビットか SGID ビットを持つファイルを {{ic|/usr/bin}} から探すには:

$ find /usr/bin -perm "/u=s,g=s"

== ユーザー設定 ==

=== root アカウントを日常的に使用しない ===

最小特権の原則に従い、root ユーザーを日常的に使用しないようにしてください。システムを使用する各人に非特権ユーザーアカウントを作成するか。一時的な特権アクセスには、必要に応じて [[sudo]] を使用する。

=== ログイン失敗後の遅延時間の設定 ===

以下の行を {{ic|/etc/pam.d/system-login}} に追加し、ログインに失敗した際に最低4秒の遅延を追加します。

{{hc|/etc/pam.d/system-login|2=
auth optional pam_faildelay.so delay=4000000
}}

{{ic|4000000}} は遅延させる時間をマイクロ秒単位で指定します。

===3回ログインを失敗したユーザーをロックアウトする===

{{Pkg|pambase}} 20200721.1-2 の時点では、デフォルトで {{ic|pam_faillock.so}} が有効になっており、15分間に3回ログインに失敗すると10分間ユーザをロックアウトします ({{Bug|67644}} を参照してください) このロックアウトはパスワード認証 (例:ログインと ''sudo'') にのみ適用され、SSH 経由の公開鍵認証はそのまま利用可能です。完全なサービス拒否を防ぐために、このロックアウトは root では無効になっています。

ユーザーをロック解除するには、次のようにします。

$ faillock --reset --user ''username''

デフォルトでは、ロック機構は {{ic|/run/faillock/}} にあるユーザーごとのファイルです。ディレクトリの所有者は root ですが、ファイルの所有者はユーザーなので、 {{ic|faillock}} コマンドはファイルを空にするだけで、root は必要ありません。

モジュール {{ic|pam_faillock.so}} は、ファイル {{ic|1=/etc/security/faillock.conf}} で設定することが可能です。ロックアウトのパラメータです。

* {{ic|unlock_time}} - ロックアウト時間 (秒単位、デフォルトは10分)
* {{ic|fail_interval}} - ロックアウトに失敗するとロックアウトされる時間 (秒単位、デフォルトは15分)
* {{ic|deny}} - ロックアウトするまでに何回ログインに失敗するか (デフォルトは 3)

{{Note|{{ic|1=deny = 0}} はロックアウトを無効化します}}

デフォルトでは、すべてのユーザーロックは再起動後に失われます。攻撃者がマシンをリブートできるのであれば、ロックは持続させた方が安全です。ロックを持続させるには、{{ic|1=/etc/security/faillock.conf}} の {{ic|dir}} パラメータを {{ic|/var/lib/faillock}} に変更する必要があります。

変更を反映させるために再起動する必要はありません。root アカウントのロックアウトを有効にする、集中ログイン (LDAP など) を無効にするなど、さらなる設定オプションについては {{man|5|faillock.conf}} を参照してください。

=== プロセスの数を制限する ===

信頼できないユーザーが大量に存在するシステムでは、一度に実行できるプロセスの数を制限して、[[Wikipedia:ja:Fork爆弾|フォーク爆弾]]などのサービス拒否攻撃を予防することが重要です。ユーザーやグループごとに実行できるプロセスの数は {{ic|/etc/security/limits.conf}} で定義することができ、デフォルトでは空になっています。以下の値をファイルに追加すると、実行できるプロセスが100個までに制限されます。{{ic|prlimit}} コマンドを使って一時的に上げられる最大数も200個までに制限します。ユーザーが普段実行するプロセスの数や、管理するハードウェアにあわせて適切な値に変更してください。

* soft nproc 100
* hard nproc 200

=== Wayland を使用する ===

[[Xorg]] よりも [[Wayland]] を使用することをお勧めします。Xorg の設計は現代のセキュリティ慣行より古く、多くの人が [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 は安全でないと考えています] 例えば、Xorg のアプリケーションは非アクティブな状態でもキーストロークを記録することがあります。

もし Xorg を実行しなければならないなら、[[Xorg#Rootless_Xorg|root での実行を避ける]]ことが推奨されます。Wayland 内では、XWayland 互換レイヤーは自動的に root レス Xorg を使用します。

== root の制限 ==
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。

=== su の代わりに sudo を使う ===
[[Su#セキュリティ|色々な理由]]から特権アクセスには [[su]] よりも [[sudo]] を使うほうが好ましいとされます。

* 通常の権限しか持たないユーザーが実行した特権コマンドのログを保持します。
* root アクセスを必要とする各ユーザーに root ユーザーのパスワードを与える必要がありません。
* 完全な root ターミナルは作成されないため、{{ic|sudo}} は root アクセスが必要ないコマンドを偶発的に ''root'' で実行してしまうことを防止します。これは[[Wikipedia:ja:最小権限の原則|最小権限の原則]]と合っています。
* 一つのコマンドを実行するためだけに完全な root アクセスを与える代わりに、ユーザーごとに個々のプログラムを有効にすることができます。例えば、ユーザー ''alice'' に特定のプログラムへのアクセス権限を与えるには:

# visudo

{{hc|/etc/sudoers|
alice ALL = NOPASSWD: /path/to/program}}

また、全てのユーザーに個別のコマンドを許可することも可能です。通常ユーザーでサーバーから Samba 共有をマウントするには:

%users ALL=/sbin/mount.cifs,/sbin/umount.cifs

これによって users グループのメンバーである全てのユーザーが全てのマシン (ALL) から {{ic|/sbin/mount.cifs}} や {{ic|/sbin/umount.cifs}} コマンドを実行できるようになります。

{{Tip|{{ic|visudo}} で {{ic|vi}} の代わりに {{ic|nano}} を使うには:

{{hc|/etc/sudoers|
2=Defaults editor=/usr/bin/rnano
}}
{{ic|1=# EDITOR=nano visudo}} のエクスポートは何にでも {{ic|EDITOR}} として使うことができるためにセキュリティリスクとされています。
}}

==== sudo を使ってファイルを編集する ====
root で {{ic|vim}} などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:

export SUDO_EDITOR=rvim

ファイルの編集には {{ic|sudoedit filename}} または {{ic|sudo -e filename}} を使って下さい。自動的に {{ic|rvim}} によって {{ic|filename}} が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。

=== root ログインの制限 ===
[[sudo]] を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。[[sudo]] を使える状態のまま root を無効化したい場合、{{ic|passwd -l root}} を使用します。

==== 特定のユーザーだけに許可を与える ====
[[Wikipedia:Pluggable authentication module|PAM]] の {{ic|pam_wheel.so}} は {{ic|wheel}} グループに入っているユーザーだけに {{ic|su}} を使用したログインを許可します。{{ic|/etc/pam.d/su}} と {{ic|/etc/pam.d/su-l}} の両方を編集して次の行をアンコメントしてください:
{{bc|<nowiki>
# Uncomment the following line to require a user to be in the "wheel" group.
auth required pam_wheel.so use_uid
</nowiki>}}
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。

==== ssh ログインを拒否する ====
ローカルユーザーの root ログインを拒否したくない場合でも、[[SSH#root ログインを拒否する|SSH による root ログインを拒否]]するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。

==== access.conf で許容されるログインの組み合わせを指定する ====

誰かが [[PAM]] でログインしようとすると、 {{ic|/etc/security/access.conf}} がそのログインプロパティに一致する最初の組み合わせをチェックします。そして、その組み合わせのルールに基づいて、試行が失敗するか成功するかが決まります。

+:root:LOCAL
-:root:ALL

特定のグループやユーザーに対してルールを設定することができます。この例では、ユーザー archie は、wheel および adm グループに属するすべてのユーザーと同様に、ローカルでのログインを許可されています。それ以外のログインは拒否されます。

+:archie:LOCAL
+:(wheel):LOCAL
+:(adm):LOCAL
-:ALL:ALL

詳しくは {{man|5|access.conf}} で確認してください。

==強制アクセス制御==

[[Wikipedia:ja:強制アクセス制御|強制アクセス制御]] (Mandatory Access Control, MAC) は Arch やほとんどの Linux ディストリビューションで使われている[[Wikipedia:ja:任意アクセス制御|任意アクセス制御]] (Discretionary Access Control, DAC) とは大きく異なるタイプのセキュリティポリシーです。原則的に MAC ではシステムに影響を与えるプログラムの行動は全てセキュリティルールセットによってチェックを受けます。このルールセットは、DAC とは対照的に、ユーザーが変更することは不可能です。実装方法は色々と異なるタイプが存在しますが、強制アクセス制御を使うことで実質的にコンピュータのセキュリティを著しく向上させることになります。

===パス名 MAC===
パス名ベースのアクセス制御は指定されたファイルのパスに基づいてパーミッションを与えるというシンプルな形式のアクセス制御です。この形式のアクセス制御の欠点としてはファイルが移動されてもパーミッションはファイルと一緒に付いていかないということが挙げられます。プラス面となるのは、パス名ベースの MAC はラベルベースの MAC と異なり、幅広いファイルシステムに実装できることです。

*[[AppArmor]] は [[Wikipedia:ja:カノニカル|Canonical]] によって開発されている MAC 実装で SELinux に比べて"簡単"になっています。
*[[TOMOYO Linux|Tomoyo]] はもうひとつのシンプルで、使いやすい強制アクセス制御を提供するシステムです。利用と実装の両面でシンプルになるように設計されており、依存するライブラリがとても少なくなっています。

===ラベル MAC===
ラベルベースのアクセス制御ではファイルの拡張属性を使ってセキュリティパーミッションを管理します。このシステムはセキュリティの機能においてパス名ベースの MAC よりも間違いなく柔軟性が高い一方、拡張属性をサポートしているファイルシステムでしか動作しません。

*[[SELinux]] は、Linux セキュリティを向上させる [[Wikipedia:ja:アメリカ国家安全保障局|NSA]] プロジェクトに基づいており、システムユーザーやロールとは完全に独立して MAC を実装しています。成長してオリジナルの設定が変わっていくシステムのコントロールを簡単に維持できる、極めて強固なマルチレベル MAC ポリシー実装を提供します。

=== アクセス制御リスト ===
[[アクセス制御リスト]] (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。

== カーネルの堅牢化 ==

=== カーネルの自己防衛機能/脆弱性攻撃対策 ===

{{pkg|linux-hardened}} パッケージは、[https://github.com/anthraxx/linux-hardened 基本的なカーネル堅牢化パッチセット]と、{{pkg|linux}} パッケージよりもセキュリティに重点を置いたコンパイル時設定オプションを使用します。カスタムビルドでは、セキュリティ寄りのデフォルトとは異なる、セキュリティと性能の妥協点を選択することができます。

しかし、このカーネルを使うといくつかのパッケージが動かなくなることに注意する必要があります。例えば

* {{AUR|skypeforlinux-preview-bin}}
* {{AUR|skypeforlinux-stable-bin}}
* {{pkg|throttled}}

[[NVIDIA]] などのアウトオブツリードライバを使用している場合、その [[DKMS]] パッケージに切り替える必要があるかもしれません。

==== ユーザー空間 ASLR の比較 ====

{{pkg|linux-hardened}} パッケージは、アドレス空間配置ランダム化の改善された実装をユーザ空間のプロセスに対して提供します。{{pkg|paxtest}} コマンドを使うことで、提供されるエントロピーの推定値を得ることができます:

===== 64 ビットプロセス =====

{{hc|linux-hardened 5.4.21.a-1-hardened|
Anonymous mapping randomization test : 32 quality bits (guessed)
Heap randomization test (ET_EXEC) : 40 quality bits (guessed)
Heap randomization test (PIE) : 40 quality bits (guessed)
Main executable randomization (ET_EXEC) : 32 quality bits (guessed)
Main executable randomization (PIE) : 32 quality bits (guessed)
Shared library randomization test : 32 quality bits (guessed)
VDSO randomization test : 32 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)
Randomization under memory exhaustion @~0: 32 bits (guessed)
Randomization under memory exhaustion @0 : 32 bits (guessed)
}}

{{hc|linux 5.5.5-arch1-1|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 20 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 29 bits (guessed)
Randomization under memory exhaustion @0 : 29 bits (guessed)
}}

{{hc|linux-lts 4.19.101-1-lts|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 19 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 28 bits (guessed)
Randomization under memory exhaustion @0 : 28 bits (guessed)
}}

===== 32 ビットプロセス (x86_64 カーネル上) =====

{{hc|linux-hardened|
Anonymous mapping randomization test : 16 quality bits (guessed)
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)
Heap randomization test (PIE) : 27 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 18 quality bits (guessed)
Shared library randomization test : 16 quality bits (guessed)
VDSO randomization test : 16 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)
Randomization under memory exhaustion @~0: 18 bits (guessed)
Randomization under memory exhaustion @0 : 18 bits (guessed)
}}

{{hc|linux|
Anonymous mapping randomization test : 8 quality bits (guessed)
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)
Heap randomization test (PIE) : 13 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 8 quality bits (guessed)
Shared library randomization test : 8 quality bits (guessed)
VDSO randomization test : 8 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)
Randomization under memory exhaustion @~0: No randomization
Randomization under memory exhaustion @0 : No randomization
}}

=== proc ファイルシステム内のカーネルポインタへのアクセスを制限する ===

{{ic|kernel.kptr_restrict}} を 1 に設定すると、{{ic|CAP_SYSLOG}} を持たない通常ユーザから {{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが秘匿され、カーネルのエクスプロイトで動的にアドレス/シンボルを解決することが困難になります。これは、事前にコンパイルされた Arch Linux カーネルではあまり意味がありません。周到な攻撃者はカーネルパッケージをダウンロードして、そこから手動でシンボルを取得することができるからです。しかしながら、自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし、一部の {{Pkg|perf}} コマンドの機能が、root 以外のユーザによって使用されば場合に破壊されます (しかし、いずれにせよ多くの {{Pkg|perf}} コマンドは root アクセスを必要とします)。詳細は {{Bug|34323}} を参照してください。

{{ic|kernel.kptr_restrict}} を 2 に設定すると、{{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが権限に依らず隠されます。

{{hc|/etc/sysctl.d/51-kptr-restrict.conf|2=
kernel.kptr_restrict = 1
}}

{{Note|{{pkg|linux-hardened}} はデフォルトで {{ic|0}} ではなく {{ic|1=kptr_restrict=2}} を設定します。}}

=== BPF の堅牢化 ===

BPF は、実行時にカーネル内のバイトコードを動的にロードして実行するために使用されるシステムです。ネットワーク (XDP, tc など)、トレース (kprobes, uprobes, tracepoints など)、セキュリティ (seccomp など) など、多くの Linux カーネルサブシステムで使用されています。また、高度なネットワークセキュリティ、パフォーマンスプロファイリング、ダイナミックトレースにも有効です。

BPF はもともと [[Wikipedia:ja:Berkeley Packet Filter|Berkeley Packet Filter]] の頭文字をとったもので、オリジナルの古典的な BPF は BSD 用のパケットキャプチャツールに使われていたためです。これは最終的に拡張 BPF (eBPF) に発展し、その後まもなくただの BPF (頭字語ではありません) に改名されました。BPFはパケットフィルタリングツールの実装に使われることがありますが、 iptables や netfilter のようなパケットフィルタリングツールと混同しないでください。

BPF のコードは解釈されるか、[[Wikipedia:ja:実行時コンパイラ|Just-In-Time (JIT) コンパイラ]]を使ってコンパイルされるかのどちらかです。Arch のカーネルは {{ic|CONFIG_BPF_JIT_ALWAYS_ON}} でビルドされており、BPF インタープリタを無効にして全ての BPF を JIT コンパイラでコンパイルするよう強制しています。これにより、攻撃者が BPF を使って SPECTRE 型の脆弱性を悪用した特権昇格攻撃をすることが難しくなります。詳しくは、[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290af86629b25ffd1ed6232c4e9107da031705cb CONFIG_BPF_JIT_ALWAYS_ON を導入したカーネルパッチ]を参照してください。

カーネルは JIT コンパイルされた BPF に対して、パフォーマンスと多くの BPF プログラムをトレース・デバッグする能力を犠牲にして、ある種の JIT スプレー攻撃を軽減するための堅牢化機能を備えています。この機能は、{{ic|net.core.bpf_jit_harden}} を {{ic|1}} (非特権コードの堅牢化を有効化する) か {{ic|2}} (全てのコードの堅牢化を有効化する) に設定することで有効化できます。

詳しくは、[https://docs.kernel.org/admin-guide/sysctl/net.html カーネルドキュメント] の {{ic|net.core.bpf_*}} 設定を参照してください。

{{Tip|
* {{Pkg|linux-hardened}} では、デフォルトで {{ic|1=net.core.bpf_jit_harden=2}} が設定されており、{{ic|0}} ではありません。
* デフォルトでは、BPF プログラムは非特権ユーザでも実行可能です。この挙動を変更するには {{ic|1=kernel.unprivileged_bpf_disabled=1}} を設定してください [https://access.redhat.com/security/cve/cve-2021-33624]。
}}

=== ptrace スコープ ===

{{man|2|ptrace}} システムコールは、あるプロセス ("tracer") が他のプロセス ("tracee") の実行を監視、制御し、tracee のメモリとレジスタを検査、変更するための手段を提供します。通常、{{ic|ptrace}} は ''gdb'' や ''strace''、''perf''、''reptyr'' などのデバッグツールによって使用されます。しかし、他のプロセスからデータを読んだり、他のプロセスの制御を奪ったりする手段を悪意のあるプロセスにも提供してしまいます。

Arch では、{{ic|kernel.yama.ptrace_scope}} [[カーネルパラメータ]]を提供する [https://docs.kernel.org/admin-guide/LSM/Yama.html Yama LSM] がデフォルトで有効化されています。このパラメータはデフォルトで {{ic|1}} (制限) に設定されており、{{ic|CAP_SYS_PTRACE}} [[ケイパビリティ]]も特権も持たない tracer が制限されたスコープ外で {{ic|ptrace}} コールを実行できないようにしています。これは、古典的なパーミッションと比べてセキュリティ上大きな改善です。このモジュールが無いと、同じユーザとして実行されているプロセスを隔てるものがなくなってしまいます ({{man|7|pid_namespaces}} などの他のセキュリティレイヤーがない場合)。

{{Note|デフォルトでは、[[sudo]] を使うなどして、{{ic|ptrace}} を必要とするツールを特権プロセスとして実行することができます。}}

デバッグツールを使う必要がない場合は、システムを堅牢化するために {{ic|kernel.yama.ptrace_scope}} を {{ic|2}} (管理者限定) や {{ic|3}} ({{ic|ptrace}} を禁止) に設定することを検討してください。

=== hidepid ===

{{Warning|
* これは、サンドボックスと [[Xorg]] 内で実行するアプリケーションなど、特定のアプリケーションで問題を発生させる場合があります (回避策を見てください)。
* {{Pkg|systemd}} > 237.64-1 を使用している場合、これは [[D-Bus]]、[[Polkit]]、[[PulseAudio]]、そして [[bluetooth]] で問題を発生させます。
}}

カーネルには、{{ic|proc}} ファイルシステムを {{ic|1=hidepid=}} オプションと {{ic|1=gid=}} オプションを使ってマウントすることで、他のユーザのプロセス (通常、{{ic|/proc}} でアクセス可能) を非特権ユーザから秘匿する機能があります。これらのマウントオプションは https://docs.kernel.org/filesystems/proc.html でドキュメント化されています。

これにより、侵入者が動作中のプロセスの情報 (特権で動作しているデーモンがあるか、他のユーザが機密情報を扱うプログラムを実行しているか、他のユーザがプログラムを実行しているか) を得る作業を複雑化し、ユーザが特定のプログラムを実行しているかどうかを知るのを不可能にし (ただし、そのプログラムがそれ自体の挙動で存在を他者に知られることがないとする)、さらに、貧弱に書かれたプログラムが機密情報をプログラム引数を介して渡したとしてもローカルの盗聴者から守られます。

{{ic|proc}} [[ユーザーとグループ#システムグループ#グループ]] ({{Pkg|filesystem}} パッケージによって提供されています) は、他のユーザのプロセス情報を得ることのできるユーザのホワイトリストとして機能します。ユーザやサービスが自身以外の {{ic|/proc/<pid>}} ディレクトリにアクセスする必要がある場合、そのユーザまたはサービスを[[ユーザーとグループ#グループ管理|proc グループに追加してください]]。

例えば、プロセスの情報を {{ic|proc}} グループに属さない他のユーザから隠すには:

{{hc|/etc/fstab|2=
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
}}

ユーザのセッションを正しく動作させるために、''systemd-logind'' を例外として追加する必要があります:

{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=
[Service]
SupplementaryGroups=proc
}}

=== モジュールのロードを制限する ===

デフォルトの Arch カーネルは {{ic|CONFIG_MODULE_SIG_ALL}} が有効で、{{Pkg|linux}} パッケージの一部としてビルドされた全てのカーネルモジュールに署名します。これにより、カーネルは有効なキーで署名されたモジュールだけをロードするように制限できます。実際、これはローカルでコンパイルされた、もしくは {{Pkg|virtualbox-host-modules-arch}} などのパッケージによって提供された、ツリー外のモジュールは全てロードできないことを意味します。

カーネルモジュールの読み込みは {{ic|1=module.sig_enforce=1}} [[カーネルパラメータ]]を設定することで制限することができます。詳細は[https://docs.kernel.org/admin-guide/module-signing.html カーネルドキュメント]で見られます。

=== kexec を無効にする ===

Kexec は、現在実行中のカーネルを置き換えることを可能にします。

{{hc|/etc/sysctl.d/51-kexec-restrict.conf|2=
kernel.kexec_load_disabled = 1
}}

{{Tip|kexec は {{pkg|linux-hardened}} でデフォルトで無効になっています。}}

=== カーネルロックダウンモード ===

Linux 5.4 から、オプションの[https://mjg59.dreamwidth.org/55105.html ロックダウン機能]がカーネルに[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d 追加されました]。これは、UID 0 (root) とカーネルの間の境界を強化することを目的としています。この機能を有効にすると、ハードウェアやカーネルへの低レベルなアクセスに依存している一部のアプリケーションは動作しなくなる可能性があります。

ロックダウンを使用するには、LSM が初期化され、ロックダウンモードが設定されている必要があります。

[[カーネル#公式サポートカーネル|公式にサポートされているカーネル]]は全て LSM を初期化しますが、ロックダウンモードを強制しません。

{{Tip|有効化されている LSM は {{ic|cat /sys/kernel/security/lsm}} を実行することで確認することができます。}}

ロックダウンには2つの動作モードがあります:

* {{ic|integrity}}: ユーザーランドが実行中のカーネルを変更できるカーネル機能 (kexec、bpf) は無効化されます。
* {{ic|confidentiality}}: ユーザーランドがカーネルから機密情報を抽出するためのカーネルの機能も無効化されます。

特定の脅威モデルで指示がない限り、{{ic|integrity}} を使用することが推奨されます。

実行時にカーネルのロックダウンを有効にするには、以下を実行してください:

# echo ''mode'' > /sys/kernel/security/lockdown

起動時にカーネルのロックダウンを有効にするには、{{ic|1=lockdown=''mode''}} [[カーネルパラメータ]]を使用してください:

{{Note|
* カーネルロックダウンを実行時に無効化することはできません。
* カーネルロックダウンは、[[ハイバネート]]を無効化します。
}}

{{man|7|kernel_lockdown}} も参照してください。

=== Linux Kernel Runtime Guard (LKRG) ===

[https://www.openwall.com/lkrg/ LKRG] ({{AUR|lkrg-dkms}}) は、カーネルの整合性チェックとエクスプロイト行為の検出を行うカーネルモジュールです。

== アプリケーションのサンドボックス化 ==

こちらも参照 [[Wikipedia:ja:サンドボックス (セキュリティ)]]

{{Note|ユーザー名前空間の設定項目 {{ic|CONFIG_USER_NS}} は、現在 {{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}}、および {{Pkg|linux-hardened}} で有効になっています。これが無効だと、一部のアプリケーションで特定のサンドボックス機能が利用できなくなる可能性があります。}}

{{Warning|非特権ユーザー名前空間の使用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) は、{{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}} でデフォルトで有効になっています。これにより、ローカル特権昇格の攻撃対象が大幅に拡大します([https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction AppArmorのWiki] および {{Bug|36969}} を参照。}}

これを軽減するためには、次のいずれかを行ってください:

* 安全なデフォルトを持つ {{Pkg|linux-hardened}} カーネルを使用する、または
* {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] を {{ic|0}} に設定する。

これにより、[[Zoom Meetings|Zoom]] や {{pkg|nsjail}} などのアプリケーションが動作しなくなる場合があることに注意してください。また、システムに {{pkg|bubblewrap}} がインストールされている場合は、{{pkg|bubblewrap-suid}} に置き換える必要があります。詳細は [[Bubblewrap#インストール]] を参照してください。

=== Firejail ===

[[Firejail]] は、アプリケーションやサーバーをサンドボックス化するための使いやすいツールです。元々はブラウザやインターネット向けアプリケーションのために作成されましたが、現在では多くのアプリケーションに対応しています。さまざまな機能を備えたサンドボックス環境を構築するために、suid バイナリとしてインストールされ、ブラックリストとホワイトリストに基づいてターゲットアプリケーションのサンドボックス化された実行環境を構築します。

=== bubblewrap ===

[[bubblewrap]] は、[[Flatpak]] などの非特権コンテナツール向けに開発されたサンドボックスアプリケーションで、Firejail よりもリソース消費と複雑さが大幅に小さいです。ファイルパスのホワイトリスト機能は欠けていますが、bubblewrap はバインドマウントのほか、ユーザー/IPC/PID/ ネットワーク /cgroup 名前空間の作成をサポートしており、シンプルなものから複雑なサンドボックスまで対応可能です。

[[Bubblejail]] サンドボックスは [[bubblewrap]] を基にしており、リソース指向の権限モデルと、権限を調整するためのグラフィカルインターフェースを提供します。

=== chroot ===

手動で [[chroot]] してサンドボックス化されたプロセス環境を作成できます。しかし、これは他のサンドボックス技術に比べて非常に制限されています。そのサンドボックス化の範囲はファイルパスの隔離に限られています。

=== Linux Containers ===

[[Linux Containers]] は、他のオプション([[#完全な仮想化オプション|完全な仮想化オプション]] を除く) よりも多くの隔離が必要な場合に適した選択肢です。LXC は、既存のカーネルの上で擬似 chroot 内で実行され、独自の仮想ハードウェアを持っています。

=== 完全な仮想化オプション ===

[[VirtualBox]]、[[KVM]]、[[Xen]]、または [https://www.qubes-os.org/ Qubes OS](Xen ベース)などの完全仮想化オプションを使用することで、リスクの高いアプリケーションを実行したり、危険なウェブサイトを閲覧したりする場合に、隔離とセキュリティを強化することができます。

==ネットワークとファイアウォール==

===ファイアウォール===

標準の Arch カーネルは [[Wikipedia:Netfilter|Netfilter]] の [[iptables]] および [[nftables]] を使用できますが、これらのサービスはデフォルトで [[有効化]] されていません。システム上で実行されているサービスを保護するために、何らかの形のファイアウォールを設定することを強く推奨します。多くのリソース(ArchWiki など)では、どのサービスを保護するべきかが明示的に記載されていないため、ファイアウォールを有効にすることは良い予防措置となります。

* 一般的な情報については [[iptables]] および [[nftables]] を参照してください。
* iptables ファイアウォールの設定方法については [[シンプルなステートフルファイアウォール]] を参照してください。
* netfilter の設定方法については [[ファイアウォール]] を参照してください。
* Bluetack などの IP アドレスリストをブロックするには [[Ipset]] を参照してください。
* {{Pkg|opensnitch}} は、アプリケーション、ポート、ホストなどによる設定可能なルールをサポートする、構成可能なインバウンドおよびアウトバウンドファイアウォールです。

==== ポートを開く ====

一部のサービスは、開かれたネットワークポートでインバウンドトラフィックを待ち受けます。これらのサービスは、必要最低限のアドレスとインターフェースにのみバインドすることが重要です。リモート攻撃者が [https://samy.pl/slipstream/ ネットワークプロトコルの欠陥を悪用して公開されたサービスにアクセスする] 可能性があります。これは、[https://nvd.nist.gov/vuln/detail/CVE-2019-13450 localhost にバインドされたプロセス] にも発生することがあります。

一般的に、サービスがローカルシステムのみでアクセス可能であれば、非ループバックアドレス(例えば {{ic|0.0.0.0/0}})ではなく、Unix ドメインソケット({{man|7|unix}})や {{ic|localhost}} のようなループバックアドレスにバインドするべきです。

サービスがネットワーク越しに他のシステムからアクセス可能である必要がある場合、厳格な [[ファイアウォール]] ルールでアクセスを制御し、可能な限り認証、認可、暗号化を構成することが重要です。

現在のすべてのオープンポートをリストするには、{{ic|ss -l}} を使用できます。すべてのリスニング中のプロセスとその数値的な TCP および UDP ポート番号を表示するには:

# ss -lpntu

その他のオプションについては、{{man|8|ss}}を参照してください。

===カーネルパラメータ===
ネットワークに影響を与えるカーネルパラメータは [[sysctl]] を使って設定できます。設定方法は [[sysctl#TCP/IP スタックの防御]] を見て下さい。

===SSH===
[[SSH 鍵#パスワードログインの無効化|SSH 鍵を必要]]としない [[Secure Shell]] を使うのは避けましょう。これは[[Wikipedia:ja:総当たり攻撃|総当たり攻撃]]を防ぎます。また、[[Fail2ban]] や [[Sshguard]] はログを監視して [[iptables|iptables ルール]]を書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。

二段階認証によって認証を強化することができます。[[Google Authenticator]] はワンタイムパスコード (OTP) を使用する二段階認証方式を提供します。

[[Secure Shell#root ログインを拒否する|root ログインを拒否する]]のは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。

===DNS===

[[DNSSEC]] や [[DNSCrypt]] を見て下さい。

=== プロキシ ===

プロキシはアプリケーションとネットワークの間に挟まる追加レイヤーとして使われ、信頼できないソースからのデータをサニタイズします。少ない権限でプロキシを動作させることで、エンドユーザー権限で複雑なアプリケーションを実行するよりも攻撃対象を小さくすることができます。

例えば {{Pkg|glibc}} の中に実装されている DNS リゾルバを考えてみてください。(root で実行することもある) アプリケーションにリンクされている DNS リゾルバにバグが存在した場合、リモートコード実行につながる危険があります。[[dnsmasq]] などの DNS キャッシュサーバーをインストールしてプロキシとして使うことで問題を防ぐことが可能です [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]。

=== SSL 証明書の管理 ===

サーバーサイドの SSL 証明書の管理については [[OpenSSL]] や [[Network Security Services]] (NSS) を参照してください。また、関連する [[Let’s Encrypt]] プロジェクトも見てください。

デフォルトのインターネット SSL 証明書のトラストチェーンは {{Pkg|ca-certificates}} パッケージによって提供されています。Arch はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: {{AUR|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) に依存しています。

デフォルトの証明書を変えたいと思うことがあるかもしれません。例えば、[http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ ニュース] を読んで証明書を信頼しないようにしたい場合 (ソースのプロバイダーによって無効になるのを待てない場合)、Arch のインフラを使うことで簡単に設定できます:
# {{ic|.crt}} 形式の証明書を入手してください (例: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; 既存のルート認証局の場合、システム内にあるはずです)。
# {{ic|/etc/ca-certificates/trust-source/blacklist/}} にコピーしてください。
# root で ''update-ca-trust'' を実行してください。

お好きなブラウザを開いて'''信頼できない'''サイトとして表示されれば、ブラックリストが上手く機能しています。

== 物理セキュリティ ==

{{Note|リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。}}

十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで''実用的で''高いレベルのセキュリティを得ることができます。

攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [http://www.breaknenter.org/projects/inception/]。これを防ぐためにできることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識がなく実行されることはほとんどありません。

[[#ディスク暗号化|ディスク暗号化]]はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。

===BIOS をロックダウンする===

BIOS にパスワードを追加することによってリムーバブルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。

=== ブートローダー ===

[[Arch ブートプロセス#ブートローダー|ブートローダー]] を保護することは非常に重要です。保護されていないブートローダは、例えば {{ic|1=init=/bin/sh}} を設定することでログインの制限を回避することができます。[[カーネルパラメータ]] でシェルに直接ブートするようにします。

==== Syslinux ====

Syslinux は[[Syslinux#セキュリティ|ブートローダーのパスワード保護]]をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。

==== GRUB ====

[[GRUB]] はブートローダのパスワードもサポートしています。詳しくは [[GRUB/ヒントとテクニック#GRUB メニューのパスワード保護|GRUB メニューのパスワード保護]] を参照してください。[[GRUB/ヒントとテクニック# GRUB メニューのパスワード保護|暗号化 /boot]] もサポートしていますが、これはブートローダコードの一部だけを暗号化しないままにしています。GRUB の設定、[[カーネル]]、[[initramfs]] は暗号化されています。

==== systemd-boot ====

[[systemd-boot]] は [[#セキュアブート]] が有効な場合、カーネルパラメータの編集を無効にします。代わりの方法として、[[systemd-boot#パスワードで保護されたカーネルパラメータエディタ]] を参照して下さい、より伝統的なパスワードベースのオプションを使用できます。

=== セキュアブート ===

[[セキュアブート]] は [[UEFI]] の機能で、コンピュータが起動するファイルの認証を可能にするものです。これは、起動パーティション内のファイルを置き換えるような、いくつかの [https://ja.wikipedia.org/wiki/%E6%82%AA%E6%84%8F%E3%81%82%E3%82%8B%E3%83%A1%E3%82%A4%E3%83%89%E6%94%BB%E6%92%83 悪意あるメイド攻撃] を防止するのに役立つ。通常、コンピュータにはベンダー (OEM) によって登録されたキーが付属しています。しかし、これを取り外して、コンピュータを「セットアップモード」にし、ユーザーが自分のキーを登録・管理できるようにすることができます。

セキュアブートのページでは、[https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Implementing_Secure_Boot using your own keys] によってセキュアブートを設定する方法を案内しています。

=== トラステッドプラットフォームモジュール(TPM) ===

[[Trusted Platform Module|TPM]] は、暗号鍵が埋め込まれたハードウェア・マイクロプロセッサです。これは、最近のほとんどのコンピュータの基本的な信頼性の根源を形成し、ブートチェーンのエンドツーエンドの検証を可能にします。内部スマートカードとして使用したり、コンピュータ上で動作するファームウェアを証明したり、改ざん防止とブルートフォース耐性のあるストアにユーザーがシークレットに挿入することができます。

=== リムーバブルフラッシュドライブ上のブートパーティション ===

ブートパーティションをフラッシュドライブに置き、それがないとシステムが起動しないようにする、というのはよくあるアイデアです。このアイデアの支持者はしばしば [[セキュリティ#ディスク暗号化|ディスク暗号化]] を併用し、ブートパーティションに置かれた [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USBdetached encryption headers] を使っている人もいます。

この方法は [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USB encrypting /boot] と統合することも可能です。

=== 自動ログアウト ===
[[Bash]] または [[Zsh]] を使っている場合、{{ic|TMOUT}} によってタイムアウトによるシェルからの自動ログアウトを設定できます。

例えば、以下は仮想コンソールから自動でログアウトします (X11 のターミナルエミュレータからはログアウトしません):

{{hc|/etc/profile.d/shell-timeout.sh|<nowiki>
TMOUT="$(( 60*10 ))";
[ -z "$DISPLAY" ] && export TMOUT;
case $( /usr/bin/tty ) in
/dev/tty[0-9]*) export TMOUT;;
esac
</nowiki>}}

(X のコンソールも含めて) 全ての Bash/Zsh プロンプトでタイムアウトさせたい場合は、次を使って下さい:

$ export TMOUT="$(( 60*10 ))";

シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや {{ic|TMOUT}} をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。

=== 不正なUSBデバイスから保護する ===

[[Usbguard]] は、デバイスの属性に基づく基本的なホワイトリストおよびブラックリスト機能を実装することで、不正な USB デバイス (別名 [https://ja.wikipedia.org/wiki/BadUSB BadUSB], [https://github.com/samyk/poisontap PoisonTap] または [https://lanturtle.com/ LanTurtle]) からコンピューターを保護できるソフトウェアフレームワークです。

=== 揮発性データの収集 ===

電源が入っているコンピュータは、[https://fedvte.usalearning.gov/courses/CSI/course/videos/pdf/CSI_D01_S05_T01_STEP.pdf volatile data collection] に対して脆弱である可能性があります。コンピュータの電源を入れる必要がない時や、コンピュータの物理的な安全性が一時的に損なわれる場合(例:セキュリティチェックポイントを通過する時)には、コンピュータの電源を完全に切ることがベストプラクティスです。

== パッケージ ==

=== パッケージの認証 ===
パッケージの署名が適正に使われていないと [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview パッケージマネージャへの攻撃] が考えられ、さらに [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html 適切な署名システム] を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは [[Pacman-key]] を見て下さい。

=== アップグレード ===

定期的に [[システムメンテナンス#システムのアップグレード|システムのアップグレード]] を行うことが重要です。

=== 脆弱性アラートの確認 ===

National Vulnerability Database が提供する Common Vulnerabilities and Exposure (CVE) Security Alert の更新を購読し、[https://nvd.nist.gov/download.cfm NVD Download webpage] で見つけてください。[https://security.archlinux.org/ Arch Linux Security Tracker] は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットを表形式でまとめた、特に有用なリソースです。ツール {{Pkg|arch-audit}} は実行中のシステムに影響を与える脆弱性をチェックするために使われます。グラフィカルなシステムトレイである {{Pkg|arch-audit-gtk}} も使うことができます。[https://wiki.archlinux.org/title/Arch_Security_Team Arch Security Team]も参照してください。

特にメインレポジトリや AUR 以外の手段でソフトウェアをインストールしている場合は、あなたが使っているソフトウェアのリリース通知を購読することも検討すべきです。いくつかのソフトウェアには、セキュリティに関する通知を受け取るために購読できるメーリングリストがあります。ソースコードホスティングサイトはしばしば新しいリリースの RSS フィードを提供しています。

=== パッケージの再ビルド ===

攻撃対象領域を減らす手段として、パッケージをリビルドし、不要な関数や機能を削除することができます。例えば、{{Pkg|bzip2}} は [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189] を回避するために {{ic|bzip2recover}} を使わずにリビルドすることが可能です。カスタムハードニングフラグは、手動またはラッパーを介して適用することもできます。

{| class="wikitable"
! フラグ !! 目的
|-
| -D_FORTIFY_SOURCE=2 || ランタイムバッファオーバーフローの検出
|-
| -D_GLIBCXX_ASSERTIONS || C++ の文字列とコンテナのランタイム境界チェック
|-
| -fasynchronous-unwind-tables || バックトレースの信頼性向上
|-
| -fexceptions || テーブルベースのスレッドキャンセルを有効にする
|-
| -fpie -Wl,-pie || 実行可能ファイルに対する完全な ASLR
|-
| -fpic -shared || 共有ライブラリのテキスト再配置を行わない
|-
| -fplugin=annobin || ハードニング品質管理用データの作成
|-
| -fstack-clash-protection || スタックオーバーフロー検出の信頼性向上
|-
| -fstack-protector or -fstack-protector-all || スタックスマッシュプロテクター
|-
| -fstack-protector-strong || 同様に
|-
| -g || デバッグ情報を生成する
|-
| -grecord-gcc-switches || デバッグ情報にコンパイラのフラグを格納する
|-
| -mcet -fcf-protection || 制御フローの完全性保護
|-
| -O2 || 推奨される最適化
|-
| -pipe || 一時ファイルを回避し、ビルドを高速化します。
|-
| -Wall || 推奨されるコンパイラの警告
|-
| -Werror=format-security || 安全でない可能性のあるフォーマット文字列の引数を拒否する
|-
| -Werror=implicit-function-declaration || 関数プロトタイプの欠落を却下する
|-
| -Wl,-z,defs || アンダーリンクの検出と拒否
|-
| -Wl,-z,now || 遅延バインディングを無効にする
|-
| -Wl,-z,relro || 移設後の読み出し専用セグメント
|}

* [https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/ Flags and info ソース]

== 参照 ==

* [https://security.archlinux.org/ Arch Linux セキュリティトラッカー]
* ArchWiki のセキュリティアプリケーションのリスト: [[アプリケーション一覧/セキュリティ]]
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux ワークステーションのセキュリティチェックリスト]
* [https://www.privacytools.io/ privacytools.io Privacy Resources]
* [https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/index.html Red Hat Enterprise Linux 7 セキュリティガイド]
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Debian 安全化マニュアル (PDF)]
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]

セキュリティ

2025-04-07T07:08:18Z

Oech3: SUIDバイナリとリンク/* SUID ファイルと SGID ファイル */

[[Category:セキュリティ]]
[[Category:ファイルシステム]]
[[Category:ネットワーク]]
[[en:Security]]
[[fa:امنیت]]
[[ru:Security]]
[[zh-hans:Security]]
{{Related articles start}}
{{Related|PAM}}
{{Related|ケイパビリティ}}
{{Related|アプリケーション一覧/セキュリティ}}
{{Related|:カテゴリ:セキュリティ}}
{{Related articles end}}
この記事には、Arch Linux システムを[[Wikipedia:ja:ハードニング|ハードニング]]するための推奨事項とベストプラクティスを並べています。

== 概念 ==

* システムのセキュリティを厳重にしすぎると、使い物にならなくなることもある。セキュリティと利便性のバランスを取ることが重要だ。重要なのは、安全で ''かつ'' 使いやすいシステムを作ること。
* 最大の脅威は常にユーザー自身である。
* [[Wikipedia:ja:最小権限の原則|最小権限の原則]]: システムの各部分は、必要最小限の権限のみを持つべきであり、それ以上のアクセスは許可されるべきではない。
* 多層防御 (Defense in Depth): セキュリティは独立した複数の層で成り立つべきである。一つの層が突破されても、次の層が攻撃を食い止める仕組みが必要です。
* 少しだけ疑い深くなること。常に警戒すること。うますぎる話には注意すべきだ。それが本当である可能性は低いと思うこと。
* システムを100%安全にする方法はただ一つ。それはネットワークから切り離し、電源を切り、金庫に入れ、コンクリートで固め、二度と使用しないこと。
* 失敗を想定せよ。セキュリティが破られたときに備え、あらかじめ対応策を準備しておくこと。

==パスワード==
パスワードは安全な linux システムのかぎです。パスワードは[[ユーザーとグループ|ユーザーアカウント]], [[ディスク暗号化|暗号化されたファイルシステム]], [[SSH 鍵|SSH]]/[[GPG]] 鍵などを守ります。コンピュータを使用する人を信頼するのに使う主要な手段なので、安全なパスワードを選んでそれを保護するというのがセキュリティの大部分と言っても過言ではありません。

=== 安全なパスワードの選び方 ===

パスワードは、個人情報などから簡単に推測されないよう十分に複雑であり、また、ソーシャルエンジニアリングやブルートフォース攻撃などの手法で[[Wikipedia:Password cracking|クラック]]されないようにする必要があります。強力なパスワードの基本原則は、''長さ''と''ランダム性''に基づいています。暗号学では、パスワードの品質はその[[Wikipedia:Password strength#Entropy as a measure of password strength|エントロピー]]によって測られます。

安全でないパスワードには、以下のようなものが含まれます。また、以下のようなものを元に変更や置き換えを行った場合も同様に危険です。

* 個人を特定できる情報(例:ペットの名前、生年月日、市外局番、好きなビデオゲームなど)
* 単純な文字の置き換えを行った単語(例:{{ic|k1araj0hns0n}})最新の辞書攻撃ではこれらも簡単に解析可能
* 既存の "単語" や一般的な文字列の前後に数字・記号・文字を追加したもの(例:{{ic|DG091101%}})
* 一般的なフレーズや辞書にある単語を短く組み合わせたもの(例:{{ic|photocopyhauntbranchexpose}})文字の置き換えを行っても(例:{{ic|Ph0toc0pyh4uN7br@nch3xp*se}})、安全とは限らない(ただし、後述の "Diceware" を利用した場合は例外あり)
* [[Wikipedia:List of the most common passwords|最も一般的なパスワード]]のいずれか

最も安全なパスワードは、十分に長く(長いほど良い)ランダムなソースから生成されたものです。長いパスワードを使用することが重要です。[https://www.theregister.com/2019/02/14/password_length 弱いハッシュアルゴリズムを使用すると、8文字のパスワードハッシュはわずか数時間で解読可能] です。

{{Pkg|pwgen}} や {{AUR|apg}} のようなツールを使用すると、ランダムなパスワードを生成できます。しかし、これらのパスワードは覚えにくいことがあります。覚えやすくするための1つの方法は、長いパスワードを生成し、最初は最低限の安全な文字数だけを暗記し、完全な文字列を一時的に書き留めることです。時間をかけて入力する文字数を増やしていけば、最終的にはパスワードが筋肉の記憶として定着し、完全に覚える必要がなくなります。この方法は難易度が高いものの、辞書攻撃や "知的" ブルートフォース攻撃(単語の組み合わせや文字の置き換えを考慮する攻撃)に対して非常に強力です。

パスワード管理とは別に、{{Pkg|keepassxc}} はパスワード/パスフレーズの生成機能を提供します。GUI でカスタマイズ可能なパスワード生成機能があり、辞書ベースのパスフレーズもサポートされています。

パスワードを覚えるための1つの方法として、**記憶術(ニーモニック)**を利用することが挙げられます。
例えば、"the girl is walking down the rainy street" というフレーズは、以下のようなパスワードに変換できます。簡単な例:{{ic|t6!WdtR5}} より複雑な例:{{ic|t&6!RrlW@dtR,57}}
この方法は、パスワードを覚えやすくすることができますが、英単語の最初の文字には偏りがあることに注意が必要です([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]] を参照)

また、ランダムに生成したパスワードを紙に書いて安全な場所に保管するという方法も有効です。例えば、財布、カバン、金庫などに保管するのがよいでしょう。ほとんどの人は、デジタルセキュリティよりも物理的な貴重品の保護に関しては理解しやすいため、この方法は現実的です。

さらに、記憶術とランダム生成を組み合わせる方法も効果的です。例えば、長くランダムに生成したパスワードを[[パスワードマネージャ]]に保存し、それをマスターパスワードで管理する方法です。マスターパスワードは記憶し、絶対に保存しないようにします。この方法では、パスワードマネージャーがインストールされているシステムでのみパスワードにアクセスできるようになり、状況によっては不便にもなりますが、セキュリティ強化の側面もあります。一部のパスワードマネージャーにはスマートフォンアプリもあり、手入力が必要な場合にパスワードを表示することができます(この場合、完全にランダムなものではなく、タイピングしやすいが安全なパスワードを使うことも検討できます)ただし、マスターパスワードを忘れるとすべてのパスワードにアクセスできなくなるため、単一障害点になり得ることに注意が必要です。
また、一部のパスワードマネージャーは、保存するパスワードを暗号化するのではなく、マスターパスワードとサービス名から計算する方式を採用しており、新しいシステムでもデータ同期なしで使用できます。

覚えやすく、それでいて強力なパスワードの作成方法として、無関係な単語を複数組み合わせたパスフレーズを使うという方法もあります。この方法では、十分に長いフレーズを使用することで、辞書単語を使うことによるエントロピーの損失を補うことができます。この手法のエントロピーのトレードオフについては、[https://xkcd.com/936/ xkcdのコミック] に示されています。この方法の安全性は、選択可能な単語の集合が大きい(数千語以上)ことと、5〜7語以上のランダムな単語を選択することによって保証されます。攻撃者が選択可能な単語の集合と、使用する単語数を知っていたとしても、(選択可能な単語数) の (選択する単語数) 乗の通りのパスフレーズが生成可能であり、安全性が確保されます。詳細については [https://www.rempe.us/diceware/ Diceware] を参照してください。

さらに詳しい情報については、[https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] や [[Wikipedia:Password strength]] も参考になります。

=== パスワードの管理 ===

強力なパスワードを選んだら、それを安全に保管することが重要です。[[Wikipedia:Keylogger|キーロガー]] (ソフトウェアおよびハードウェア)、スクリーンロガー、[[Wikipedia:Social engineering (security)|ソーシャルエンジニアリング]]、[[Wikipedia:Shoulder surfing (computer security)|ショルダースーフィング]]に注意し、パスワードの使い回しを避けて、セキュリティの低いサーバーから不要な情報が漏れないようにしましょう。[[アプリケーション一覧/セキュリティ#パスワードマネージャ|パスワードマネージャ]]を使用すると、大量の複雑なパスワードを管理できます。パスワードマネージャーからアプリケーションに保存されたパスワードをコピー&ペーストして使用する場合は、毎回コピーした内容をクリアし、ログに保存されないようにしてください(例:プレーンテキストのターミナルコマンドにペーストしないようにし、{{ic|.bash_history}} などのファイルに保存されないようにします)ブラウザ拡張として実装されたパスワードマネージャは、[https://www.spookjs.com サイドチャネル攻撃]に脆弱である可能性があります。これを回避するためには、別のアプリケーションとして実行されるパスワードマネージャーを使用することが推奨されます。

原則として、強力なパスワードを覚えにくいからといって、セキュリティが低いパスワードを選んではいけません。パスワードはバランスを取る必要があります。強力なマスターパスワードと鍵で守られた暗号化された安全なパスワードデータベースを持つ方が、多くの似たような弱いパスワードを使うよりも優れています。パスワードを紙に書いて保管することも、[https://www.schneier.com/blog/archives/2005/06/write_down_your.html] で示されているように、ソフトウェアの脆弱性を避けつつ物理的なセキュリティを確保できるため、非常に効果的です。

パスフレーズの強度のもう一つの側面は、それが他の場所から簡単に回復できないことです。

ディスク暗号化のパスフレーズをログインパスワードと同じに使用する場合(例えば、ログイン時に暗号化されたパーティションやフォルダを自動マウントする場合)、{{ic|/etc/shadow}} が暗号化されたパーティションに保存されるか、または強力な鍵導出関数 (i.e. yescrypt/argon2 や sha512 を PBKDF2 で使用、md5 や低回数の PBKDF2 は避ける) を使用して保存されたパスワードハッシュを使うようにしてください (詳細については [[SHA hashes#SHA パスワードハッシュ|SHA パスワードハッシュ]] を参照してください)

{{Tip|Arch Linux は [https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのハッシュアルゴリズム]を yescrypt に変更しました。もしデフォルトをカスタマイズしていない場合は、{{ic|passwd}} を実行してパスワード変更を行うなどして下さい。}}

パスワードデータベースをバックアップする場合、そのコピーが他のパスフレーズで保護されていないことを確認してください。例えば、暗号化されたドライブや認証されたリモートストレージサービスなどです。もしそのような保護が施されている場合、必要なときにアクセスできなくなります。役立つ方法としては、データベースがバックアップされているドライブやアカウントをマスターパスワードの簡単な暗号学的ハッシュで保護することです。バックアップ場所のリストを保持してください。もしもマスターパスワードが漏洩したと疑われる場合、その場所すべてでパスワードを即座に変更し、マスターパスワードから導出された鍵で保護されたすべてのバックアップと場所も変更する必要があります。

データベースをセキュアにバージョン管理するのは非常に複雑な場合があります。もしその方法を選択するなら、すべてのデータベースバージョンでマスターパスワードを更新する手段を持っている必要があります。マスターパスワードが漏洩したときにそれを即座に知るのは難しいことがあります。他の人がパスワードを発見するリスクを減らすために、定期的にパスワードを変更することを選ぶかもしれません。もしデータベースのコピーの管理が失われたと感じた場合、そのコピーがブルートフォース攻撃によってマスターパスワードを解読される前に、そのデータベース内のすべてのパスワードを変更する必要があります。

=== パスワードのハッシュ ===

ハッシュは一方向の関数です。つまり、入力を計算せずにそのハッシュを解読することは不可能になるように設計されています (例:MD5、SHA)

パスワードハッシュ関数は、ユーザー入力 (パスワード) を計算せずに解読することが不可能になるように設計されています(例:bcrypt)[[Wikipedia:Key derivation function|鍵導出関数]] (KDF; 例:yescrypt、scrypt、PBKDF2) は、入力 (マスターキーやパスワード) から秘密鍵 (例:AESキー、パスワードハッシュ) を導出するために設計された暗号アルゴリズムです。したがって、KDF はパスワードハッシュ関数としても使用できる複数の用途に対応します。

デフォルトでは、Arch Linux はユーザーパスワードをルート専用の読み取り可能な {{ic|/etc/shadow}} ファイルにハッシュ化して保存します。これは、他のユーザーのパラメータが保存される世界に読み取り可能な {{ic|/etc/passwd}} ファイルから分離されています。詳細は [[ユーザーとグループ#ユーザーデータベース]] を参照してください。また、[[#root の制限]] も参照してください。

パスワードは '''passwd''' コマンドを使用して設定され、このコマンドはシステムの暗号化関数でパスワードを[[Wikipedia:Key stretching|ストレッチ]]し、その後 {{ic|/etc/shadow}} に保存されます。パスワードは[[Wikipedia:Salt (cryptography)|ソルト]]も施され、[[Wikipedia:Rainbow table|レインボーテーブル]]攻撃に対して防御されます。詳細は[https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils Linux でパスワードがどのように保存されているか(Shadow ユーティリティを使ったハッシュの理解)]を参照してください。

パスワードハッシュは定義されたフォーマットに従って保存されるため、新たな ''passwd'' コマンドの実行に対してメソッドとパラメータを設定することができます。したがって、{{ic|/etc/shadow}} ファイルに保存された個々のハッシュは、システムでサポートされているハッシュ関数の異種混合になる可能性があります。

フォーマット、ハッシュメソッド、およびパラメータに関する詳細は、{{man|5|crypt}} を参照してください。

{{ic|/etc/login.defs}} ファイルでは、[https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのパスワードハッシュメソッド]{{ic|ENCRYPT_METHOD YESCRYPT}} とそのパラメータ {{ic|YESCRYPT_COST_FACTOR}} が設定されます。

例えば、デフォルトの {{ic|YESCRYPT_COST_FACTOR}} パラメータを増加させると、パスワードからハッシュを導き出すために必要な計算時間が対数的に増加します。これは、システムがユーザーのログインを認証する際や、第三者がパスワードの秘密を取得しようとする場合にも適用されます。

これに対して、SHA-512 ハッシュ関数の計算時間は、パラメータにより線形的に影響されます。以前の Arch のデフォルトについては [[SHA パスワードハッシュ]] を参照してください。yescrypt アルゴリズムは内部で SHA-256、HMAC、およびPBKDF2 を使用してパスワードハッシュを計算することに注意してください。主な理由は、これらの広く使用され、テストされた関数の良い特性を組み合わせ、攻撃への耐性を強化することです。例えば、SHA の多用途性が原因で、この関数のハードウェアサポートが提供され、SHA ハッシュの計算性能が著しく向上したため、パスワードハッシュ関数としての使用が次第に時代遅れになりつつあります。

=== pam_cracklib を用いた強力なパスワードの強制 ===

''pam_pwquality'' は、[[Wikipedia:Dictionary attack|辞書攻撃]]に対する保護を提供し、システム全体で強制できるパスワードポリシーを設定するのに役立ちます。これは ''pam_cracklib'' をベースにしており、そのオプションとの後方互換性があります。

{{Pkg|libpwquality}} パッケージを[[インストール]]してください。

{{Warning|デフォルトでは、''root'' アカウントはこのポリシーの影響を受けません。}}

{{Note|
* ''root'' アカウントを使用すると、設定したパスワードポリシーをバイパスするユーザーパスワードを設定できます。これは一時的なパスワードを設定する際に便利です。
* 現在のパスワードに関するセキュリティガイドライン(例:NISTなど)では、特別な文字を強制することは推奨されていません。なぜなら、それらはしばしば予測可能な変更を引き起こすだけだからです。
}}

例えば、以下のポリシーを強制したい場合:

* エラーが発生した場合にパスワードを2回入力する (retry オプション)
* 最小長10文字 (minlen オプション)
* 新しいパスワードを入力する際、古いパスワードとは少なくとも6文字異なること (difok オプション)
* 最低1桁の数字 (dcredit オプション)
* 最低1つの大文字 (ucredit オプション)
* 最低1つの小文字 (lcredit オプション)
* 最低1つのその他の文字 (ocredit オプション)
* "myservice" および "mydomain" という単語を含めない
* root にもこのポリシーを強制する

{{ic|/etc/pam.d/passwd}}ファイルを以下のように編集します:

{{bc|1=
#%PAM-1.0
password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root
password required pam_unix.so use_authtok sha512 shadow
}}

{{ic|password required pam_unix.so use_authtok}} は、''pam_unix'' モジュールに対してパスワードの入力を促さず、代わりに ''pam_pwquality'' で提供されたものを使用するように指示します。

詳細については、{{man|8|pam_pwquality}} および {{man|8|pam_unix}} のマニュアルページを参照してください。

== CPU ==

=== マイクロコード ===

CPU のマイクロコードに対する重要なセキュリティ更新プログラムをインストールする方法については、[[マイクロコード]] を参照してください。

=== ハードウェアの脆弱性 ===

CPU の中には、ハードウェアの脆弱性を含んでいるものがあります。これらの脆弱性の一覧と、特定の使用シナリオに合わせてこれらの脆弱性を緩和するためにカーネルをカスタマイズするのに役立つ緩和策の選択ガイドについては、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/ kernel documentation on hardware vulnerabilities] を参照してください。

既知の脆弱性の影響を受けているかどうかを確認するには、以下を実行してください。

$ grep -r . /sys/devices/system/cpu/vulnerabilities/

ほとんどの場合、カーネルとマイクロコードを更新することで、脆弱性を軽減することができます。

==== 同時マルチスレッディング (ハイパースレッディング) ====

[https://ja.wikipedia.org/wiki/%E5%90%8C%E6%99%82%E3%83%9E%E3%83%AB%E3%83%81%E3%82%B9%E3%83%AC%E3%83%83%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0 同時マルチスレッディング]] (SMT) は、インテル CPU のハイパースレッディングとも呼ばれ、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html L1 Terminal Fault] および [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html Microarchitectural Data Sampling] 脆弱性の原因となる可能性のあるハードウェア機能です。Linux カーネルとマイクロコードのアップデートには、既知の脆弱性に対する緩和策が含まれていますが、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html#virtualization-with-untrusted-guests 信頼できない仮想化ゲストが存在する場合、特定の CPU で SMT を無効にしたほうが良い場合があります。]

SMT は、システムのファームウェアで無効にできることがよくあります。詳細については、マザーボードまたはシステムのドキュメントを参照してください。また、以下の [[カーネルパラメータ]] を追加することで、カーネルで SMT を無効にすることができます。

l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force

== メモリ ==

===ハード化された malloc ===

[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened_malloc}}, {{AUR|hardened-malloc-git}}) は [https://ja.wikipedia.org/wiki/GNU_C%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA glibc] の malloc() をハード化した代替品です。元々は Android の [[Wikipedia:Bionic (software)|Bionic]] と [https://ja.wikipedia.org/wiki/Musl musl] に組み込むために開発されましたが、 x86_64 アーキテクチャの標準 Linux ディストリビューションのサポートにも組み込みました。

hardened_malloc はまだ glibc に統合されていませんが(支援とプルリクエストは歓迎します)、LD_PRELOAD と一緒に簡単に使用することができます。これまでのテストでは、 {{ic|/etc/ld.so.preload}} でグローバルに有効にすると、一握りのアプリケーションにしか問題を起こしません。例えば、{{ic|getrandom}} が標準のホワイトリストにないため、{{ic|seccomp}} 環境フラグが無効でないと {{ic|man}} は正常に動作しませんが、これはシステムコールを追加して再構築すれば簡単に修正可能です。hardened_malloc は性能上のコストがあるので、どの実装を使うかは攻撃対象領域と性能上の必要性に基づいてケースバイケースで決めるとよいでしょう。

スタンドアロンで試すには、hardened-malloc-preload ラッパースクリプトを使用するか、適切なプリロード値でアプリケーションを手動で開始します。

LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox

[[Firejail]] の正しい使い方は、その wiki ページにあります。また、hardened_malloc の設定可能なビルドオプションは、githubレポで見つけることができます。

== ストレージ ==

===ディスク暗号化===

[[ディスク暗号化]]、特に [[#パスワード|強力なパスフレーズ]] を使用したフルディスク暗号化は、物理的な回復からデータを守る唯一の方法です。これにより、コンピュータの電源がオフになっている場合や、対象のディスクがアンマウントされている場合にデータの機密性が保たれます。

ただし、コンピュータの電源が入っており、ドライブがマウントされている場合、そのデータは暗号化されていないドライブと同様に脆弱です。そのため、データパーティションがもう必要なくなったら、できるだけ早くアンマウントすることが最良の実践です。

また、[[Trusted Platform Module#LUKS による保存データの暗号化|TPMにキーを保存してドライブを暗号化]] することもできますが、過去に [https://tpm.fail 脆弱性] があり、キーは [https://pulsesecurity.co.nz/articles/TPM-sniffing TPMバススニッフィング攻撃] によって抽出される可能性があります。

[[dm-crypt]] のような特定のプログラムは、ユーザーが仮想ボリュームとしてループファイルを暗号化できるようにします。これは、システムの特定の部分だけを安全に保護する必要がある場合、フルディスク暗号化の合理的な代替手段です。

[[ディスク暗号化]] の記事で比較されているブロックデバイスやファイルシステムベースの暗号化方法は、物理メディア上のデータ保護には有効ですが、リモートシステム(例えば [[保存データ暗号化#クラウドストレージの最適化|クラウドストレージ]])に保存されたデータを保護するためには使用できません。そのため、個々のファイル暗号化が役立つ場合もあります。

ファイルを暗号化するためのいくつかの方法は次の通りです:

* 一部の [[アーカイブと圧縮|アーカイブおよび圧縮]] ツールは基本的な暗号化も提供します。例としては、[[7-Zip]] ({{ic|-p}} フラグ)、{{Pkg|zip}} ({{ic|-e}}フラグ) があります。これらのツールはクロスプラットフォームの互換性のためにカスタムアルゴリズムを使用している場合があるため、特別な注意を払って使用するべきです。[https://math.ucr.edu/~mike/zipattacks.pdf]
* [[GnuPG]] を使用してファイルを [[GnuPG#Encrypt and decrypt|暗号化]] できます。
* {{Pkg|age}} は、シンプルで使いやすいファイル暗号化ツールです。複数の受信者をサポートしており、SSH キーを使用した暗号化もサポートしているため、安全なファイル共有に役立ちます。

=== ファイルシステム ===

現在カーネルは {{ic|fs.protected_hardlinks}} や {{ic|fs.protected_symlinks}} sysctl スイッチが有効になっていればハードリンクやシンボリックリンクに関するセキュリティの問題を解決するので、world-writable なディレクトリを分離させるセキュリティ的な利点はもはや存在しません。

それでもディスク容量が消耗したときのダメージを低減させる荒っぽい方法として world-writable なディレクトリを含むパーティションが分割されることがあります。しかしながら、サービスを落とすには {{ic|/var}} や {{ic|/tmp}} などのパーティションを一杯にするだけで十分です。この問題の対処についてはもっと柔軟性のある方法が存在します (クォータなど)、またファイルシステムによっては関連する機能を持っていることがあります (btrfs はサブボリュームにクォータを設定できます)。

====マウントオプション====

最小特権の原則に従い、ファイルシステムは可能な限り制限の厳しいマウントオプションを使用してマウントするべきです(機能を失わない範囲で)

関連するマウントオプションは以下の通りです:

* {{ic|nodev}}: ファイルシステム上のキャラクタデバイスやブロックデバイスを解釈しない。
* {{ic|nosuid}}: set-user-identifier や set-group-identifier ビットを無効にする。
* {{ic|noexec}}: マウントされたファイルシステム上のバイナリを直接実行できないようにする。
** {{ic|/home}} に {{ic|noexec}} を設定すると、実行可能なスクリプトが禁止され、[[Wine]]、[[Steam]]、PyCharm、[[.NET]] などが動作しなくなります。
*** Wine は Windows バイナリの実行に {{ic|exec}} フラグを必要としません。ただし、Wine 自体を {{ic|/home}} にインストールする場合は必要です。
*** [[Steam]] を動作させるには、{{ic|/home/user/.local/share/Steam}} を [[fstab]] で {{ic|exec}} としてマウントできます。以下の設定を追加してください: {{bc|/home/user/.local/share/Steam /home/user/.local/share/Steam none defaults,bind,user,exec,nofail 0 0}}
** 一部のパッケージ(例:{{Pkg|nvidia-dkms}} のビルド)では、{{ic|/var}} に {{ic|exec}} が必要な場合があります。

データ用のファイルシステムは、常に {{ic|nodev}}、{{ic|nosuid}}、{{ic|noexec}} を指定してマウントするべきです。

マウントを検討すべきファイルシステム:

* {{ic|/var}}
* {{ic|/home}}
* {{ic|/dev/shm}}
* {{ic|/tmp}}
* {{ic|/boot}}

{{Tip|[[systemd#GPT パーティションの自動マウント|GPT パーティションの自動マウント]] を使用する場合、ESP および XBOOTLDR パーティションは [https://github.com/systemd/systemd-stable/commit/49804cfb71d3a79f433096e4cfb5616980171336 常に {{ic|noexec,nosuid,nodev}} で強化] されます。}}

==== スナップショット ====

ファイルシステムのスナップショットを利用する場合(例えば [[Btrfs]]、[[LVM]]、[[ZFS]] など)、スナップショットがユーザーが削除したと期待している機密情報を保持する可能性があることを理解することが重要です。特に、[[Snapper]] のような自動スナップショットツールを設定している場合、定期的またはシステムイベントに応じてスナップショットが作成されるため、この問題が発生しやすくなります。

以下は、{{ic|/home/}} 内の機密情報がスナップショットに残存する例です:

* 削除されたファイルやディレクトリ: ファイルシステム上から削除されたとしても、古いスナップショット内には残存している可能性があります。これは通常想定される動作ですが、{{ic|.local/share/Trash/}}、{{ic|.history}} などのファイルやディレクトリを保持する必要があるかどうかを検討すべきです。
* 一時ファイルやキャッシュ: アプリケーションによって生成された一時ファイルやキャッシュデータもスナップショットに含まれる可能性があります。例えば、暗号化されたディレクトリ内のファイルを開くと、サムネイル({{ic|.cache/thumbnails}})や作業用のコピーが作成され、それらがスナップショットに含まれる可能性があります。同様に、ブラウザの履歴({{ic|.mozilla/}}、{{ic|.config/chromium/}} など)も、削除される前にスナップショットに記録されている場合があります。

対応可能であれば、これらのディレクトリをスナップショットの対象から完全に除外することを検討してください。例えば、[[Btrfs]] を使用している場合、{{ic|.cache/}}、{{ic|.config/}}、{{ic|.local/}}、{{ic|.var/}} など、用途に応じたディレクトリをサブボリュームとして作成することで、スナップショットの影響を受けにくくできます。

{{Note|{{ic|.local/share/Trash}} を別のサブボリュームに移動すると、場合によっては [[GNOME/Files]] などでゴミ箱の機能が正常に動作しなくなる可能性があります。}}

===ファイルシステムのパーミッション===

デフォルトの [[パーミッション]] では、ほとんどのファイルが読み取り可能になっていますが、これを変更することで、{{ic|http}} ユーザーや {{ic|nobody}} ユーザーなどの非 root アカウントに侵入した攻撃者から貴重な情報を隠すことができます。[[chmod]] を使用して、グループやその他のユーザーからすべてのアクセス権を削除できます。

# chmod go-r ''path_to_hide''

{{Warning|この設定を広範囲に適用しないでください。1つの設定ファイルごとに適用し、非表示にする価値があるか、プログラムの動作に影響しないかを確認してください。グループが必要な場合は、{{ic|g}} をコマンドから削除するか、既に実行してしまった場合は {{ic|chmod g+r path}} で再度許可を追加する必要があるかもしれません。}}

考慮すべきパスの例:

* {{ic|/boot}}: [[パーティショニング#/boot|ブートディレクトリ]]、[[vmlinuz]] や [[initramfs]] image、または [[ユニファイドカーネルイメージ]] が含まれる場合があります。なお、[[systemd# GPT パーティションの自動マウント]] を使用する場合、デフォルトで安全なパーミッションが適用されます。
* {{ic|/etc/nftables.conf}}: [[nftables]] の設定ファイル({{Pkg|nftables}} および {{Pkg|iptables-nft}} に適用)
* {{ic|/etc/iptables}}: レガシーな [[iptables]] の設定ファイル({{Pkg|iptables}} に適用)

また、新しく作成されるファイルのセキュリティを向上させるために、デフォルトの [[umask]] 値 {{ic|0022}} を変更することも可能です。[https://apps.nsa.gov/iaarchive/library/ia-guidance/security-configuration/operating-systems/guide-to-the-secure-configuration-of-red-hat-enterprise.cfm NSA RHEL5 Security Guide] では最大限のセキュリティを確保するために、{{ic|0077}} を推奨しており、これにより所有者以外のユーザーが新しいファイルを読み取れなくなります。変更方法については [[Umask#マスクの値を設定]] を参照してください。

さらに、[[sudo]] を使用する場合、[[Sudo#Permissive umask|デフォルトの root umask]] を適用するよう設定することを検討してください。

=== SUID ファイルと SGID ファイル ===

[[Wikipedia:ja:Setuid|Setuid]] ビットや Setgid ビットが設定されたファイルには注意しましょう。このようなファイルの例としては、以下があります。

* [[PAM|unix_chkpwd]]
* chage expiry gpasswd groupmems [[passwd]] ({{Pkg|shadow}} パッケージ)
* [[FUSE|fusermount3]]
* pkexec polkit-agent-helper-1 ([[polkit]] パッケージ)
* [[OpenSSH|ssh-keysign]]
* chfn chsh mount newgrp umount wall write ({{Pkg|util-linux}} パッケージ)
* [[sudo]] [[doas]] [[su]] [[Kerberos|ksu]]
* [[firejail]]
* [[Dbus|dbus-daemon-launch-helper]]
* [[Chromium|chromium-sandbox]]

このような実行ファイルの主なリスクとして、特権昇格の脆弱性があります。例えば [[Wikipedia:Setuid#Security impact]] を参照してください。[https://www.cvedetails.com/vulnerability-list/vendor_id-16224/product_id-36412/Calibre-ebook-Calibre.html][https://www.cvedetails.com/product/32625/Sudo-Project-Sudo.html?vendor_id=15714][https://www.cvedetails.com/vulnerability-list/vendor_id-16191/Firejail-Project.html]

SUID ビットが設定されているが root によって所有されていないファイル、または SGID ビットが設定されているファイルは、''典型的には''潜在的なリスクがより小さいですが、理論上、そのようなファイルに脆弱性が存在している場合は、依然として損害を与える可能性があります。通常、代わりに[[ケイパビリティ]]を割り当てることによって、Setuid や Setgid の使用を回避することが可能です。

{{Tip|SUID/SGID 実行ファイルを含むパッケージを最新に保って、脆弱性からシステムを守ることが肝心です。}}

SUID ビットか SGID ビットを持つファイルを {{ic|/usr/bin}} から探すには:

$ find /usr/bin -perm "/u=s,g=s"

== ユーザー設定 ==

=== root アカウントを日常的に使用しない ===

最小特権の原則に従い、root ユーザーを日常的に使用しないようにしてください。システムを使用する各人に非特権ユーザーアカウントを作成するか。一時的な特権アクセスには、必要に応じて [[sudo]] を使用する。

=== ログイン失敗後の遅延時間の設定 ===

以下の行を {{ic|/etc/pam.d/system-login}} に追加し、ログインに失敗した際に最低4秒の遅延を追加します。

{{hc|/etc/pam.d/system-login|2=
auth optional pam_faildelay.so delay=4000000
}}

{{ic|4000000}} は遅延させる時間をマイクロ秒単位で指定します。

===3回ログインを失敗したユーザーをロックアウトする===

{{Pkg|pambase}} 20200721.1-2 の時点では、デフォルトで {{ic|pam_faillock.so}} が有効になっており、15分間に3回ログインに失敗すると10分間ユーザをロックアウトします ({{Bug|67644}} を参照してください) このロックアウトはパスワード認証 (例:ログインと ''sudo'') にのみ適用され、SSH 経由の公開鍵認証はそのまま利用可能です。完全なサービス拒否を防ぐために、このロックアウトは root では無効になっています。

ユーザーをロック解除するには、次のようにします。

$ faillock --reset --user ''username''

デフォルトでは、ロック機構は {{ic|/run/faillock/}} にあるユーザーごとのファイルです。ディレクトリの所有者は root ですが、ファイルの所有者はユーザーなので、 {{ic|faillock}} コマンドはファイルを空にするだけで、root は必要ありません。

モジュール {{ic|pam_faillock.so}} は、ファイル {{ic|1=/etc/security/faillock.conf}} で設定することが可能です。ロックアウトのパラメータです。

* {{ic|unlock_time}} - ロックアウト時間 (秒単位、デフォルトは10分)
* {{ic|fail_interval}} - ロックアウトに失敗するとロックアウトされる時間 (秒単位、デフォルトは15分)
* {{ic|deny}} - ロックアウトするまでに何回ログインに失敗するか (デフォルトは 3)

{{Note|{{ic|1=deny = 0}} はロックアウトを無効化します}}

デフォルトでは、すべてのユーザーロックは再起動後に失われます。攻撃者がマシンをリブートできるのであれば、ロックは持続させた方が安全です。ロックを持続させるには、{{ic|1=/etc/security/faillock.conf}} の {{ic|dir}} パラメータを {{ic|/var/lib/faillock}} に変更する必要があります。

変更を反映させるために再起動する必要はありません。root アカウントのロックアウトを有効にする、集中ログイン (LDAP など) を無効にするなど、さらなる設定オプションについては {{man|5|faillock.conf}} を参照してください。

=== プロセスの数を制限する ===

信頼できないユーザーが大量に存在するシステムでは、一度に実行できるプロセスの数を制限して、[[Wikipedia:ja:Fork爆弾|フォーク爆弾]]などのサービス拒否攻撃を予防することが重要です。ユーザーやグループごとに実行できるプロセスの数は {{ic|/etc/security/limits.conf}} で定義することができ、デフォルトでは空になっています。以下の値をファイルに追加すると、実行できるプロセスが100個までに制限されます。{{ic|prlimit}} コマンドを使って一時的に上げられる最大数も200個までに制限します。ユーザーが普段実行するプロセスの数や、管理するハードウェアにあわせて適切な値に変更してください。

* soft nproc 100
* hard nproc 200

=== Wayland を使用する ===

[[Xorg]] よりも [[Wayland]] を使用することをお勧めします。Xorg の設計は現代のセキュリティ慣行より古く、多くの人が [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 は安全でないと考えています] 例えば、Xorg のアプリケーションは非アクティブな状態でもキーストロークを記録することがあります。

もし Xorg を実行しなければならないなら、[[Xorg#Rootless_Xorg|root での実行を避ける]]ことが推奨されます。Wayland 内では、XWayland 互換レイヤーは自動的に root レス Xorg を使用します。

== root の制限 ==
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。

=== su の代わりに sudo を使う ===
[[Su#セキュリティ|色々な理由]]から特権アクセスには [[su]] よりも [[sudo]] を使うほうが好ましいとされます。

* 通常の権限しか持たないユーザーが実行した特権コマンドのログを保持します。
* root アクセスを必要とする各ユーザーに root ユーザーのパスワードを与える必要がありません。
* 完全な root ターミナルは作成されないため、{{ic|sudo}} は root アクセスが必要ないコマンドを偶発的に ''root'' で実行してしまうことを防止します。これは[[Wikipedia:ja:最小権限の原則|最小権限の原則]]と合っています。
* 一つのコマンドを実行するためだけに完全な root アクセスを与える代わりに、ユーザーごとに個々のプログラムを有効にすることができます。例えば、ユーザー ''alice'' に特定のプログラムへのアクセス権限を与えるには:

# visudo

{{hc|/etc/sudoers|
alice ALL = NOPASSWD: /path/to/program}}

また、全てのユーザーに個別のコマンドを許可することも可能です。通常ユーザーでサーバーから Samba 共有をマウントするには:

%users ALL=/sbin/mount.cifs,/sbin/umount.cifs

これによって users グループのメンバーである全てのユーザーが全てのマシン (ALL) から {{ic|/sbin/mount.cifs}} や {{ic|/sbin/umount.cifs}} コマンドを実行できるようになります。

{{Tip|{{ic|visudo}} で {{ic|vi}} の代わりに {{ic|nano}} を使うには:

{{hc|/etc/sudoers|
2=Defaults editor=/usr/bin/rnano
}}
{{ic|1=# EDITOR=nano visudo}} のエクスポートは何にでも {{ic|EDITOR}} として使うことができるためにセキュリティリスクとされています。
}}

==== sudo を使ってファイルを編集する ====
root で {{ic|vim}} などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:

export SUDO_EDITOR=rvim

ファイルの編集には {{ic|sudoedit filename}} または {{ic|sudo -e filename}} を使って下さい。自動的に {{ic|rvim}} によって {{ic|filename}} が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。

=== root ログインの制限 ===
[[sudo]] を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。[[sudo]] を使える状態のまま root を無効化したい場合、{{ic|passwd -l root}} を使用します。

==== 特定のユーザーだけに許可を与える ====
[[Wikipedia:Pluggable authentication module|PAM]] の {{ic|pam_wheel.so}} は {{ic|wheel}} グループに入っているユーザーだけに {{ic|su}} を使用したログインを許可します。{{ic|/etc/pam.d/su}} と {{ic|/etc/pam.d/su-l}} の両方を編集して次の行をアンコメントしてください:
{{bc|<nowiki>
# Uncomment the following line to require a user to be in the "wheel" group.
auth required pam_wheel.so use_uid
</nowiki>}}
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。

==== ssh ログインを拒否する ====
ローカルユーザーの root ログインを拒否したくない場合でも、[[SSH#root ログインを拒否する|SSH による root ログインを拒否]]するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。

==== access.conf で許容されるログインの組み合わせを指定する ====

誰かが [[PAM]] でログインしようとすると、 {{ic|/etc/security/access.conf}} がそのログインプロパティに一致する最初の組み合わせをチェックします。そして、その組み合わせのルールに基づいて、試行が失敗するか成功するかが決まります。

+:root:LOCAL
-:root:ALL

特定のグループやユーザーに対してルールを設定することができます。この例では、ユーザー archie は、wheel および adm グループに属するすべてのユーザーと同様に、ローカルでのログインを許可されています。それ以外のログインは拒否されます。

+:archie:LOCAL
+:(wheel):LOCAL
+:(adm):LOCAL
-:ALL:ALL

詳しくは {{man|5|access.conf}} で確認してください。

==強制アクセス制御==

[[Wikipedia:ja:強制アクセス制御|強制アクセス制御]] (Mandatory Access Control, MAC) は Arch やほとんどの Linux ディストリビューションで使われている[[Wikipedia:ja:任意アクセス制御|任意アクセス制御]] (Discretionary Access Control, DAC) とは大きく異なるタイプのセキュリティポリシーです。原則的に MAC ではシステムに影響を与えるプログラムの行動は全てセキュリティルールセットによってチェックを受けます。このルールセットは、DAC とは対照的に、ユーザーが変更することは不可能です。実装方法は色々と異なるタイプが存在しますが、強制アクセス制御を使うことで実質的にコンピュータのセキュリティを著しく向上させることになります。

===パス名 MAC===
パス名ベースのアクセス制御は指定されたファイルのパスに基づいてパーミッションを与えるというシンプルな形式のアクセス制御です。この形式のアクセス制御の欠点としてはファイルが移動されてもパーミッションはファイルと一緒に付いていかないということが挙げられます。プラス面となるのは、パス名ベースの MAC はラベルベースの MAC と異なり、幅広いファイルシステムに実装できることです。

*[[AppArmor]] は [[Wikipedia:ja:カノニカル|Canonical]] によって開発されている MAC 実装で SELinux に比べて"簡単"になっています。
*[[TOMOYO Linux|Tomoyo]] はもうひとつのシンプルで、使いやすい強制アクセス制御を提供するシステムです。利用と実装の両面でシンプルになるように設計されており、依存するライブラリがとても少なくなっています。

===ラベル MAC===
ラベルベースのアクセス制御ではファイルの拡張属性を使ってセキュリティパーミッションを管理します。このシステムはセキュリティの機能においてパス名ベースの MAC よりも間違いなく柔軟性が高い一方、拡張属性をサポートしているファイルシステムでしか動作しません。

*[[SELinux]] は、Linux セキュリティを向上させる [[Wikipedia:ja:アメリカ国家安全保障局|NSA]] プロジェクトに基づいており、システムユーザーやロールとは完全に独立して MAC を実装しています。成長してオリジナルの設定が変わっていくシステムのコントロールを簡単に維持できる、極めて強固なマルチレベル MAC ポリシー実装を提供します。

=== アクセス制御リスト ===
[[アクセス制御リスト]] (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。

== カーネルの堅牢化 ==

=== カーネルの自己防衛機能/脆弱性攻撃対策 ===

{{pkg|linux-hardened}} パッケージは、[https://github.com/anthraxx/linux-hardened 基本的なカーネル堅牢化パッチセット]と、{{pkg|linux}} パッケージよりもセキュリティに重点を置いたコンパイル時設定オプションを使用します。カスタムビルドでは、セキュリティ寄りのデフォルトとは異なる、セキュリティと性能の妥協点を選択することができます。

しかし、このカーネルを使うといくつかのパッケージが動かなくなることに注意する必要があります。例えば

* {{AUR|skypeforlinux-preview-bin}}
* {{AUR|skypeforlinux-stable-bin}}
* {{pkg|throttled}}

[[NVIDIA]] などのアウトオブツリードライバを使用している場合、その [[DKMS]] パッケージに切り替える必要があるかもしれません。

==== ユーザー空間 ASLR の比較 ====

{{pkg|linux-hardened}} パッケージは、アドレス空間配置ランダム化の改善された実装をユーザ空間のプロセスに対して提供します。{{pkg|paxtest}} コマンドを使うことで、提供されるエントロピーの推定値を得ることができます:

===== 64 ビットプロセス =====

{{hc|linux-hardened 5.4.21.a-1-hardened|
Anonymous mapping randomization test : 32 quality bits (guessed)
Heap randomization test (ET_EXEC) : 40 quality bits (guessed)
Heap randomization test (PIE) : 40 quality bits (guessed)
Main executable randomization (ET_EXEC) : 32 quality bits (guessed)
Main executable randomization (PIE) : 32 quality bits (guessed)
Shared library randomization test : 32 quality bits (guessed)
VDSO randomization test : 32 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)
Randomization under memory exhaustion @~0: 32 bits (guessed)
Randomization under memory exhaustion @0 : 32 bits (guessed)
}}

{{hc|linux 5.5.5-arch1-1|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 20 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 29 bits (guessed)
Randomization under memory exhaustion @0 : 29 bits (guessed)
}}

{{hc|linux-lts 4.19.101-1-lts|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 19 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 28 bits (guessed)
Randomization under memory exhaustion @0 : 28 bits (guessed)
}}

===== 32 ビットプロセス (x86_64 カーネル上) =====

{{hc|linux-hardened|
Anonymous mapping randomization test : 16 quality bits (guessed)
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)
Heap randomization test (PIE) : 27 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 18 quality bits (guessed)
Shared library randomization test : 16 quality bits (guessed)
VDSO randomization test : 16 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)
Randomization under memory exhaustion @~0: 18 bits (guessed)
Randomization under memory exhaustion @0 : 18 bits (guessed)
}}

{{hc|linux|
Anonymous mapping randomization test : 8 quality bits (guessed)
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)
Heap randomization test (PIE) : 13 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 8 quality bits (guessed)
Shared library randomization test : 8 quality bits (guessed)
VDSO randomization test : 8 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)
Randomization under memory exhaustion @~0: No randomization
Randomization under memory exhaustion @0 : No randomization
}}

=== proc ファイルシステム内のカーネルポインタへのアクセスを制限する ===

{{ic|kernel.kptr_restrict}} を 1 に設定すると、{{ic|CAP_SYSLOG}} を持たない通常ユーザから {{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが秘匿され、カーネルのエクスプロイトで動的にアドレス/シンボルを解決することが困難になります。これは、事前にコンパイルされた Arch Linux カーネルではあまり意味がありません。周到な攻撃者はカーネルパッケージをダウンロードして、そこから手動でシンボルを取得することができるからです。しかしながら、自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし、一部の {{Pkg|perf}} コマンドの機能が、root 以外のユーザによって使用されば場合に破壊されます (しかし、いずれにせよ多くの {{Pkg|perf}} コマンドは root アクセスを必要とします)。詳細は {{Bug|34323}} を参照してください。

{{ic|kernel.kptr_restrict}} を 2 に設定すると、{{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが権限に依らず隠されます。

{{hc|/etc/sysctl.d/51-kptr-restrict.conf|2=
kernel.kptr_restrict = 1
}}

{{Note|{{pkg|linux-hardened}} はデフォルトで {{ic|0}} ではなく {{ic|1=kptr_restrict=2}} を設定します。}}

=== BPF の堅牢化 ===

BPF は、実行時にカーネル内のバイトコードを動的にロードして実行するために使用されるシステムです。ネットワーク (XDP, tc など)、トレース (kprobes, uprobes, tracepoints など)、セキュリティ (seccomp など) など、多くの Linux カーネルサブシステムで使用されています。また、高度なネットワークセキュリティ、パフォーマンスプロファイリング、ダイナミックトレースにも有効です。

BPF はもともと [[Wikipedia:ja:Berkeley Packet Filter|Berkeley Packet Filter]] の頭文字をとったもので、オリジナルの古典的な BPF は BSD 用のパケットキャプチャツールに使われていたためです。これは最終的に拡張 BPF (eBPF) に発展し、その後まもなくただの BPF (頭字語ではありません) に改名されました。BPFはパケットフィルタリングツールの実装に使われることがありますが、 iptables や netfilter のようなパケットフィルタリングツールと混同しないでください。

BPF のコードは解釈されるか、[[Wikipedia:ja:実行時コンパイラ|Just-In-Time (JIT) コンパイラ]]を使ってコンパイルされるかのどちらかです。Arch のカーネルは {{ic|CONFIG_BPF_JIT_ALWAYS_ON}} でビルドされており、BPF インタープリタを無効にして全ての BPF を JIT コンパイラでコンパイルするよう強制しています。これにより、攻撃者が BPF を使って SPECTRE 型の脆弱性を悪用した特権昇格攻撃をすることが難しくなります。詳しくは、[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290af86629b25ffd1ed6232c4e9107da031705cb CONFIG_BPF_JIT_ALWAYS_ON を導入したカーネルパッチ]を参照してください。

カーネルは JIT コンパイルされた BPF に対して、パフォーマンスと多くの BPF プログラムをトレース・デバッグする能力を犠牲にして、ある種の JIT スプレー攻撃を軽減するための堅牢化機能を備えています。この機能は、{{ic|net.core.bpf_jit_harden}} を {{ic|1}} (非特権コードの堅牢化を有効化する) か {{ic|2}} (全てのコードの堅牢化を有効化する) に設定することで有効化できます。

詳しくは、[https://docs.kernel.org/admin-guide/sysctl/net.html カーネルドキュメント] の {{ic|net.core.bpf_*}} 設定を参照してください。

{{Tip|
* {{Pkg|linux-hardened}} では、デフォルトで {{ic|1=net.core.bpf_jit_harden=2}} が設定されており、{{ic|0}} ではありません。
* デフォルトでは、BPF プログラムは非特権ユーザでも実行可能です。この挙動を変更するには {{ic|1=kernel.unprivileged_bpf_disabled=1}} を設定してください [https://access.redhat.com/security/cve/cve-2021-33624]。
}}

=== ptrace スコープ ===

{{man|2|ptrace}} システムコールは、あるプロセス ("tracer") が他のプロセス ("tracee") の実行を監視、制御し、tracee のメモリとレジスタを検査、変更するための手段を提供します。通常、{{ic|ptrace}} は ''gdb'' や ''strace''、''perf''、''reptyr'' などのデバッグツールによって使用されます。しかし、他のプロセスからデータを読んだり、他のプロセスの制御を奪ったりする手段を悪意のあるプロセスにも提供してしまいます。

Arch では、{{ic|kernel.yama.ptrace_scope}} [[カーネルパラメータ]]を提供する [https://docs.kernel.org/admin-guide/LSM/Yama.html Yama LSM] がデフォルトで有効化されています。このパラメータはデフォルトで {{ic|1}} (制限) に設定されており、{{ic|CAP_SYS_PTRACE}} [[ケイパビリティ]]も特権も持たない tracer が制限されたスコープ外で {{ic|ptrace}} コールを実行できないようにしています。これは、古典的なパーミッションと比べてセキュリティ上大きな改善です。このモジュールが無いと、同じユーザとして実行されているプロセスを隔てるものがなくなってしまいます ({{man|7|pid_namespaces}} などの他のセキュリティレイヤーがない場合)。

{{Note|デフォルトでは、[[sudo]] を使うなどして、{{ic|ptrace}} を必要とするツールを特権プロセスとして実行することができます。}}

デバッグツールを使う必要がない場合は、システムを堅牢化するために {{ic|kernel.yama.ptrace_scope}} を {{ic|2}} (管理者限定) や {{ic|3}} ({{ic|ptrace}} を禁止) に設定することを検討してください。

=== hidepid ===

{{Warning|
* これは、サンドボックスと [[Xorg]] 内で実行するアプリケーションなど、特定のアプリケーションで問題を発生させる場合があります (回避策を見てください)。
* {{Pkg|systemd}} > 237.64-1 を使用している場合、これは [[D-Bus]]、[[Polkit]]、[[PulseAudio]]、そして [[bluetooth]] で問題を発生させます。
}}

カーネルには、{{ic|proc}} ファイルシステムを {{ic|1=hidepid=}} オプションと {{ic|1=gid=}} オプションを使ってマウントすることで、他のユーザのプロセス (通常、{{ic|/proc}} でアクセス可能) を非特権ユーザから秘匿する機能があります。これらのマウントオプションは https://docs.kernel.org/filesystems/proc.html でドキュメント化されています。

これにより、侵入者が動作中のプロセスの情報 (特権で動作しているデーモンがあるか、他のユーザが機密情報を扱うプログラムを実行しているか、他のユーザがプログラムを実行しているか) を得る作業を複雑化し、ユーザが特定のプログラムを実行しているかどうかを知るのを不可能にし (ただし、そのプログラムがそれ自体の挙動で存在を他者に知られることがないとする)、さらに、貧弱に書かれたプログラムが機密情報をプログラム引数を介して渡したとしてもローカルの盗聴者から守られます。

{{ic|proc}} [[ユーザーとグループ#システムグループ#グループ]] ({{Pkg|filesystem}} パッケージによって提供されています) は、他のユーザのプロセス情報を得ることのできるユーザのホワイトリストとして機能します。ユーザやサービスが自身以外の {{ic|/proc/<pid>}} ディレクトリにアクセスする必要がある場合、そのユーザまたはサービスを[[ユーザーとグループ#グループ管理|proc グループに追加してください]]。

例えば、プロセスの情報を {{ic|proc}} グループに属さない他のユーザから隠すには:

{{hc|/etc/fstab|2=
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
}}

ユーザのセッションを正しく動作させるために、''systemd-logind'' を例外として追加する必要があります:

{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=
[Service]
SupplementaryGroups=proc
}}

=== モジュールのロードを制限する ===

デフォルトの Arch カーネルは {{ic|CONFIG_MODULE_SIG_ALL}} が有効で、{{Pkg|linux}} パッケージの一部としてビルドされた全てのカーネルモジュールに署名します。これにより、カーネルは有効なキーで署名されたモジュールだけをロードするように制限できます。実際、これはローカルでコンパイルされた、もしくは {{Pkg|virtualbox-host-modules-arch}} などのパッケージによって提供された、ツリー外のモジュールは全てロードできないことを意味します。

カーネルモジュールの読み込みは {{ic|1=module.sig_enforce=1}} [[カーネルパラメータ]]を設定することで制限することができます。詳細は[https://docs.kernel.org/admin-guide/module-signing.html カーネルドキュメント]で見られます。

=== kexec を無効にする ===

Kexec は、現在実行中のカーネルを置き換えることを可能にします。

{{hc|/etc/sysctl.d/51-kexec-restrict.conf|2=
kernel.kexec_load_disabled = 1
}}

{{Tip|kexec は {{pkg|linux-hardened}} でデフォルトで無効になっています。}}

=== カーネルロックダウンモード ===

Linux 5.4 から、オプションの[https://mjg59.dreamwidth.org/55105.html ロックダウン機能]がカーネルに[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d 追加されました]。これは、UID 0 (root) とカーネルの間の境界を強化することを目的としています。この機能を有効にすると、ハードウェアやカーネルへの低レベルなアクセスに依存している一部のアプリケーションは動作しなくなる可能性があります。

ロックダウンを使用するには、LSM が初期化され、ロックダウンモードが設定されている必要があります。

[[カーネル#公式サポートカーネル|公式にサポートされているカーネル]]は全て LSM を初期化しますが、ロックダウンモードを強制しません。

{{Tip|有効化されている LSM は {{ic|cat /sys/kernel/security/lsm}} を実行することで確認することができます。}}

ロックダウンには2つの動作モードがあります:

* {{ic|integrity}}: ユーザーランドが実行中のカーネルを変更できるカーネル機能 (kexec、bpf) は無効化されます。
* {{ic|confidentiality}}: ユーザーランドがカーネルから機密情報を抽出するためのカーネルの機能も無効化されます。

特定の脅威モデルで指示がない限り、{{ic|integrity}} を使用することが推奨されます。

実行時にカーネルのロックダウンを有効にするには、以下を実行してください:

# echo ''mode'' > /sys/kernel/security/lockdown

起動時にカーネルのロックダウンを有効にするには、{{ic|1=lockdown=''mode''}} [[カーネルパラメータ]]を使用してください:

{{Note|
* カーネルロックダウンを実行時に無効化することはできません。
* カーネルロックダウンは、[[ハイバネート]]を無効化します。
}}

{{man|7|kernel_lockdown}} も参照してください。

=== Linux Kernel Runtime Guard (LKRG) ===

[https://www.openwall.com/lkrg/ LKRG] ({{AUR|lkrg-dkms}}) は、カーネルの整合性チェックとエクスプロイト行為の検出を行うカーネルモジュールです。

== アプリケーションのサンドボックス化 ==

こちらも参照 [[Wikipedia:ja:サンドボックス (セキュリティ)]]

{{Note|ユーザー名前空間の設定項目 {{ic|CONFIG_USER_NS}} は、現在 {{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}}、および {{Pkg|linux-hardened}} で有効になっています。これが無効だと、一部のアプリケーションで特定のサンドボックス機能が利用できなくなる可能性があります。}}

{{Warning|非特権ユーザー名前空間の使用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) は、{{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}} でデフォルトで有効になっています。これにより、ローカル特権昇格の攻撃対象が大幅に拡大します([https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction AppArmorのWiki] および {{Bug|36969}} を参照。}}

これを軽減するためには、次のいずれかを行ってください:

* 安全なデフォルトを持つ {{Pkg|linux-hardened}} カーネルを使用する、または
* {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] を {{ic|0}} に設定する。

これにより、[[Zoom Meetings|Zoom]] や {{pkg|nsjail}} などのアプリケーションが動作しなくなる場合があることに注意してください。また、システムに {{pkg|bubblewrap}} がインストールされている場合は、{{pkg|bubblewrap-suid}} に置き換える必要があります。詳細は [[Bubblewrap#インストール]] を参照してください。

=== Firejail ===

[[Firejail]] は、アプリケーションやサーバーをサンドボックス化するための使いやすいツールです。元々はブラウザやインターネット向けアプリケーションのために作成されましたが、現在では多くのアプリケーションに対応しています。さまざまな機能を備えたサンドボックス環境を構築するために、suid バイナリとしてインストールされ、ブラックリストとホワイトリストに基づいてターゲットアプリケーションのサンドボックス化された実行環境を構築します。

=== bubblewrap ===

[[bubblewrap]] は、[[Flatpak]] などの非特権コンテナツール向けに開発されたサンドボックスアプリケーションで、Firejail よりもリソース消費と複雑さが大幅に小さいです。ファイルパスのホワイトリスト機能は欠けていますが、bubblewrap はバインドマウントのほか、ユーザー/IPC/PID/ ネットワーク /cgroup 名前空間の作成をサポートしており、シンプルなものから複雑なサンドボックスまで対応可能です。

[[Bubblejail]] サンドボックスは [[bubblewrap]] を基にしており、リソース指向の権限モデルと、権限を調整するためのグラフィカルインターフェースを提供します。

=== chroot ===

手動で [[chroot]] してサンドボックス化されたプロセス環境を作成できます。しかし、これは他のサンドボックス技術に比べて非常に制限されています。そのサンドボックス化の範囲はファイルパスの隔離に限られています。

=== Linux Containers ===

[[Linux Containers]] は、他のオプション([[#完全な仮想化オプション|完全な仮想化オプション]] を除く) よりも多くの隔離が必要な場合に適した選択肢です。LXC は、既存のカーネルの上で擬似 chroot 内で実行され、独自の仮想ハードウェアを持っています。

=== 完全な仮想化オプション ===

[[VirtualBox]]、[[KVM]]、[[Xen]]、または [https://www.qubes-os.org/ Qubes OS](Xen ベース)などの完全仮想化オプションを使用することで、リスクの高いアプリケーションを実行したり、危険なウェブサイトを閲覧したりする場合に、隔離とセキュリティを強化することができます。

==ネットワークとファイアウォール==

===ファイアウォール===

標準の Arch カーネルは [[Wikipedia:Netfilter|Netfilter]] の [[iptables]] および [[nftables]] を使用できますが、これらのサービスはデフォルトで [[有効化]] されていません。システム上で実行されているサービスを保護するために、何らかの形のファイアウォールを設定することを強く推奨します。多くのリソース(ArchWiki など)では、どのサービスを保護するべきかが明示的に記載されていないため、ファイアウォールを有効にすることは良い予防措置となります。

* 一般的な情報については [[iptables]] および [[nftables]] を参照してください。
* iptables ファイアウォールの設定方法については [[シンプルなステートフルファイアウォール]] を参照してください。
* netfilter の設定方法については [[ファイアウォール]] を参照してください。
* Bluetack などの IP アドレスリストをブロックするには [[Ipset]] を参照してください。
* {{Pkg|opensnitch}} は、アプリケーション、ポート、ホストなどによる設定可能なルールをサポートする、構成可能なインバウンドおよびアウトバウンドファイアウォールです。

==== ポートを開く ====

一部のサービスは、開かれたネットワークポートでインバウンドトラフィックを待ち受けます。これらのサービスは、必要最低限のアドレスとインターフェースにのみバインドすることが重要です。リモート攻撃者が [https://samy.pl/slipstream/ ネットワークプロトコルの欠陥を悪用して公開されたサービスにアクセスする] 可能性があります。これは、[https://nvd.nist.gov/vuln/detail/CVE-2019-13450 localhost にバインドされたプロセス] にも発生することがあります。

一般的に、サービスがローカルシステムのみでアクセス可能であれば、非ループバックアドレス(例えば {{ic|0.0.0.0/0}})ではなく、Unix ドメインソケット({{man|7|unix}})や {{ic|localhost}} のようなループバックアドレスにバインドするべきです。

サービスがネットワーク越しに他のシステムからアクセス可能である必要がある場合、厳格な [[ファイアウォール]] ルールでアクセスを制御し、可能な限り認証、認可、暗号化を構成することが重要です。

現在のすべてのオープンポートをリストするには、{{ic|ss -l}} を使用できます。すべてのリスニング中のプロセスとその数値的な TCP および UDP ポート番号を表示するには:

# ss -lpntu

その他のオプションについては、{{man|8|ss}}を参照してください。

===カーネルパラメータ===
ネットワークに影響を与えるカーネルパラメータは [[sysctl]] を使って設定できます。設定方法は [[sysctl#TCP/IP スタックの防御]] を見て下さい。

===SSH===
[[SSH 鍵#パスワードログインの無効化|SSH 鍵を必要]]としない [[Secure Shell]] を使うのは避けましょう。これは[[Wikipedia:ja:総当たり攻撃|総当たり攻撃]]を防ぎます。また、[[Fail2ban]] や [[Sshguard]] はログを監視して [[iptables|iptables ルール]]を書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。

二段階認証によって認証を強化することができます。[[Google Authenticator]] はワンタイムパスコード (OTP) を使用する二段階認証方式を提供します。

[[Secure Shell#root ログインを拒否する|root ログインを拒否する]]のは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。

===DNS===

[[DNSSEC]] や [[DNSCrypt]] を見て下さい。

=== プロキシ ===

プロキシはアプリケーションとネットワークの間に挟まる追加レイヤーとして使われ、信頼できないソースからのデータをサニタイズします。少ない権限でプロキシを動作させることで、エンドユーザー権限で複雑なアプリケーションを実行するよりも攻撃対象を小さくすることができます。

例えば {{Pkg|glibc}} の中に実装されている DNS リゾルバを考えてみてください。(root で実行することもある) アプリケーションにリンクされている DNS リゾルバにバグが存在した場合、リモートコード実行につながる危険があります。[[dnsmasq]] などの DNS キャッシュサーバーをインストールしてプロキシとして使うことで問題を防ぐことが可能です [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]。

=== SSL 証明書の管理 ===

サーバーサイドの SSL 証明書の管理については [[OpenSSL]] や [[Network Security Services]] (NSS) を参照してください。また、関連する [[Let’s Encrypt]] プロジェクトも見てください。

デフォルトのインターネット SSL 証明書のトラストチェーンは {{Pkg|ca-certificates}} パッケージによって提供されています。Arch はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: {{AUR|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) に依存しています。

デフォルトの証明書を変えたいと思うことがあるかもしれません。例えば、[http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ ニュース] を読んで証明書を信頼しないようにしたい場合 (ソースのプロバイダーによって無効になるのを待てない場合)、Arch のインフラを使うことで簡単に設定できます:
# {{ic|.crt}} 形式の証明書を入手してください (例: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; 既存のルート認証局の場合、システム内にあるはずです)。
# {{ic|/etc/ca-certificates/trust-source/blacklist/}} にコピーしてください。
# root で ''update-ca-trust'' を実行してください。

お好きなブラウザを開いて'''信頼できない'''サイトとして表示されれば、ブラックリストが上手く機能しています。

== 物理セキュリティ ==

{{Note|リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。}}

十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで''実用的で''高いレベルのセキュリティを得ることができます。

攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [http://www.breaknenter.org/projects/inception/]。これを防ぐためにできることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識がなく実行されることはほとんどありません。

[[#ディスク暗号化|ディスク暗号化]]はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。

===BIOS をロックダウンする===

BIOS にパスワードを追加することによってリムーバブルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。

=== ブートローダー ===

[[Arch ブートプロセス#ブートローダー|ブートローダー]] を保護することは非常に重要です。保護されていないブートローダは、例えば {{ic|1=init=/bin/sh}} を設定することでログインの制限を回避することができます。[[カーネルパラメータ]] でシェルに直接ブートするようにします。

==== Syslinux ====

Syslinux は[[Syslinux#セキュリティ|ブートローダーのパスワード保護]]をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。

==== GRUB ====

[[GRUB]] はブートローダのパスワードもサポートしています。詳しくは [[GRUB/ヒントとテクニック#GRUB メニューのパスワード保護|GRUB メニューのパスワード保護]] を参照してください。[[GRUB/ヒントとテクニック# GRUB メニューのパスワード保護|暗号化 /boot]] もサポートしていますが、これはブートローダコードの一部だけを暗号化しないままにしています。GRUB の設定、[[カーネル]]、[[initramfs]] は暗号化されています。

==== systemd-boot ====

[[systemd-boot]] は [[#セキュアブート]] が有効な場合、カーネルパラメータの編集を無効にします。代わりの方法として、[[systemd-boot#パスワードで保護されたカーネルパラメータエディタ]] を参照して下さい、より伝統的なパスワードベースのオプションを使用できます。

=== セキュアブート ===

[[セキュアブート]] は [[UEFI]] の機能で、コンピュータが起動するファイルの認証を可能にするものです。これは、起動パーティション内のファイルを置き換えるような、いくつかの [https://ja.wikipedia.org/wiki/%E6%82%AA%E6%84%8F%E3%81%82%E3%82%8B%E3%83%A1%E3%82%A4%E3%83%89%E6%94%BB%E6%92%83 悪意あるメイド攻撃] を防止するのに役立つ。通常、コンピュータにはベンダー (OEM) によって登録されたキーが付属しています。しかし、これを取り外して、コンピュータを「セットアップモード」にし、ユーザーが自分のキーを登録・管理できるようにすることができます。

セキュアブートのページでは、[https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Implementing_Secure_Boot using your own keys] によってセキュアブートを設定する方法を案内しています。

=== トラステッドプラットフォームモジュール(TPM) ===

[[Trusted Platform Module|TPM]] は、暗号鍵が埋め込まれたハードウェア・マイクロプロセッサです。これは、最近のほとんどのコンピュータの基本的な信頼性の根源を形成し、ブートチェーンのエンドツーエンドの検証を可能にします。内部スマートカードとして使用したり、コンピュータ上で動作するファームウェアを証明したり、改ざん防止とブルートフォース耐性のあるストアにユーザーがシークレットに挿入することができます。

=== リムーバブルフラッシュドライブ上のブートパーティション ===

ブートパーティションをフラッシュドライブに置き、それがないとシステムが起動しないようにする、というのはよくあるアイデアです。このアイデアの支持者はしばしば [[セキュリティ#ディスク暗号化|ディスク暗号化]] を併用し、ブートパーティションに置かれた [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USBdetached encryption headers] を使っている人もいます。

この方法は [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USB encrypting /boot] と統合することも可能です。

=== 自動ログアウト ===
[[Bash]] または [[Zsh]] を使っている場合、{{ic|TMOUT}} によってタイムアウトによるシェルからの自動ログアウトを設定できます。

例えば、以下は仮想コンソールから自動でログアウトします (X11 のターミナルエミュレータからはログアウトしません):

{{hc|/etc/profile.d/shell-timeout.sh|<nowiki>
TMOUT="$(( 60*10 ))";
[ -z "$DISPLAY" ] && export TMOUT;
case $( /usr/bin/tty ) in
/dev/tty[0-9]*) export TMOUT;;
esac
</nowiki>}}

(X のコンソールも含めて) 全ての Bash/Zsh プロンプトでタイムアウトさせたい場合は、次を使って下さい:

$ export TMOUT="$(( 60*10 ))";

シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや {{ic|TMOUT}} をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。

=== 不正なUSBデバイスから保護する ===

[[Usbguard]] は、デバイスの属性に基づく基本的なホワイトリストおよびブラックリスト機能を実装することで、不正な USB デバイス (別名 [https://ja.wikipedia.org/wiki/BadUSB BadUSB], [https://github.com/samyk/poisontap PoisonTap] または [https://lanturtle.com/ LanTurtle]) からコンピューターを保護できるソフトウェアフレームワークです。

=== 揮発性データの収集 ===

電源が入っているコンピュータは、[https://fedvte.usalearning.gov/courses/CSI/course/videos/pdf/CSI_D01_S05_T01_STEP.pdf volatile data collection] に対して脆弱である可能性があります。コンピュータの電源を入れる必要がない時や、コンピュータの物理的な安全性が一時的に損なわれる場合(例:セキュリティチェックポイントを通過する時)には、コンピュータの電源を完全に切ることがベストプラクティスです。

== パッケージ ==

=== パッケージの認証 ===
パッケージの署名が適正に使われていないと [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview パッケージマネージャへの攻撃] が考えられ、さらに [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html 適切な署名システム] を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは [[Pacman-key]] を見て下さい。

=== アップグレード ===

定期的に [[システムメンテナンス#システムのアップグレード|システムのアップグレード]] を行うことが重要です。

=== 脆弱性アラートの確認 ===

National Vulnerability Database が提供する Common Vulnerabilities and Exposure (CVE) Security Alert の更新を購読し、[https://nvd.nist.gov/download.cfm NVD Download webpage] で見つけてください。[https://security.archlinux.org/ Arch Linux Security Tracker] は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットを表形式でまとめた、特に有用なリソースです。ツール {{Pkg|arch-audit}} は実行中のシステムに影響を与える脆弱性をチェックするために使われます。グラフィカルなシステムトレイである {{Pkg|arch-audit-gtk}} も使うことができます。[https://wiki.archlinux.org/title/Arch_Security_Team Arch Security Team]も参照してください。

特にメインレポジトリや AUR 以外の手段でソフトウェアをインストールしている場合は、あなたが使っているソフトウェアのリリース通知を購読することも検討すべきです。いくつかのソフトウェアには、セキュリティに関する通知を受け取るために購読できるメーリングリストがあります。ソースコードホスティングサイトはしばしば新しいリリースの RSS フィードを提供しています。

=== パッケージの再ビルド ===

攻撃対象領域を減らす手段として、パッケージをリビルドし、不要な関数や機能を削除することができます。例えば、{{Pkg|bzip2}} は [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189] を回避するために {{ic|bzip2recover}} を使わずにリビルドすることが可能です。カスタムハードニングフラグは、手動またはラッパーを介して適用することもできます。

{| class="wikitable"
! フラグ !! 目的
|-
| -D_FORTIFY_SOURCE=2 || ランタイムバッファオーバーフローの検出
|-
| -D_GLIBCXX_ASSERTIONS || C++ の文字列とコンテナのランタイム境界チェック
|-
| -fasynchronous-unwind-tables || バックトレースの信頼性向上
|-
| -fexceptions || テーブルベースのスレッドキャンセルを有効にする
|-
| -fpie -Wl,-pie || 実行可能ファイルに対する完全な ASLR
|-
| -fpic -shared || 共有ライブラリのテキスト再配置を行わない
|-
| -fplugin=annobin || ハードニング品質管理用データの作成
|-
| -fstack-clash-protection || スタックオーバーフロー検出の信頼性向上
|-
| -fstack-protector or -fstack-protector-all || スタックスマッシュプロテクター
|-
| -fstack-protector-strong || 同様に
|-
| -g || デバッグ情報を生成する
|-
| -grecord-gcc-switches || デバッグ情報にコンパイラのフラグを格納する
|-
| -mcet -fcf-protection || 制御フローの完全性保護
|-
| -O2 || 推奨される最適化
|-
| -pipe || 一時ファイルを回避し、ビルドを高速化します。
|-
| -Wall || 推奨されるコンパイラの警告
|-
| -Werror=format-security || 安全でない可能性のあるフォーマット文字列の引数を拒否する
|-
| -Werror=implicit-function-declaration || 関数プロトタイプの欠落を却下する
|-
| -Wl,-z,defs || アンダーリンクの検出と拒否
|-
| -Wl,-z,now || 遅延バインディングを無効にする
|-
| -Wl,-z,relro || 移設後の読み出し専用セグメント
|}

* [https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/ Flags and info ソース]

== 参照 ==

* [https://security.archlinux.org/ Arch Linux セキュリティトラッカー]
* ArchWiki のセキュリティアプリケーションのリスト: [[アプリケーション一覧/セキュリティ]]
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux ワークステーションのセキュリティチェックリスト]
* [https://www.privacytools.io/ privacytools.io Privacy Resources]
* [https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/index.html Red Hat Enterprise Linux 7 セキュリティガイド]
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Debian 安全化マニュアル (PDF)]
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]

セキュリティ

2025-04-06T22:47:40Z

Oech3: バイナリを追加/* SUID ファイルと SGID ファイル */

[[Category:セキュリティ]]
[[Category:ファイルシステム]]
[[Category:ネットワーク]]
[[en:Security]]
[[fa:امنیت]]
[[ru:Security]]
[[zh-hans:Security]]
{{Related articles start}}
{{Related|PAM}}
{{Related|ケイパビリティ}}
{{Related|アプリケーション一覧/セキュリティ}}
{{Related|:カテゴリ:セキュリティ}}
{{Related articles end}}
この記事には、Arch Linux システムを[[Wikipedia:ja:ハードニング|ハードニング]]するための推奨事項とベストプラクティスを並べています。

== 概念 ==

* システムのセキュリティを厳重にしすぎると、使い物にならなくなることもある。セキュリティと利便性のバランスを取ることが重要だ。重要なのは、安全で ''かつ'' 使いやすいシステムを作ること。
* 最大の脅威は常にユーザー自身である。
* [[Wikipedia:ja:最小権限の原則|最小権限の原則]]: システムの各部分は、必要最小限の権限のみを持つべきであり、それ以上のアクセスは許可されるべきではない。
* 多層防御 (Defense in Depth): セキュリティは独立した複数の層で成り立つべきである。一つの層が突破されても、次の層が攻撃を食い止める仕組みが必要です。
* 少しだけ疑い深くなること。常に警戒すること。うますぎる話には注意すべきだ。それが本当である可能性は低いと思うこと。
* システムを100%安全にする方法はただ一つ。それはネットワークから切り離し、電源を切り、金庫に入れ、コンクリートで固め、二度と使用しないこと。
* 失敗を想定せよ。セキュリティが破られたときに備え、あらかじめ対応策を準備しておくこと。

==パスワード==
パスワードは安全な linux システムのかぎです。パスワードは[[ユーザーとグループ|ユーザーアカウント]], [[ディスク暗号化|暗号化されたファイルシステム]], [[SSH 鍵|SSH]]/[[GPG]] 鍵などを守ります。コンピュータを使用する人を信頼するのに使う主要な手段なので、安全なパスワードを選んでそれを保護するというのがセキュリティの大部分と言っても過言ではありません。

=== 安全なパスワードの選び方 ===

パスワードは、個人情報などから簡単に推測されないよう十分に複雑であり、また、ソーシャルエンジニアリングやブルートフォース攻撃などの手法で[[Wikipedia:Password cracking|クラック]]されないようにする必要があります。強力なパスワードの基本原則は、''長さ''と''ランダム性''に基づいています。暗号学では、パスワードの品質はその[[Wikipedia:Password strength#Entropy as a measure of password strength|エントロピー]]によって測られます。

安全でないパスワードには、以下のようなものが含まれます。また、以下のようなものを元に変更や置き換えを行った場合も同様に危険です。

* 個人を特定できる情報(例:ペットの名前、生年月日、市外局番、好きなビデオゲームなど)
* 単純な文字の置き換えを行った単語(例:{{ic|k1araj0hns0n}})最新の辞書攻撃ではこれらも簡単に解析可能
* 既存の "単語" や一般的な文字列の前後に数字・記号・文字を追加したもの(例:{{ic|DG091101%}})
* 一般的なフレーズや辞書にある単語を短く組み合わせたもの(例:{{ic|photocopyhauntbranchexpose}})文字の置き換えを行っても(例:{{ic|Ph0toc0pyh4uN7br@nch3xp*se}})、安全とは限らない(ただし、後述の "Diceware" を利用した場合は例外あり)
* [[Wikipedia:List of the most common passwords|最も一般的なパスワード]]のいずれか

最も安全なパスワードは、十分に長く(長いほど良い)ランダムなソースから生成されたものです。長いパスワードを使用することが重要です。[https://www.theregister.com/2019/02/14/password_length 弱いハッシュアルゴリズムを使用すると、8文字のパスワードハッシュはわずか数時間で解読可能] です。

{{Pkg|pwgen}} や {{AUR|apg}} のようなツールを使用すると、ランダムなパスワードを生成できます。しかし、これらのパスワードは覚えにくいことがあります。覚えやすくするための1つの方法は、長いパスワードを生成し、最初は最低限の安全な文字数だけを暗記し、完全な文字列を一時的に書き留めることです。時間をかけて入力する文字数を増やしていけば、最終的にはパスワードが筋肉の記憶として定着し、完全に覚える必要がなくなります。この方法は難易度が高いものの、辞書攻撃や "知的" ブルートフォース攻撃(単語の組み合わせや文字の置き換えを考慮する攻撃)に対して非常に強力です。

パスワード管理とは別に、{{Pkg|keepassxc}} はパスワード/パスフレーズの生成機能を提供します。GUI でカスタマイズ可能なパスワード生成機能があり、辞書ベースのパスフレーズもサポートされています。

パスワードを覚えるための1つの方法として、**記憶術(ニーモニック)**を利用することが挙げられます。
例えば、"the girl is walking down the rainy street" というフレーズは、以下のようなパスワードに変換できます。簡単な例:{{ic|t6!WdtR5}} より複雑な例:{{ic|t&6!RrlW@dtR,57}}
この方法は、パスワードを覚えやすくすることができますが、英単語の最初の文字には偏りがあることに注意が必要です([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]] を参照)

また、ランダムに生成したパスワードを紙に書いて安全な場所に保管するという方法も有効です。例えば、財布、カバン、金庫などに保管するのがよいでしょう。ほとんどの人は、デジタルセキュリティよりも物理的な貴重品の保護に関しては理解しやすいため、この方法は現実的です。

さらに、記憶術とランダム生成を組み合わせる方法も効果的です。例えば、長くランダムに生成したパスワードを[[パスワードマネージャ]]に保存し、それをマスターパスワードで管理する方法です。マスターパスワードは記憶し、絶対に保存しないようにします。この方法では、パスワードマネージャーがインストールされているシステムでのみパスワードにアクセスできるようになり、状況によっては不便にもなりますが、セキュリティ強化の側面もあります。一部のパスワードマネージャーにはスマートフォンアプリもあり、手入力が必要な場合にパスワードを表示することができます(この場合、完全にランダムなものではなく、タイピングしやすいが安全なパスワードを使うことも検討できます)ただし、マスターパスワードを忘れるとすべてのパスワードにアクセスできなくなるため、単一障害点になり得ることに注意が必要です。
また、一部のパスワードマネージャーは、保存するパスワードを暗号化するのではなく、マスターパスワードとサービス名から計算する方式を採用しており、新しいシステムでもデータ同期なしで使用できます。

覚えやすく、それでいて強力なパスワードの作成方法として、無関係な単語を複数組み合わせたパスフレーズを使うという方法もあります。この方法では、十分に長いフレーズを使用することで、辞書単語を使うことによるエントロピーの損失を補うことができます。この手法のエントロピーのトレードオフについては、[https://xkcd.com/936/ xkcdのコミック] に示されています。この方法の安全性は、選択可能な単語の集合が大きい(数千語以上)ことと、5〜7語以上のランダムな単語を選択することによって保証されます。攻撃者が選択可能な単語の集合と、使用する単語数を知っていたとしても、(選択可能な単語数) の (選択する単語数) 乗の通りのパスフレーズが生成可能であり、安全性が確保されます。詳細については [https://www.rempe.us/diceware/ Diceware] を参照してください。

さらに詳しい情報については、[https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] や [[Wikipedia:Password strength]] も参考になります。

=== パスワードの管理 ===

強力なパスワードを選んだら、それを安全に保管することが重要です。[[Wikipedia:Keylogger|キーロガー]] (ソフトウェアおよびハードウェア)、スクリーンロガー、[[Wikipedia:Social engineering (security)|ソーシャルエンジニアリング]]、[[Wikipedia:Shoulder surfing (computer security)|ショルダースーフィング]]に注意し、パスワードの使い回しを避けて、セキュリティの低いサーバーから不要な情報が漏れないようにしましょう。[[アプリケーション一覧/セキュリティ#パスワードマネージャ|パスワードマネージャ]]を使用すると、大量の複雑なパスワードを管理できます。パスワードマネージャーからアプリケーションに保存されたパスワードをコピー&ペーストして使用する場合は、毎回コピーした内容をクリアし、ログに保存されないようにしてください(例:プレーンテキストのターミナルコマンドにペーストしないようにし、{{ic|.bash_history}} などのファイルに保存されないようにします)ブラウザ拡張として実装されたパスワードマネージャは、[https://www.spookjs.com サイドチャネル攻撃]に脆弱である可能性があります。これを回避するためには、別のアプリケーションとして実行されるパスワードマネージャーを使用することが推奨されます。

原則として、強力なパスワードを覚えにくいからといって、セキュリティが低いパスワードを選んではいけません。パスワードはバランスを取る必要があります。強力なマスターパスワードと鍵で守られた暗号化された安全なパスワードデータベースを持つ方が、多くの似たような弱いパスワードを使うよりも優れています。パスワードを紙に書いて保管することも、[https://www.schneier.com/blog/archives/2005/06/write_down_your.html] で示されているように、ソフトウェアの脆弱性を避けつつ物理的なセキュリティを確保できるため、非常に効果的です。

パスフレーズの強度のもう一つの側面は、それが他の場所から簡単に回復できないことです。

ディスク暗号化のパスフレーズをログインパスワードと同じに使用する場合(例えば、ログイン時に暗号化されたパーティションやフォルダを自動マウントする場合)、{{ic|/etc/shadow}} が暗号化されたパーティションに保存されるか、または強力な鍵導出関数 (i.e. yescrypt/argon2 や sha512 を PBKDF2 で使用、md5 や低回数の PBKDF2 は避ける) を使用して保存されたパスワードハッシュを使うようにしてください (詳細については [[SHA hashes#SHA パスワードハッシュ|SHA パスワードハッシュ]] を参照してください)

{{Tip|Arch Linux は [https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのハッシュアルゴリズム]を yescrypt に変更しました。もしデフォルトをカスタマイズしていない場合は、{{ic|passwd}} を実行してパスワード変更を行うなどして下さい。}}

パスワードデータベースをバックアップする場合、そのコピーが他のパスフレーズで保護されていないことを確認してください。例えば、暗号化されたドライブや認証されたリモートストレージサービスなどです。もしそのような保護が施されている場合、必要なときにアクセスできなくなります。役立つ方法としては、データベースがバックアップされているドライブやアカウントをマスターパスワードの簡単な暗号学的ハッシュで保護することです。バックアップ場所のリストを保持してください。もしもマスターパスワードが漏洩したと疑われる場合、その場所すべてでパスワードを即座に変更し、マスターパスワードから導出された鍵で保護されたすべてのバックアップと場所も変更する必要があります。

データベースをセキュアにバージョン管理するのは非常に複雑な場合があります。もしその方法を選択するなら、すべてのデータベースバージョンでマスターパスワードを更新する手段を持っている必要があります。マスターパスワードが漏洩したときにそれを即座に知るのは難しいことがあります。他の人がパスワードを発見するリスクを減らすために、定期的にパスワードを変更することを選ぶかもしれません。もしデータベースのコピーの管理が失われたと感じた場合、そのコピーがブルートフォース攻撃によってマスターパスワードを解読される前に、そのデータベース内のすべてのパスワードを変更する必要があります。

=== パスワードのハッシュ ===

ハッシュは一方向の関数です。つまり、入力を計算せずにそのハッシュを解読することは不可能になるように設計されています (例:MD5、SHA)

パスワードハッシュ関数は、ユーザー入力 (パスワード) を計算せずに解読することが不可能になるように設計されています(例:bcrypt)[[Wikipedia:Key derivation function|鍵導出関数]] (KDF; 例:yescrypt、scrypt、PBKDF2) は、入力 (マスターキーやパスワード) から秘密鍵 (例:AESキー、パスワードハッシュ) を導出するために設計された暗号アルゴリズムです。したがって、KDF はパスワードハッシュ関数としても使用できる複数の用途に対応します。

デフォルトでは、Arch Linux はユーザーパスワードをルート専用の読み取り可能な {{ic|/etc/shadow}} ファイルにハッシュ化して保存します。これは、他のユーザーのパラメータが保存される世界に読み取り可能な {{ic|/etc/passwd}} ファイルから分離されています。詳細は [[ユーザーとグループ#ユーザーデータベース]] を参照してください。また、[[#root の制限]] も参照してください。

パスワードは '''passwd''' コマンドを使用して設定され、このコマンドはシステムの暗号化関数でパスワードを[[Wikipedia:Key stretching|ストレッチ]]し、その後 {{ic|/etc/shadow}} に保存されます。パスワードは[[Wikipedia:Salt (cryptography)|ソルト]]も施され、[[Wikipedia:Rainbow table|レインボーテーブル]]攻撃に対して防御されます。詳細は[https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils Linux でパスワードがどのように保存されているか(Shadow ユーティリティを使ったハッシュの理解)]を参照してください。

パスワードハッシュは定義されたフォーマットに従って保存されるため、新たな ''passwd'' コマンドの実行に対してメソッドとパラメータを設定することができます。したがって、{{ic|/etc/shadow}} ファイルに保存された個々のハッシュは、システムでサポートされているハッシュ関数の異種混合になる可能性があります。

フォーマット、ハッシュメソッド、およびパラメータに関する詳細は、{{man|5|crypt}} を参照してください。

{{ic|/etc/login.defs}} ファイルでは、[https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのパスワードハッシュメソッド]{{ic|ENCRYPT_METHOD YESCRYPT}} とそのパラメータ {{ic|YESCRYPT_COST_FACTOR}} が設定されます。

例えば、デフォルトの {{ic|YESCRYPT_COST_FACTOR}} パラメータを増加させると、パスワードからハッシュを導き出すために必要な計算時間が対数的に増加します。これは、システムがユーザーのログインを認証する際や、第三者がパスワードの秘密を取得しようとする場合にも適用されます。

これに対して、SHA-512 ハッシュ関数の計算時間は、パラメータにより線形的に影響されます。以前の Arch のデフォルトについては [[SHA パスワードハッシュ]] を参照してください。yescrypt アルゴリズムは内部で SHA-256、HMAC、およびPBKDF2 を使用してパスワードハッシュを計算することに注意してください。主な理由は、これらの広く使用され、テストされた関数の良い特性を組み合わせ、攻撃への耐性を強化することです。例えば、SHA の多用途性が原因で、この関数のハードウェアサポートが提供され、SHA ハッシュの計算性能が著しく向上したため、パスワードハッシュ関数としての使用が次第に時代遅れになりつつあります。

=== pam_cracklib を用いた強力なパスワードの強制 ===

''pam_pwquality'' は、[[Wikipedia:Dictionary attack|辞書攻撃]]に対する保護を提供し、システム全体で強制できるパスワードポリシーを設定するのに役立ちます。これは ''pam_cracklib'' をベースにしており、そのオプションとの後方互換性があります。

{{Pkg|libpwquality}} パッケージを[[インストール]]してください。

{{Warning|デフォルトでは、''root'' アカウントはこのポリシーの影響を受けません。}}

{{Note|
* ''root'' アカウントを使用すると、設定したパスワードポリシーをバイパスするユーザーパスワードを設定できます。これは一時的なパスワードを設定する際に便利です。
* 現在のパスワードに関するセキュリティガイドライン(例:NISTなど)では、特別な文字を強制することは推奨されていません。なぜなら、それらはしばしば予測可能な変更を引き起こすだけだからです。
}}

例えば、以下のポリシーを強制したい場合:

* エラーが発生した場合にパスワードを2回入力する (retry オプション)
* 最小長10文字 (minlen オプション)
* 新しいパスワードを入力する際、古いパスワードとは少なくとも6文字異なること (difok オプション)
* 最低1桁の数字 (dcredit オプション)
* 最低1つの大文字 (ucredit オプション)
* 最低1つの小文字 (lcredit オプション)
* 最低1つのその他の文字 (ocredit オプション)
* "myservice" および "mydomain" という単語を含めない
* root にもこのポリシーを強制する

{{ic|/etc/pam.d/passwd}}ファイルを以下のように編集します:

{{bc|1=
#%PAM-1.0
password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root
password required pam_unix.so use_authtok sha512 shadow
}}

{{ic|password required pam_unix.so use_authtok}} は、''pam_unix'' モジュールに対してパスワードの入力を促さず、代わりに ''pam_pwquality'' で提供されたものを使用するように指示します。

詳細については、{{man|8|pam_pwquality}} および {{man|8|pam_unix}} のマニュアルページを参照してください。

== CPU ==

=== マイクロコード ===

CPU のマイクロコードに対する重要なセキュリティ更新プログラムをインストールする方法については、[[マイクロコード]] を参照してください。

=== ハードウェアの脆弱性 ===

CPU の中には、ハードウェアの脆弱性を含んでいるものがあります。これらの脆弱性の一覧と、特定の使用シナリオに合わせてこれらの脆弱性を緩和するためにカーネルをカスタマイズするのに役立つ緩和策の選択ガイドについては、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/ kernel documentation on hardware vulnerabilities] を参照してください。

既知の脆弱性の影響を受けているかどうかを確認するには、以下を実行してください。

$ grep -r . /sys/devices/system/cpu/vulnerabilities/

ほとんどの場合、カーネルとマイクロコードを更新することで、脆弱性を軽減することができます。

==== 同時マルチスレッディング (ハイパースレッディング) ====

[https://ja.wikipedia.org/wiki/%E5%90%8C%E6%99%82%E3%83%9E%E3%83%AB%E3%83%81%E3%82%B9%E3%83%AC%E3%83%83%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0 同時マルチスレッディング]] (SMT) は、インテル CPU のハイパースレッディングとも呼ばれ、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html L1 Terminal Fault] および [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html Microarchitectural Data Sampling] 脆弱性の原因となる可能性のあるハードウェア機能です。Linux カーネルとマイクロコードのアップデートには、既知の脆弱性に対する緩和策が含まれていますが、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html#virtualization-with-untrusted-guests 信頼できない仮想化ゲストが存在する場合、特定の CPU で SMT を無効にしたほうが良い場合があります。]

SMT は、システムのファームウェアで無効にできることがよくあります。詳細については、マザーボードまたはシステムのドキュメントを参照してください。また、以下の [[カーネルパラメータ]] を追加することで、カーネルで SMT を無効にすることができます。

l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force

== メモリ ==

===ハード化された malloc ===

[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened_malloc}}, {{AUR|hardened-malloc-git}}) は [https://ja.wikipedia.org/wiki/GNU_C%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA glibc] の malloc() をハード化した代替品です。元々は Android の [[Wikipedia:Bionic (software)|Bionic]] と [https://ja.wikipedia.org/wiki/Musl musl] に組み込むために開発されましたが、 x86_64 アーキテクチャの標準 Linux ディストリビューションのサポートにも組み込みました。

hardened_malloc はまだ glibc に統合されていませんが(支援とプルリクエストは歓迎します)、LD_PRELOAD と一緒に簡単に使用することができます。これまでのテストでは、 {{ic|/etc/ld.so.preload}} でグローバルに有効にすると、一握りのアプリケーションにしか問題を起こしません。例えば、{{ic|getrandom}} が標準のホワイトリストにないため、{{ic|seccomp}} 環境フラグが無効でないと {{ic|man}} は正常に動作しませんが、これはシステムコールを追加して再構築すれば簡単に修正可能です。hardened_malloc は性能上のコストがあるので、どの実装を使うかは攻撃対象領域と性能上の必要性に基づいてケースバイケースで決めるとよいでしょう。

スタンドアロンで試すには、hardened-malloc-preload ラッパースクリプトを使用するか、適切なプリロード値でアプリケーションを手動で開始します。

LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox

[[Firejail]] の正しい使い方は、その wiki ページにあります。また、hardened_malloc の設定可能なビルドオプションは、githubレポで見つけることができます。

== ストレージ ==

===ディスク暗号化===

[[ディスク暗号化]]、特に [[#パスワード|強力なパスフレーズ]] を使用したフルディスク暗号化は、物理的な回復からデータを守る唯一の方法です。これにより、コンピュータの電源がオフになっている場合や、対象のディスクがアンマウントされている場合にデータの機密性が保たれます。

ただし、コンピュータの電源が入っており、ドライブがマウントされている場合、そのデータは暗号化されていないドライブと同様に脆弱です。そのため、データパーティションがもう必要なくなったら、できるだけ早くアンマウントすることが最良の実践です。

また、[[Trusted Platform Module#LUKS による保存データの暗号化|TPMにキーを保存してドライブを暗号化]] することもできますが、過去に [https://tpm.fail 脆弱性] があり、キーは [https://pulsesecurity.co.nz/articles/TPM-sniffing TPMバススニッフィング攻撃] によって抽出される可能性があります。

[[dm-crypt]] のような特定のプログラムは、ユーザーが仮想ボリュームとしてループファイルを暗号化できるようにします。これは、システムの特定の部分だけを安全に保護する必要がある場合、フルディスク暗号化の合理的な代替手段です。

[[ディスク暗号化]] の記事で比較されているブロックデバイスやファイルシステムベースの暗号化方法は、物理メディア上のデータ保護には有効ですが、リモートシステム(例えば [[保存データ暗号化#クラウドストレージの最適化|クラウドストレージ]])に保存されたデータを保護するためには使用できません。そのため、個々のファイル暗号化が役立つ場合もあります。

ファイルを暗号化するためのいくつかの方法は次の通りです:

* 一部の [[アーカイブと圧縮|アーカイブおよび圧縮]] ツールは基本的な暗号化も提供します。例としては、[[7-Zip]] ({{ic|-p}} フラグ)、{{Pkg|zip}} ({{ic|-e}}フラグ) があります。これらのツールはクロスプラットフォームの互換性のためにカスタムアルゴリズムを使用している場合があるため、特別な注意を払って使用するべきです。[https://math.ucr.edu/~mike/zipattacks.pdf]
* [[GnuPG]] を使用してファイルを [[GnuPG#Encrypt and decrypt|暗号化]] できます。
* {{Pkg|age}} は、シンプルで使いやすいファイル暗号化ツールです。複数の受信者をサポートしており、SSH キーを使用した暗号化もサポートしているため、安全なファイル共有に役立ちます。

=== ファイルシステム ===

現在カーネルは {{ic|fs.protected_hardlinks}} や {{ic|fs.protected_symlinks}} sysctl スイッチが有効になっていればハードリンクやシンボリックリンクに関するセキュリティの問題を解決するので、world-writable なディレクトリを分離させるセキュリティ的な利点はもはや存在しません。

それでもディスク容量が消耗したときのダメージを低減させる荒っぽい方法として world-writable なディレクトリを含むパーティションが分割されることがあります。しかしながら、サービスを落とすには {{ic|/var}} や {{ic|/tmp}} などのパーティションを一杯にするだけで十分です。この問題の対処についてはもっと柔軟性のある方法が存在します (クォータなど)、またファイルシステムによっては関連する機能を持っていることがあります (btrfs はサブボリュームにクォータを設定できます)。

====マウントオプション====

最小特権の原則に従い、ファイルシステムは可能な限り制限の厳しいマウントオプションを使用してマウントするべきです(機能を失わない範囲で)

関連するマウントオプションは以下の通りです:

* {{ic|nodev}}: ファイルシステム上のキャラクタデバイスやブロックデバイスを解釈しない。
* {{ic|nosuid}}: set-user-identifier や set-group-identifier ビットを無効にする。
* {{ic|noexec}}: マウントされたファイルシステム上のバイナリを直接実行できないようにする。
** {{ic|/home}} に {{ic|noexec}} を設定すると、実行可能なスクリプトが禁止され、[[Wine]]、[[Steam]]、PyCharm、[[.NET]] などが動作しなくなります。
*** Wine は Windows バイナリの実行に {{ic|exec}} フラグを必要としません。ただし、Wine 自体を {{ic|/home}} にインストールする場合は必要です。
*** [[Steam]] を動作させるには、{{ic|/home/user/.local/share/Steam}} を [[fstab]] で {{ic|exec}} としてマウントできます。以下の設定を追加してください: {{bc|/home/user/.local/share/Steam /home/user/.local/share/Steam none defaults,bind,user,exec,nofail 0 0}}
** 一部のパッケージ(例:{{Pkg|nvidia-dkms}} のビルド)では、{{ic|/var}} に {{ic|exec}} が必要な場合があります。

データ用のファイルシステムは、常に {{ic|nodev}}、{{ic|nosuid}}、{{ic|noexec}} を指定してマウントするべきです。

マウントを検討すべきファイルシステム:

* {{ic|/var}}
* {{ic|/home}}
* {{ic|/dev/shm}}
* {{ic|/tmp}}
* {{ic|/boot}}

{{Tip|[[systemd#GPT パーティションの自動マウント|GPT パーティションの自動マウント]] を使用する場合、ESP および XBOOTLDR パーティションは [https://github.com/systemd/systemd-stable/commit/49804cfb71d3a79f433096e4cfb5616980171336 常に {{ic|noexec,nosuid,nodev}} で強化] されます。}}

==== スナップショット ====

ファイルシステムのスナップショットを利用する場合(例えば [[Btrfs]]、[[LVM]]、[[ZFS]] など)、スナップショットがユーザーが削除したと期待している機密情報を保持する可能性があることを理解することが重要です。特に、[[Snapper]] のような自動スナップショットツールを設定している場合、定期的またはシステムイベントに応じてスナップショットが作成されるため、この問題が発生しやすくなります。

以下は、{{ic|/home/}} 内の機密情報がスナップショットに残存する例です:

* 削除されたファイルやディレクトリ: ファイルシステム上から削除されたとしても、古いスナップショット内には残存している可能性があります。これは通常想定される動作ですが、{{ic|.local/share/Trash/}}、{{ic|.history}} などのファイルやディレクトリを保持する必要があるかどうかを検討すべきです。
* 一時ファイルやキャッシュ: アプリケーションによって生成された一時ファイルやキャッシュデータもスナップショットに含まれる可能性があります。例えば、暗号化されたディレクトリ内のファイルを開くと、サムネイル({{ic|.cache/thumbnails}})や作業用のコピーが作成され、それらがスナップショットに含まれる可能性があります。同様に、ブラウザの履歴({{ic|.mozilla/}}、{{ic|.config/chromium/}} など)も、削除される前にスナップショットに記録されている場合があります。

対応可能であれば、これらのディレクトリをスナップショットの対象から完全に除外することを検討してください。例えば、[[Btrfs]] を使用している場合、{{ic|.cache/}}、{{ic|.config/}}、{{ic|.local/}}、{{ic|.var/}} など、用途に応じたディレクトリをサブボリュームとして作成することで、スナップショットの影響を受けにくくできます。

{{Note|{{ic|.local/share/Trash}} を別のサブボリュームに移動すると、場合によっては [[GNOME/Files]] などでゴミ箱の機能が正常に動作しなくなる可能性があります。}}

===ファイルシステムのパーミッション===

デフォルトの [[パーミッション]] では、ほとんどのファイルが読み取り可能になっていますが、これを変更することで、{{ic|http}} ユーザーや {{ic|nobody}} ユーザーなどの非 root アカウントに侵入した攻撃者から貴重な情報を隠すことができます。[[chmod]] を使用して、グループやその他のユーザーからすべてのアクセス権を削除できます。

# chmod go-r ''path_to_hide''

{{Warning|この設定を広範囲に適用しないでください。1つの設定ファイルごとに適用し、非表示にする価値があるか、プログラムの動作に影響しないかを確認してください。グループが必要な場合は、{{ic|g}} をコマンドから削除するか、既に実行してしまった場合は {{ic|chmod g+r path}} で再度許可を追加する必要があるかもしれません。}}

考慮すべきパスの例:

* {{ic|/boot}}: [[パーティショニング#/boot|ブートディレクトリ]]、[[vmlinuz]] や [[initramfs]] image、または [[ユニファイドカーネルイメージ]] が含まれる場合があります。なお、[[systemd# GPT パーティションの自動マウント]] を使用する場合、デフォルトで安全なパーミッションが適用されます。
* {{ic|/etc/nftables.conf}}: [[nftables]] の設定ファイル({{Pkg|nftables}} および {{Pkg|iptables-nft}} に適用)
* {{ic|/etc/iptables}}: レガシーな [[iptables]] の設定ファイル({{Pkg|iptables}} に適用)

また、新しく作成されるファイルのセキュリティを向上させるために、デフォルトの [[umask]] 値 {{ic|0022}} を変更することも可能です。[https://apps.nsa.gov/iaarchive/library/ia-guidance/security-configuration/operating-systems/guide-to-the-secure-configuration-of-red-hat-enterprise.cfm NSA RHEL5 Security Guide] では最大限のセキュリティを確保するために、{{ic|0077}} を推奨しており、これにより所有者以外のユーザーが新しいファイルを読み取れなくなります。変更方法については [[Umask#マスクの値を設定]] を参照してください。

さらに、[[sudo]] を使用する場合、[[Sudo#Permissive umask|デフォルトの root umask]] を適用するよう設定することを検討してください。

=== SUID ファイルと SGID ファイル ===

[[Wikipedia:ja:Setuid|Setuid]] ビットや Setgid ビットが設定されたファイルには注意しましょう。このようなファイルの例としては、以下があります。これらは {{ic|/usr/bin}} 内にあり、SUID ビットが設定されていて、root によって所有されています:

* gpasswd
* [[Poklit|pkexec]]
* [[sudo]] [[doas]]
* [[su]] ksu
* [[passwd]]
* [[firejail]]
* [[Chromium|chromium-sandbox]]

このような実行ファイルの主なリスクとして、特権昇格の脆弱性があります。例えば [[Wikipedia:Setuid#Security impact]] を参照してください。[https://www.cvedetails.com/vulnerability-list/vendor_id-16224/product_id-36412/Calibre-ebook-Calibre.html][https://www.cvedetails.com/product/32625/Sudo-Project-Sudo.html?vendor_id=15714][https://www.cvedetails.com/vulnerability-list/vendor_id-16191/Firejail-Project.html]

SUID ビットが設定されているが root によって所有されていないファイル、または SGID ビットが設定されているファイルは、''典型的には''潜在的なリスクがより小さいですが、理論上、そのようなファイルに脆弱性が存在している場合は、依然として損害を与える可能性があります。通常、代わりに[[ケイパビリティ]]を割り当てることによって、Setuid や Setgid の使用を回避することが可能です。

{{Tip|SUID/SGID 実行ファイルを含むパッケージを最新に保って、脆弱性からシステムを守ることが肝心です。}}

SUID ビットか SGID ビットを持つファイルを {{ic|/usr/bin}} から探すには:

$ find /usr/bin -perm "/u=s,g=s"

== ユーザー設定 ==

=== root アカウントを日常的に使用しない ===

最小特権の原則に従い、root ユーザーを日常的に使用しないようにしてください。システムを使用する各人に非特権ユーザーアカウントを作成するか。一時的な特権アクセスには、必要に応じて [[sudo]] を使用する。

=== ログイン失敗後の遅延時間の設定 ===

以下の行を {{ic|/etc/pam.d/system-login}} に追加し、ログインに失敗した際に最低4秒の遅延を追加します。

{{hc|/etc/pam.d/system-login|2=
auth optional pam_faildelay.so delay=4000000
}}

{{ic|4000000}} は遅延させる時間をマイクロ秒単位で指定します。

===3回ログインを失敗したユーザーをロックアウトする===

{{Pkg|pambase}} 20200721.1-2 の時点では、デフォルトで {{ic|pam_faillock.so}} が有効になっており、15分間に3回ログインに失敗すると10分間ユーザをロックアウトします ({{Bug|67644}} を参照してください) このロックアウトはパスワード認証 (例:ログインと ''sudo'') にのみ適用され、SSH 経由の公開鍵認証はそのまま利用可能です。完全なサービス拒否を防ぐために、このロックアウトは root では無効になっています。

ユーザーをロック解除するには、次のようにします。

$ faillock --reset --user ''username''

デフォルトでは、ロック機構は {{ic|/run/faillock/}} にあるユーザーごとのファイルです。ディレクトリの所有者は root ですが、ファイルの所有者はユーザーなので、 {{ic|faillock}} コマンドはファイルを空にするだけで、root は必要ありません。

モジュール {{ic|pam_faillock.so}} は、ファイル {{ic|1=/etc/security/faillock.conf}} で設定することが可能です。ロックアウトのパラメータです。

* {{ic|unlock_time}} - ロックアウト時間 (秒単位、デフォルトは10分)
* {{ic|fail_interval}} - ロックアウトに失敗するとロックアウトされる時間 (秒単位、デフォルトは15分)
* {{ic|deny}} - ロックアウトするまでに何回ログインに失敗するか (デフォルトは 3)

{{Note|{{ic|1=deny = 0}} はロックアウトを無効化します}}

デフォルトでは、すべてのユーザーロックは再起動後に失われます。攻撃者がマシンをリブートできるのであれば、ロックは持続させた方が安全です。ロックを持続させるには、{{ic|1=/etc/security/faillock.conf}} の {{ic|dir}} パラメータを {{ic|/var/lib/faillock}} に変更する必要があります。

変更を反映させるために再起動する必要はありません。root アカウントのロックアウトを有効にする、集中ログイン (LDAP など) を無効にするなど、さらなる設定オプションについては {{man|5|faillock.conf}} を参照してください。

=== プロセスの数を制限する ===

信頼できないユーザーが大量に存在するシステムでは、一度に実行できるプロセスの数を制限して、[[Wikipedia:ja:Fork爆弾|フォーク爆弾]]などのサービス拒否攻撃を予防することが重要です。ユーザーやグループごとに実行できるプロセスの数は {{ic|/etc/security/limits.conf}} で定義することができ、デフォルトでは空になっています。以下の値をファイルに追加すると、実行できるプロセスが100個までに制限されます。{{ic|prlimit}} コマンドを使って一時的に上げられる最大数も200個までに制限します。ユーザーが普段実行するプロセスの数や、管理するハードウェアにあわせて適切な値に変更してください。

* soft nproc 100
* hard nproc 200

=== Wayland を使用する ===

[[Xorg]] よりも [[Wayland]] を使用することをお勧めします。Xorg の設計は現代のセキュリティ慣行より古く、多くの人が [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 は安全でないと考えています] 例えば、Xorg のアプリケーションは非アクティブな状態でもキーストロークを記録することがあります。

もし Xorg を実行しなければならないなら、[[Xorg#Rootless_Xorg|root での実行を避ける]]ことが推奨されます。Wayland 内では、XWayland 互換レイヤーは自動的に root レス Xorg を使用します。

== root の制限 ==
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。

=== su の代わりに sudo を使う ===
[[Su#セキュリティ|色々な理由]]から特権アクセスには [[su]] よりも [[sudo]] を使うほうが好ましいとされます。

* 通常の権限しか持たないユーザーが実行した特権コマンドのログを保持します。
* root アクセスを必要とする各ユーザーに root ユーザーのパスワードを与える必要がありません。
* 完全な root ターミナルは作成されないため、{{ic|sudo}} は root アクセスが必要ないコマンドを偶発的に ''root'' で実行してしまうことを防止します。これは[[Wikipedia:ja:最小権限の原則|最小権限の原則]]と合っています。
* 一つのコマンドを実行するためだけに完全な root アクセスを与える代わりに、ユーザーごとに個々のプログラムを有効にすることができます。例えば、ユーザー ''alice'' に特定のプログラムへのアクセス権限を与えるには:

# visudo

{{hc|/etc/sudoers|
alice ALL = NOPASSWD: /path/to/program}}

また、全てのユーザーに個別のコマンドを許可することも可能です。通常ユーザーでサーバーから Samba 共有をマウントするには:

%users ALL=/sbin/mount.cifs,/sbin/umount.cifs

これによって users グループのメンバーである全てのユーザーが全てのマシン (ALL) から {{ic|/sbin/mount.cifs}} や {{ic|/sbin/umount.cifs}} コマンドを実行できるようになります。

{{Tip|{{ic|visudo}} で {{ic|vi}} の代わりに {{ic|nano}} を使うには:

{{hc|/etc/sudoers|
2=Defaults editor=/usr/bin/rnano
}}
{{ic|1=# EDITOR=nano visudo}} のエクスポートは何にでも {{ic|EDITOR}} として使うことができるためにセキュリティリスクとされています。
}}

==== sudo を使ってファイルを編集する ====
root で {{ic|vim}} などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:

export SUDO_EDITOR=rvim

ファイルの編集には {{ic|sudoedit filename}} または {{ic|sudo -e filename}} を使って下さい。自動的に {{ic|rvim}} によって {{ic|filename}} が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。

=== root ログインの制限 ===
[[sudo]] を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。[[sudo]] を使える状態のまま root を無効化したい場合、{{ic|passwd -l root}} を使用します。

==== 特定のユーザーだけに許可を与える ====
[[Wikipedia:Pluggable authentication module|PAM]] の {{ic|pam_wheel.so}} は {{ic|wheel}} グループに入っているユーザーだけに {{ic|su}} を使用したログインを許可します。{{ic|/etc/pam.d/su}} と {{ic|/etc/pam.d/su-l}} の両方を編集して次の行をアンコメントしてください:
{{bc|<nowiki>
# Uncomment the following line to require a user to be in the "wheel" group.
auth required pam_wheel.so use_uid
</nowiki>}}
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。

==== ssh ログインを拒否する ====
ローカルユーザーの root ログインを拒否したくない場合でも、[[SSH#root ログインを拒否する|SSH による root ログインを拒否]]するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。

==== access.conf で許容されるログインの組み合わせを指定する ====

誰かが [[PAM]] でログインしようとすると、 {{ic|/etc/security/access.conf}} がそのログインプロパティに一致する最初の組み合わせをチェックします。そして、その組み合わせのルールに基づいて、試行が失敗するか成功するかが決まります。

+:root:LOCAL
-:root:ALL

特定のグループやユーザーに対してルールを設定することができます。この例では、ユーザー archie は、wheel および adm グループに属するすべてのユーザーと同様に、ローカルでのログインを許可されています。それ以外のログインは拒否されます。

+:archie:LOCAL
+:(wheel):LOCAL
+:(adm):LOCAL
-:ALL:ALL

詳しくは {{man|5|access.conf}} で確認してください。

==強制アクセス制御==

[[Wikipedia:ja:強制アクセス制御|強制アクセス制御]] (Mandatory Access Control, MAC) は Arch やほとんどの Linux ディストリビューションで使われている[[Wikipedia:ja:任意アクセス制御|任意アクセス制御]] (Discretionary Access Control, DAC) とは大きく異なるタイプのセキュリティポリシーです。原則的に MAC ではシステムに影響を与えるプログラムの行動は全てセキュリティルールセットによってチェックを受けます。このルールセットは、DAC とは対照的に、ユーザーが変更することは不可能です。実装方法は色々と異なるタイプが存在しますが、強制アクセス制御を使うことで実質的にコンピュータのセキュリティを著しく向上させることになります。

===パス名 MAC===
パス名ベースのアクセス制御は指定されたファイルのパスに基づいてパーミッションを与えるというシンプルな形式のアクセス制御です。この形式のアクセス制御の欠点としてはファイルが移動されてもパーミッションはファイルと一緒に付いていかないということが挙げられます。プラス面となるのは、パス名ベースの MAC はラベルベースの MAC と異なり、幅広いファイルシステムに実装できることです。

*[[AppArmor]] は [[Wikipedia:ja:カノニカル|Canonical]] によって開発されている MAC 実装で SELinux に比べて"簡単"になっています。
*[[TOMOYO Linux|Tomoyo]] はもうひとつのシンプルで、使いやすい強制アクセス制御を提供するシステムです。利用と実装の両面でシンプルになるように設計されており、依存するライブラリがとても少なくなっています。

===ラベル MAC===
ラベルベースのアクセス制御ではファイルの拡張属性を使ってセキュリティパーミッションを管理します。このシステムはセキュリティの機能においてパス名ベースの MAC よりも間違いなく柔軟性が高い一方、拡張属性をサポートしているファイルシステムでしか動作しません。

*[[SELinux]] は、Linux セキュリティを向上させる [[Wikipedia:ja:アメリカ国家安全保障局|NSA]] プロジェクトに基づいており、システムユーザーやロールとは完全に独立して MAC を実装しています。成長してオリジナルの設定が変わっていくシステムのコントロールを簡単に維持できる、極めて強固なマルチレベル MAC ポリシー実装を提供します。

=== アクセス制御リスト ===
[[アクセス制御リスト]] (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。

== カーネルの堅牢化 ==

=== カーネルの自己防衛機能/脆弱性攻撃対策 ===

{{pkg|linux-hardened}} パッケージは、[https://github.com/anthraxx/linux-hardened 基本的なカーネル堅牢化パッチセット]と、{{pkg|linux}} パッケージよりもセキュリティに重点を置いたコンパイル時設定オプションを使用します。カスタムビルドでは、セキュリティ寄りのデフォルトとは異なる、セキュリティと性能の妥協点を選択することができます。

しかし、このカーネルを使うといくつかのパッケージが動かなくなることに注意する必要があります。例えば

* {{AUR|skypeforlinux-preview-bin}}
* {{AUR|skypeforlinux-stable-bin}}
* {{pkg|throttled}}

[[NVIDIA]] などのアウトオブツリードライバを使用している場合、その [[DKMS]] パッケージに切り替える必要があるかもしれません。

==== ユーザー空間 ASLR の比較 ====

{{pkg|linux-hardened}} パッケージは、アドレス空間配置ランダム化の改善された実装をユーザ空間のプロセスに対して提供します。{{pkg|paxtest}} コマンドを使うことで、提供されるエントロピーの推定値を得ることができます:

===== 64 ビットプロセス =====

{{hc|linux-hardened 5.4.21.a-1-hardened|
Anonymous mapping randomization test : 32 quality bits (guessed)
Heap randomization test (ET_EXEC) : 40 quality bits (guessed)
Heap randomization test (PIE) : 40 quality bits (guessed)
Main executable randomization (ET_EXEC) : 32 quality bits (guessed)
Main executable randomization (PIE) : 32 quality bits (guessed)
Shared library randomization test : 32 quality bits (guessed)
VDSO randomization test : 32 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)
Randomization under memory exhaustion @~0: 32 bits (guessed)
Randomization under memory exhaustion @0 : 32 bits (guessed)
}}

{{hc|linux 5.5.5-arch1-1|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 20 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 29 bits (guessed)
Randomization under memory exhaustion @0 : 29 bits (guessed)
}}

{{hc|linux-lts 4.19.101-1-lts|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 19 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 28 bits (guessed)
Randomization under memory exhaustion @0 : 28 bits (guessed)
}}

===== 32 ビットプロセス (x86_64 カーネル上) =====

{{hc|linux-hardened|
Anonymous mapping randomization test : 16 quality bits (guessed)
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)
Heap randomization test (PIE) : 27 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 18 quality bits (guessed)
Shared library randomization test : 16 quality bits (guessed)
VDSO randomization test : 16 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)
Randomization under memory exhaustion @~0: 18 bits (guessed)
Randomization under memory exhaustion @0 : 18 bits (guessed)
}}

{{hc|linux|
Anonymous mapping randomization test : 8 quality bits (guessed)
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)
Heap randomization test (PIE) : 13 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 8 quality bits (guessed)
Shared library randomization test : 8 quality bits (guessed)
VDSO randomization test : 8 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)
Randomization under memory exhaustion @~0: No randomization
Randomization under memory exhaustion @0 : No randomization
}}

=== proc ファイルシステム内のカーネルポインタへのアクセスを制限する ===

{{ic|kernel.kptr_restrict}} を 1 に設定すると、{{ic|CAP_SYSLOG}} を持たない通常ユーザから {{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが秘匿され、カーネルのエクスプロイトで動的にアドレス/シンボルを解決することが困難になります。これは、事前にコンパイルされた Arch Linux カーネルではあまり意味がありません。周到な攻撃者はカーネルパッケージをダウンロードして、そこから手動でシンボルを取得することができるからです。しかしながら、自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし、一部の {{Pkg|perf}} コマンドの機能が、root 以外のユーザによって使用されば場合に破壊されます (しかし、いずれにせよ多くの {{Pkg|perf}} コマンドは root アクセスを必要とします)。詳細は {{Bug|34323}} を参照してください。

{{ic|kernel.kptr_restrict}} を 2 に設定すると、{{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが権限に依らず隠されます。

{{hc|/etc/sysctl.d/51-kptr-restrict.conf|2=
kernel.kptr_restrict = 1
}}

{{Note|{{pkg|linux-hardened}} はデフォルトで {{ic|0}} ではなく {{ic|1=kptr_restrict=2}} を設定します。}}

=== BPF の堅牢化 ===

BPF は、実行時にカーネル内のバイトコードを動的にロードして実行するために使用されるシステムです。ネットワーク (XDP, tc など)、トレース (kprobes, uprobes, tracepoints など)、セキュリティ (seccomp など) など、多くの Linux カーネルサブシステムで使用されています。また、高度なネットワークセキュリティ、パフォーマンスプロファイリング、ダイナミックトレースにも有効です。

BPF はもともと [[Wikipedia:ja:Berkeley Packet Filter|Berkeley Packet Filter]] の頭文字をとったもので、オリジナルの古典的な BPF は BSD 用のパケットキャプチャツールに使われていたためです。これは最終的に拡張 BPF (eBPF) に発展し、その後まもなくただの BPF (頭字語ではありません) に改名されました。BPFはパケットフィルタリングツールの実装に使われることがありますが、 iptables や netfilter のようなパケットフィルタリングツールと混同しないでください。

BPF のコードは解釈されるか、[[Wikipedia:ja:実行時コンパイラ|Just-In-Time (JIT) コンパイラ]]を使ってコンパイルされるかのどちらかです。Arch のカーネルは {{ic|CONFIG_BPF_JIT_ALWAYS_ON}} でビルドされており、BPF インタープリタを無効にして全ての BPF を JIT コンパイラでコンパイルするよう強制しています。これにより、攻撃者が BPF を使って SPECTRE 型の脆弱性を悪用した特権昇格攻撃をすることが難しくなります。詳しくは、[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290af86629b25ffd1ed6232c4e9107da031705cb CONFIG_BPF_JIT_ALWAYS_ON を導入したカーネルパッチ]を参照してください。

カーネルは JIT コンパイルされた BPF に対して、パフォーマンスと多くの BPF プログラムをトレース・デバッグする能力を犠牲にして、ある種の JIT スプレー攻撃を軽減するための堅牢化機能を備えています。この機能は、{{ic|net.core.bpf_jit_harden}} を {{ic|1}} (非特権コードの堅牢化を有効化する) か {{ic|2}} (全てのコードの堅牢化を有効化する) に設定することで有効化できます。

詳しくは、[https://docs.kernel.org/admin-guide/sysctl/net.html カーネルドキュメント] の {{ic|net.core.bpf_*}} 設定を参照してください。

{{Tip|
* {{Pkg|linux-hardened}} では、デフォルトで {{ic|1=net.core.bpf_jit_harden=2}} が設定されており、{{ic|0}} ではありません。
* デフォルトでは、BPF プログラムは非特権ユーザでも実行可能です。この挙動を変更するには {{ic|1=kernel.unprivileged_bpf_disabled=1}} を設定してください [https://access.redhat.com/security/cve/cve-2021-33624]。
}}

=== ptrace スコープ ===

{{man|2|ptrace}} システムコールは、あるプロセス ("tracer") が他のプロセス ("tracee") の実行を監視、制御し、tracee のメモリとレジスタを検査、変更するための手段を提供します。通常、{{ic|ptrace}} は ''gdb'' や ''strace''、''perf''、''reptyr'' などのデバッグツールによって使用されます。しかし、他のプロセスからデータを読んだり、他のプロセスの制御を奪ったりする手段を悪意のあるプロセスにも提供してしまいます。

Arch では、{{ic|kernel.yama.ptrace_scope}} [[カーネルパラメータ]]を提供する [https://docs.kernel.org/admin-guide/LSM/Yama.html Yama LSM] がデフォルトで有効化されています。このパラメータはデフォルトで {{ic|1}} (制限) に設定されており、{{ic|CAP_SYS_PTRACE}} [[ケイパビリティ]]も特権も持たない tracer が制限されたスコープ外で {{ic|ptrace}} コールを実行できないようにしています。これは、古典的なパーミッションと比べてセキュリティ上大きな改善です。このモジュールが無いと、同じユーザとして実行されているプロセスを隔てるものがなくなってしまいます ({{man|7|pid_namespaces}} などの他のセキュリティレイヤーがない場合)。

{{Note|デフォルトでは、[[sudo]] を使うなどして、{{ic|ptrace}} を必要とするツールを特権プロセスとして実行することができます。}}

デバッグツールを使う必要がない場合は、システムを堅牢化するために {{ic|kernel.yama.ptrace_scope}} を {{ic|2}} (管理者限定) や {{ic|3}} ({{ic|ptrace}} を禁止) に設定することを検討してください。

=== hidepid ===

{{Warning|
* これは、サンドボックスと [[Xorg]] 内で実行するアプリケーションなど、特定のアプリケーションで問題を発生させる場合があります (回避策を見てください)。
* {{Pkg|systemd}} > 237.64-1 を使用している場合、これは [[D-Bus]]、[[Polkit]]、[[PulseAudio]]、そして [[bluetooth]] で問題を発生させます。
}}

カーネルには、{{ic|proc}} ファイルシステムを {{ic|1=hidepid=}} オプションと {{ic|1=gid=}} オプションを使ってマウントすることで、他のユーザのプロセス (通常、{{ic|/proc}} でアクセス可能) を非特権ユーザから秘匿する機能があります。これらのマウントオプションは https://docs.kernel.org/filesystems/proc.html でドキュメント化されています。

これにより、侵入者が動作中のプロセスの情報 (特権で動作しているデーモンがあるか、他のユーザが機密情報を扱うプログラムを実行しているか、他のユーザがプログラムを実行しているか) を得る作業を複雑化し、ユーザが特定のプログラムを実行しているかどうかを知るのを不可能にし (ただし、そのプログラムがそれ自体の挙動で存在を他者に知られることがないとする)、さらに、貧弱に書かれたプログラムが機密情報をプログラム引数を介して渡したとしてもローカルの盗聴者から守られます。

{{ic|proc}} [[ユーザーとグループ#システムグループ#グループ]] ({{Pkg|filesystem}} パッケージによって提供されています) は、他のユーザのプロセス情報を得ることのできるユーザのホワイトリストとして機能します。ユーザやサービスが自身以外の {{ic|/proc/<pid>}} ディレクトリにアクセスする必要がある場合、そのユーザまたはサービスを[[ユーザーとグループ#グループ管理|proc グループに追加してください]]。

例えば、プロセスの情報を {{ic|proc}} グループに属さない他のユーザから隠すには:

{{hc|/etc/fstab|2=
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
}}

ユーザのセッションを正しく動作させるために、''systemd-logind'' を例外として追加する必要があります:

{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=
[Service]
SupplementaryGroups=proc
}}

=== モジュールのロードを制限する ===

デフォルトの Arch カーネルは {{ic|CONFIG_MODULE_SIG_ALL}} が有効で、{{Pkg|linux}} パッケージの一部としてビルドされた全てのカーネルモジュールに署名します。これにより、カーネルは有効なキーで署名されたモジュールだけをロードするように制限できます。実際、これはローカルでコンパイルされた、もしくは {{Pkg|virtualbox-host-modules-arch}} などのパッケージによって提供された、ツリー外のモジュールは全てロードできないことを意味します。

カーネルモジュールの読み込みは {{ic|1=module.sig_enforce=1}} [[カーネルパラメータ]]を設定することで制限することができます。詳細は[https://docs.kernel.org/admin-guide/module-signing.html カーネルドキュメント]で見られます。

=== kexec を無効にする ===

Kexec は、現在実行中のカーネルを置き換えることを可能にします。

{{hc|/etc/sysctl.d/51-kexec-restrict.conf|2=
kernel.kexec_load_disabled = 1
}}

{{Tip|kexec は {{pkg|linux-hardened}} でデフォルトで無効になっています。}}

=== カーネルロックダウンモード ===

Linux 5.4 から、オプションの[https://mjg59.dreamwidth.org/55105.html ロックダウン機能]がカーネルに[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d 追加されました]。これは、UID 0 (root) とカーネルの間の境界を強化することを目的としています。この機能を有効にすると、ハードウェアやカーネルへの低レベルなアクセスに依存している一部のアプリケーションは動作しなくなる可能性があります。

ロックダウンを使用するには、LSM が初期化され、ロックダウンモードが設定されている必要があります。

[[カーネル#公式サポートカーネル|公式にサポートされているカーネル]]は全て LSM を初期化しますが、ロックダウンモードを強制しません。

{{Tip|有効化されている LSM は {{ic|cat /sys/kernel/security/lsm}} を実行することで確認することができます。}}

ロックダウンには2つの動作モードがあります:

* {{ic|integrity}}: ユーザーランドが実行中のカーネルを変更できるカーネル機能 (kexec、bpf) は無効化されます。
* {{ic|confidentiality}}: ユーザーランドがカーネルから機密情報を抽出するためのカーネルの機能も無効化されます。

特定の脅威モデルで指示がない限り、{{ic|integrity}} を使用することが推奨されます。

実行時にカーネルのロックダウンを有効にするには、以下を実行してください:

# echo ''mode'' > /sys/kernel/security/lockdown

起動時にカーネルのロックダウンを有効にするには、{{ic|1=lockdown=''mode''}} [[カーネルパラメータ]]を使用してください:

{{Note|
* カーネルロックダウンを実行時に無効化することはできません。
* カーネルロックダウンは、[[ハイバネート]]を無効化します。
}}

{{man|7|kernel_lockdown}} も参照してください。

=== Linux Kernel Runtime Guard (LKRG) ===

[https://www.openwall.com/lkrg/ LKRG] ({{AUR|lkrg-dkms}}) は、カーネルの整合性チェックとエクスプロイト行為の検出を行うカーネルモジュールです。

== アプリケーションのサンドボックス化 ==

こちらも参照 [[Wikipedia:ja:サンドボックス (セキュリティ)]]

{{Note|ユーザー名前空間の設定項目 {{ic|CONFIG_USER_NS}} は、現在 {{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}}、および {{Pkg|linux-hardened}} で有効になっています。これが無効だと、一部のアプリケーションで特定のサンドボックス機能が利用できなくなる可能性があります。}}

{{Warning|非特権ユーザー名前空間の使用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) は、{{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}} でデフォルトで有効になっています。これにより、ローカル特権昇格の攻撃対象が大幅に拡大します([https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction AppArmorのWiki] および {{Bug|36969}} を参照。}}

これを軽減するためには、次のいずれかを行ってください:

* 安全なデフォルトを持つ {{Pkg|linux-hardened}} カーネルを使用する、または
* {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] を {{ic|0}} に設定する。

これにより、[[Zoom Meetings|Zoom]] や {{pkg|nsjail}} などのアプリケーションが動作しなくなる場合があることに注意してください。また、システムに {{pkg|bubblewrap}} がインストールされている場合は、{{pkg|bubblewrap-suid}} に置き換える必要があります。詳細は [[Bubblewrap#インストール]] を参照してください。

=== Firejail ===

[[Firejail]] は、アプリケーションやサーバーをサンドボックス化するための使いやすいツールです。元々はブラウザやインターネット向けアプリケーションのために作成されましたが、現在では多くのアプリケーションに対応しています。さまざまな機能を備えたサンドボックス環境を構築するために、suid バイナリとしてインストールされ、ブラックリストとホワイトリストに基づいてターゲットアプリケーションのサンドボックス化された実行環境を構築します。

=== bubblewrap ===

[[bubblewrap]] は、[[Flatpak]] などの非特権コンテナツール向けに開発されたサンドボックスアプリケーションで、Firejail よりもリソース消費と複雑さが大幅に小さいです。ファイルパスのホワイトリスト機能は欠けていますが、bubblewrap はバインドマウントのほか、ユーザー/IPC/PID/ ネットワーク /cgroup 名前空間の作成をサポートしており、シンプルなものから複雑なサンドボックスまで対応可能です。

[[Bubblejail]] サンドボックスは [[bubblewrap]] を基にしており、リソース指向の権限モデルと、権限を調整するためのグラフィカルインターフェースを提供します。

=== chroot ===

手動で [[chroot]] してサンドボックス化されたプロセス環境を作成できます。しかし、これは他のサンドボックス技術に比べて非常に制限されています。そのサンドボックス化の範囲はファイルパスの隔離に限られています。

=== Linux Containers ===

[[Linux Containers]] は、他のオプション([[#完全な仮想化オプション|完全な仮想化オプション]] を除く) よりも多くの隔離が必要な場合に適した選択肢です。LXC は、既存のカーネルの上で擬似 chroot 内で実行され、独自の仮想ハードウェアを持っています。

=== 完全な仮想化オプション ===

[[VirtualBox]]、[[KVM]]、[[Xen]]、または [https://www.qubes-os.org/ Qubes OS](Xen ベース)などの完全仮想化オプションを使用することで、リスクの高いアプリケーションを実行したり、危険なウェブサイトを閲覧したりする場合に、隔離とセキュリティを強化することができます。

==ネットワークとファイアウォール==

===ファイアウォール===

標準の Arch カーネルは [[Wikipedia:Netfilter|Netfilter]] の [[iptables]] および [[nftables]] を使用できますが、これらのサービスはデフォルトで [[有効化]] されていません。システム上で実行されているサービスを保護するために、何らかの形のファイアウォールを設定することを強く推奨します。多くのリソース(ArchWiki など)では、どのサービスを保護するべきかが明示的に記載されていないため、ファイアウォールを有効にすることは良い予防措置となります。

* 一般的な情報については [[iptables]] および [[nftables]] を参照してください。
* iptables ファイアウォールの設定方法については [[シンプルなステートフルファイアウォール]] を参照してください。
* netfilter の設定方法については [[ファイアウォール]] を参照してください。
* Bluetack などの IP アドレスリストをブロックするには [[Ipset]] を参照してください。
* {{Pkg|opensnitch}} は、アプリケーション、ポート、ホストなどによる設定可能なルールをサポートする、構成可能なインバウンドおよびアウトバウンドファイアウォールです。

==== ポートを開く ====

一部のサービスは、開かれたネットワークポートでインバウンドトラフィックを待ち受けます。これらのサービスは、必要最低限のアドレスとインターフェースにのみバインドすることが重要です。リモート攻撃者が [https://samy.pl/slipstream/ ネットワークプロトコルの欠陥を悪用して公開されたサービスにアクセスする] 可能性があります。これは、[https://nvd.nist.gov/vuln/detail/CVE-2019-13450 localhost にバインドされたプロセス] にも発生することがあります。

一般的に、サービスがローカルシステムのみでアクセス可能であれば、非ループバックアドレス(例えば {{ic|0.0.0.0/0}})ではなく、Unix ドメインソケット({{man|7|unix}})や {{ic|localhost}} のようなループバックアドレスにバインドするべきです。

サービスがネットワーク越しに他のシステムからアクセス可能である必要がある場合、厳格な [[ファイアウォール]] ルールでアクセスを制御し、可能な限り認証、認可、暗号化を構成することが重要です。

現在のすべてのオープンポートをリストするには、{{ic|ss -l}} を使用できます。すべてのリスニング中のプロセスとその数値的な TCP および UDP ポート番号を表示するには:

# ss -lpntu

その他のオプションについては、{{man|8|ss}}を参照してください。

===カーネルパラメータ===
ネットワークに影響を与えるカーネルパラメータは [[sysctl]] を使って設定できます。設定方法は [[sysctl#TCP/IP スタックの防御]] を見て下さい。

===SSH===
[[SSH 鍵#パスワードログインの無効化|SSH 鍵を必要]]としない [[Secure Shell]] を使うのは避けましょう。これは[[Wikipedia:ja:総当たり攻撃|総当たり攻撃]]を防ぎます。また、[[Fail2ban]] や [[Sshguard]] はログを監視して [[iptables|iptables ルール]]を書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。

二段階認証によって認証を強化することができます。[[Google Authenticator]] はワンタイムパスコード (OTP) を使用する二段階認証方式を提供します。

[[Secure Shell#root ログインを拒否する|root ログインを拒否する]]のは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。

===DNS===

[[DNSSEC]] や [[DNSCrypt]] を見て下さい。

=== プロキシ ===

プロキシはアプリケーションとネットワークの間に挟まる追加レイヤーとして使われ、信頼できないソースからのデータをサニタイズします。少ない権限でプロキシを動作させることで、エンドユーザー権限で複雑なアプリケーションを実行するよりも攻撃対象を小さくすることができます。

例えば {{Pkg|glibc}} の中に実装されている DNS リゾルバを考えてみてください。(root で実行することもある) アプリケーションにリンクされている DNS リゾルバにバグが存在した場合、リモートコード実行につながる危険があります。[[dnsmasq]] などの DNS キャッシュサーバーをインストールしてプロキシとして使うことで問題を防ぐことが可能です [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]。

=== SSL 証明書の管理 ===

サーバーサイドの SSL 証明書の管理については [[OpenSSL]] や [[Network Security Services]] (NSS) を参照してください。また、関連する [[Let’s Encrypt]] プロジェクトも見てください。

デフォルトのインターネット SSL 証明書のトラストチェーンは {{Pkg|ca-certificates}} パッケージによって提供されています。Arch はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: {{AUR|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) に依存しています。

デフォルトの証明書を変えたいと思うことがあるかもしれません。例えば、[http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ ニュース] を読んで証明書を信頼しないようにしたい場合 (ソースのプロバイダーによって無効になるのを待てない場合)、Arch のインフラを使うことで簡単に設定できます:
# {{ic|.crt}} 形式の証明書を入手してください (例: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; 既存のルート認証局の場合、システム内にあるはずです)。
# {{ic|/etc/ca-certificates/trust-source/blacklist/}} にコピーしてください。
# root で ''update-ca-trust'' を実行してください。

お好きなブラウザを開いて'''信頼できない'''サイトとして表示されれば、ブラックリストが上手く機能しています。

== 物理セキュリティ ==

{{Note|リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。}}

十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで''実用的で''高いレベルのセキュリティを得ることができます。

攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [http://www.breaknenter.org/projects/inception/]。これを防ぐためにできることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識がなく実行されることはほとんどありません。

[[#ディスク暗号化|ディスク暗号化]]はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。

===BIOS をロックダウンする===

BIOS にパスワードを追加することによってリムーバブルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。

=== ブートローダー ===

[[Arch ブートプロセス#ブートローダー|ブートローダー]] を保護することは非常に重要です。保護されていないブートローダは、例えば {{ic|1=init=/bin/sh}} を設定することでログインの制限を回避することができます。[[カーネルパラメータ]] でシェルに直接ブートするようにします。

==== Syslinux ====

Syslinux は[[Syslinux#セキュリティ|ブートローダーのパスワード保護]]をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。

==== GRUB ====

[[GRUB]] はブートローダのパスワードもサポートしています。詳しくは [[GRUB/ヒントとテクニック#GRUB メニューのパスワード保護|GRUB メニューのパスワード保護]] を参照してください。[[GRUB/ヒントとテクニック# GRUB メニューのパスワード保護|暗号化 /boot]] もサポートしていますが、これはブートローダコードの一部だけを暗号化しないままにしています。GRUB の設定、[[カーネル]]、[[initramfs]] は暗号化されています。

==== systemd-boot ====

[[systemd-boot]] は [[#セキュアブート]] が有効な場合、カーネルパラメータの編集を無効にします。代わりの方法として、[[systemd-boot#パスワードで保護されたカーネルパラメータエディタ]] を参照して下さい、より伝統的なパスワードベースのオプションを使用できます。

=== セキュアブート ===

[[セキュアブート]] は [[UEFI]] の機能で、コンピュータが起動するファイルの認証を可能にするものです。これは、起動パーティション内のファイルを置き換えるような、いくつかの [https://ja.wikipedia.org/wiki/%E6%82%AA%E6%84%8F%E3%81%82%E3%82%8B%E3%83%A1%E3%82%A4%E3%83%89%E6%94%BB%E6%92%83 悪意あるメイド攻撃] を防止するのに役立つ。通常、コンピュータにはベンダー (OEM) によって登録されたキーが付属しています。しかし、これを取り外して、コンピュータを「セットアップモード」にし、ユーザーが自分のキーを登録・管理できるようにすることができます。

セキュアブートのページでは、[https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Implementing_Secure_Boot using your own keys] によってセキュアブートを設定する方法を案内しています。

=== トラステッドプラットフォームモジュール(TPM) ===

[[Trusted Platform Module|TPM]] は、暗号鍵が埋め込まれたハードウェア・マイクロプロセッサです。これは、最近のほとんどのコンピュータの基本的な信頼性の根源を形成し、ブートチェーンのエンドツーエンドの検証を可能にします。内部スマートカードとして使用したり、コンピュータ上で動作するファームウェアを証明したり、改ざん防止とブルートフォース耐性のあるストアにユーザーがシークレットに挿入することができます。

=== リムーバブルフラッシュドライブ上のブートパーティション ===

ブートパーティションをフラッシュドライブに置き、それがないとシステムが起動しないようにする、というのはよくあるアイデアです。このアイデアの支持者はしばしば [[セキュリティ#ディスク暗号化|ディスク暗号化]] を併用し、ブートパーティションに置かれた [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USBdetached encryption headers] を使っている人もいます。

この方法は [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USB encrypting /boot] と統合することも可能です。

=== 自動ログアウト ===
[[Bash]] または [[Zsh]] を使っている場合、{{ic|TMOUT}} によってタイムアウトによるシェルからの自動ログアウトを設定できます。

例えば、以下は仮想コンソールから自動でログアウトします (X11 のターミナルエミュレータからはログアウトしません):

{{hc|/etc/profile.d/shell-timeout.sh|<nowiki>
TMOUT="$(( 60*10 ))";
[ -z "$DISPLAY" ] && export TMOUT;
case $( /usr/bin/tty ) in
/dev/tty[0-9]*) export TMOUT;;
esac
</nowiki>}}

(X のコンソールも含めて) 全ての Bash/Zsh プロンプトでタイムアウトさせたい場合は、次を使って下さい:

$ export TMOUT="$(( 60*10 ))";

シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや {{ic|TMOUT}} をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。

=== 不正なUSBデバイスから保護する ===

[[Usbguard]] は、デバイスの属性に基づく基本的なホワイトリストおよびブラックリスト機能を実装することで、不正な USB デバイス (別名 [https://ja.wikipedia.org/wiki/BadUSB BadUSB], [https://github.com/samyk/poisontap PoisonTap] または [https://lanturtle.com/ LanTurtle]) からコンピューターを保護できるソフトウェアフレームワークです。

=== 揮発性データの収集 ===

電源が入っているコンピュータは、[https://fedvte.usalearning.gov/courses/CSI/course/videos/pdf/CSI_D01_S05_T01_STEP.pdf volatile data collection] に対して脆弱である可能性があります。コンピュータの電源を入れる必要がない時や、コンピュータの物理的な安全性が一時的に損なわれる場合(例:セキュリティチェックポイントを通過する時)には、コンピュータの電源を完全に切ることがベストプラクティスです。

== パッケージ ==

=== パッケージの認証 ===
パッケージの署名が適正に使われていないと [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview パッケージマネージャへの攻撃] が考えられ、さらに [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html 適切な署名システム] を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは [[Pacman-key]] を見て下さい。

=== アップグレード ===

定期的に [[システムメンテナンス#システムのアップグレード|システムのアップグレード]] を行うことが重要です。

=== 脆弱性アラートの確認 ===

National Vulnerability Database が提供する Common Vulnerabilities and Exposure (CVE) Security Alert の更新を購読し、[https://nvd.nist.gov/download.cfm NVD Download webpage] で見つけてください。[https://security.archlinux.org/ Arch Linux Security Tracker] は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットを表形式でまとめた、特に有用なリソースです。ツール {{Pkg|arch-audit}} は実行中のシステムに影響を与える脆弱性をチェックするために使われます。グラフィカルなシステムトレイである {{Pkg|arch-audit-gtk}} も使うことができます。[https://wiki.archlinux.org/title/Arch_Security_Team Arch Security Team]も参照してください。

特にメインレポジトリや AUR 以外の手段でソフトウェアをインストールしている場合は、あなたが使っているソフトウェアのリリース通知を購読することも検討すべきです。いくつかのソフトウェアには、セキュリティに関する通知を受け取るために購読できるメーリングリストがあります。ソースコードホスティングサイトはしばしば新しいリリースの RSS フィードを提供しています。

=== パッケージの再ビルド ===

攻撃対象領域を減らす手段として、パッケージをリビルドし、不要な関数や機能を削除することができます。例えば、{{Pkg|bzip2}} は [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189] を回避するために {{ic|bzip2recover}} を使わずにリビルドすることが可能です。カスタムハードニングフラグは、手動またはラッパーを介して適用することもできます。

{| class="wikitable"
! フラグ !! 目的
|-
| -D_FORTIFY_SOURCE=2 || ランタイムバッファオーバーフローの検出
|-
| -D_GLIBCXX_ASSERTIONS || C++ の文字列とコンテナのランタイム境界チェック
|-
| -fasynchronous-unwind-tables || バックトレースの信頼性向上
|-
| -fexceptions || テーブルベースのスレッドキャンセルを有効にする
|-
| -fpie -Wl,-pie || 実行可能ファイルに対する完全な ASLR
|-
| -fpic -shared || 共有ライブラリのテキスト再配置を行わない
|-
| -fplugin=annobin || ハードニング品質管理用データの作成
|-
| -fstack-clash-protection || スタックオーバーフロー検出の信頼性向上
|-
| -fstack-protector or -fstack-protector-all || スタックスマッシュプロテクター
|-
| -fstack-protector-strong || 同様に
|-
| -g || デバッグ情報を生成する
|-
| -grecord-gcc-switches || デバッグ情報にコンパイラのフラグを格納する
|-
| -mcet -fcf-protection || 制御フローの完全性保護
|-
| -O2 || 推奨される最適化
|-
| -pipe || 一時ファイルを回避し、ビルドを高速化します。
|-
| -Wall || 推奨されるコンパイラの警告
|-
| -Werror=format-security || 安全でない可能性のあるフォーマット文字列の引数を拒否する
|-
| -Werror=implicit-function-declaration || 関数プロトタイプの欠落を却下する
|-
| -Wl,-z,defs || アンダーリンクの検出と拒否
|-
| -Wl,-z,now || 遅延バインディングを無効にする
|-
| -Wl,-z,relro || 移設後の読み出し専用セグメント
|}

* [https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/ Flags and info ソース]

== 参照 ==

* [https://security.archlinux.org/ Arch Linux セキュリティトラッカー]
* ArchWiki のセキュリティアプリケーションのリスト: [[アプリケーション一覧/セキュリティ]]
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux ワークステーションのセキュリティチェックリスト]
* [https://www.privacytools.io/ privacytools.io Privacy Resources]
* [https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/index.html Red Hat Enterprise Linux 7 セキュリティガイド]
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Debian 安全化マニュアル (PDF)]
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]

トーク:Wayland

2025-04-06T15:34:08Z

Oech3: 4年前の適応済みの議論を削除/* 分割提案: Weston */

Arch ブートプロセス

2025-04-06T14:42:35Z

Oech3: linuxはinitramfsに依存するので不要Oech3 (トーク) による版 40136 を取り消し

[[Category:ブートプロセス]]
[[Category:Arch について]]
[[bs:Arch boot process]]
[[en:Arch boot process]]
[[es:Arch boot process]]
[[fr:Arch boot process]]
[[pt:Arch boot process]]
[[ru:Arch boot process]]
[[zh-hans:Arch boot process]]
{{Related articles start}}
{{Related|Master Boot Record}}
{{Related|GUID Partition Table}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|mkinitcpio}}
{{Related|init}}
{{Related|systemd}}
{{Related|fstab}}
{{Related|自動起動}}
{{Related articles end}}

Arch Linux を起動するためには、Linux 対応の[[#ブートローダー|ブートローダー]]をセットアップする必要があります。ブートローダは、ブートプロセスが始まる前にカーネルや[[#initramfs|初期 RAM ディスク]]をロードする仕事を行います。[[Wikipedia:ja:BIOS|BIOS]] と [[Unified Extensible Firmware Interface|UEFI]] で起動の流れはかなり異なっています。このページや関連するページに詳しい説明があります。

== ファームウェアの種類 ==

ファームウェアは、システムの電源を入れた時に一番最初に実行されるプログラムのことです。

{{Tip|BIOS や (U)EFI という語は、ファームウェアという語の代わりにしばしば用いられます。}}

=== BIOS ===

[[Wikipedia:ja:BIOS|BIOS]] (Basic Input-Outout System) は、ほとんどの場合マザーボード内のフラッシュメモリに保存され、システムストレージとは独立しています。元々は [[Wikipedia:IBM PC|IBM PC]] がハードウェアの初期化やブートプロセスを処理するために作成されました。2010 年より、BIOS にあるような技術的な制約が存在しない [[#UEFI|UEFI]] に徐々に置き換えられています。

=== UEFI ===

[[Unified Extensible Firmware Interface]] は、パーティションテーブルとファイルシステムの両方の読み取りをサポートしています。UEFI は [[パーティショニング#Master Boot Record (bootstrap code)|Master Boot Record (MBR) 内のブートコード]]を起動しません (たとえ、それが有ろうと無かろうと)。代わりに、起動は [[Wikipedia:Non-volatile random-access memory|NVRAM]] 内のブートエントリに頼っています。

UEFI 仕様では [[FAT|FAT12、FAT16、および FAT32]] ファイルシステム ([https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#file-system-format-1 UEFI 仕様バージョン2.8、セクション13.3.1.1] を参照) のサポートが義務付けられていますが、規格に準拠しているベンダーは任意でファイルシステムのサポートを追加できます。たとえば、Apple の一部のファームウェアでは [[Wikipedia:HFS+|HFS+]] か [[Wikipedia:APFS|APFS]] のサポートがあります。UEFI の実装では、光ディスク用の [[Wikipedia:ja:ISO 9660|ISO 9660]] もサポートされています。

UEFIは、[[#ブートローダー|ブートローダー]] 、ブートマネージャ、 [[Unified_Extensible_Firmware_Interface#UEFI シェル |UEFI シェル]] などの EFI アプリケーションを起動します。これらのアプリケーションは通常、 [[EFI システムパーティション]] にファイルとして保存されます。各ベンダーは、EFI システムパーティションの {{ic|/EFI/''vendor_name''}} フォルダにファイルを格納できます。アプリケーションを起動するには、NVRAM に、または UEFI シェルからブートエントリを追加します。

UEFI 仕様では、[[Wikipedia:ja:Unified_Extensible_Firmware_Interface|互換性サポートモジュール (CSM)]] によるレガシー [[#BIOS|BIOS]] ブートがサポートされています。UEFI で CSM が有効な場合、UEFI はすべてのドライブの CSM ブートエントリを生成します。CSM ブートエントリがブート元として選択された場合、UEFI の CSM はドライブの MBR ブートストラップコードからのブートを試みます。

{{Note|Intel は CSM のサポートを徐々に終了しつつあります。将来的に、この機能に頼ることは不可能になるかもしれません。[https://www.intel.com/content/dam/support/us/en/documents/intel-nuc/Legacy-BIOS-Boot-Support-Removal-for-Intel-Platforms.pdf]}}

== システムの初期化 ==

=== BIOS ===

# システムの電源が入れられ [[Wikipedia:ja:Power On Self Test|POST]] が実行される。
# BIOS が、ブートに必要なシステムハードウェア (ディスクやキーボードコントローラなど) を初期化する。
# BIOS のディスク順で最初のディスクの最初の440バイト ([[Master Boot Record|Master Boot Record]]) が BIOS によって実行される。
# MBR ブートコード内の、ブートローダの最初のステージが、2番めのステージコードを以下のどれかから実行する:
#* MBR の次のディスクセクタ。つまり、post-MBR gap と呼ばれる部分(MBR パーティションテーブルにしか存在しません)。
#* パーティション、あるいはパーティションレスディスクの [[Wikipedia:Volume boot record|ボリュームブートレコード (VBR)]]。
#* GPT でパーティショニングされたディスク上の [[GRUB]] の場合、GRUB 固有の [[BIOS ブートパーティション]] (GPT には存在しない MBR の後ろの隙間の代わりとして使用されます)。
# [[#ブートローダー|ブートローダー]]本体が起動される。
# ブートローダーがオペレーティングシステムのカーネルをチェインロード、または直接ロードして、オペレーティングシステムをロードする。

=== UEFI ===

# システムのスイッチが入り、[[Wikipedia:ja:Power On Self Test|power-on self-test (POST)]] が実行される。
# POST 後に、UEFI は起動に必要なハードウェア(ディスク、キーボード、コントローラなど)を初期化する。
# ファームウェアは NVRAM 内のブートエントリを読み込み、どの EFI アプリケーションを起動するかや、どこから(例えば、どのディスクやパーティションから)起動するかを判断する。
#* ブートエントリは単にディスクであることもあります。この場合、ファームウェアは [[EFI システムパーティション]]をそのディスク上から探し、フォールバックブートパス {{ic|\EFI\BOOT\BOOTx64.EFI}}([[Unified Extensible Firmware Interface#UEFI ファームウェアのビット数|IA32 (32-bit) UEFI のシステム]]では {{ic|BOOTIA32.EFI}})から EFI アプリケーションを見つけようとします。これは UEFI の起動可能リムーバブルメディアの動作です。
# ファームウェアが EFI アプリケーションを起動する。
#* そのアプリケーションは[[#ブートローダ|ブートローダ]]や、[[EFI ブートスタブ]]を使用する Arch [[カーネル]]自体であることもあります。
#* そのアプリケーションは他の EFI アプリケーション([[UEFI シェル]] や、[[systemd-boot]] や [[rEFInd]] などの [[#ブートローダ|ブートマネージャ]])であることもあります。

[[セキュアブート]] が有効化されている場合、ブートプロセスでは EFI バイナリの正統性を署名によって検証します。

{{Note|一部の UEFI システムはフォールバックブートパスからしか起動できません。}}

==== UEFI でのマルチブート ====

それぞれの OS やベンダーは互いに影響を与えずに [[EFI システムパーティション]] 内に固有のファイルを保持することができるので、UEFI を用いたマルチブートは単に、特定のオペレーティングシステムのブートローダに対応する異なる EFI アプリケーションを起動する問題になります。ゆえに、他の OS をロードするためにブートローダの[[Wikipedia:Chain loading|チェインロード]]メカニズムに頼る必要がありません。

[[Windows と Arch のデュアルブート]] も参照してください。

== ブートローダー ==

ブートローダーは、ファームウェア([[Wikipedia:BIOS|BIOS]] または [[UEFI]])によって起動されるソフトウェアの一部です。ブートローダーは、必要な[[カーネルパラメータ]]と任意の外部の初期 RAM ディスクイメージと共にカーネルをロードします。UEFI の場合、[[EFI ブートスタブ]]を使用して、UEFI からカーネル自体を直接起動できます。ブート前にカーネルパラメータを編集するために、別のブートローダやブートマネージャを使うこともできます。

{{Warning|Arch を正しくブートするには、ブートローダーが、たいてい {{ic|/boot}} ディレクトリ内にあるカーネル及び initramfs イメージへアクセスする必要があります。つまり、ブートローダーは、ブロックデバイスからスタックされたブロックデバイス (LVM、RAID、dm-crypt、LUKSなど) まで、カーネルや initramfs イメージが存在するファイルシステムまで、すべてをサポートしなければなりません。

しかし、そのようなスタックされたブロックデバイスをサポートするブートローダーは稀ですし、ブートローダーによってまだサポートされていない機能がファイルシステムに追加されることもある (例: [https://gitlab.archlinux.org/archlinux/packaging/packages/grub/-/issues/7 archlinux/packaging/packages/grub#7]、{{Bug|79857}}、{{Bug|59047}}、{{Bug|58137}}、{{Bug|51879}}、{{Bug|46856}}、{{Bug|38750}}、{{Bug|21733}}、[[fscrypt]] によって暗号化されたディレクトリ) ので、広くサポートされているファイルシステム ([[FAT32]] など) でフォーマットされた個別の [[パーティショニング#/boot|/boot パーティション]]を使うほうがほとんどの場合、現実的です。
}}

=== 機能比較 ===

{{Note|
* GPT は UEFI 仕様の一部であるため、すべての UEFI ブートローダーは GPT ディスクをサポートします。BIOS システム上の GPT は、[https://www.rodsbooks.com/gdisk/hybrid.html Hybrid MBR] で "hybrid booting" を使うか、新しい [https://repo.or.cz/syslinux.git/blob/HEAD:/doc/gpt.txt GPT-only] プロトコルを使うことで可能です。ただしこのプロトコルは特定の BIOS 実装で問題を引き起こす可能性があります。詳細については、[https://www.rodsbooks.com/gdisk/bios.html#bios rodsbooks] を参照してください。
* [[セキュアブート]]は UEFI 規格の一部なので、全ての UEFI ブートローダーはそれをサポートしています。ただし、いくつかの制限があります。
}}

{| class="wikitable sortable"
! rowspan="2" | 名前
! colspan="2" | ファームウェア
! colspan="2" | [[パーティショニング#パーティションテーブル|パーティションテーブル]]
! rowspan="2" | マルチブート
! rowspan="2" | [[ファイルシステム]]
! rowspan="2" | 備考
|-
! BIOS !! [[UEFI]]
! [[MBR]] !! [[GPT]]
|-
! [[EFI ブートスタブ]]
| {{-}}
| {{Yes}}1
| {{Yes}} || {{Yes}}
| {{-}}
| {{G|ファームウェアから継承2}}
| カーネルイメージは、UEFI または他の UEFI ブートローダーから直接起動することのできる有効な EFI 実行ファイルです。
|-
! [[Unified カーネルイメージ]]
| {{-}}
| {{Yes}}3
| {{Yes}} || {{Yes}}
| {{-}}
| {{G|ファームウェアから継承2}}
| {{man|7|systemd-stub}} やカーネル、initramfs、カーネルコマンドラインを EFI 実行ファイルにパックしたものです。UEFI ファームウェアや他のブートローダから直接読み込めます。
|-
! [[GRUB]]
| {{Yes}}
| {{Yes}}3
| {{Yes}} || {{Yes}}
| {{Yes}}
| {{G|[[GRUB#サポートされているファイルシステム|内蔵]]}}
| RAID、LUKS (ただし Argon2 PBKDF 以外)、LVM をサポートします (シンプロビジョニングボリュームはサポートしません)。環境固有の制限については [[GRUB]] を見てください。
|-
! [[Limine]]
| {{Yes}}
| {{Yes}}
| {{Yes}} || {{Yes}}
| {{Yes}}
| {{Y|[[Limine#サポートされているファイルシステム|制限有り]]}}
|
|-
! [[rEFInd]]
| {{No}}
| {{Yes}}
| {{Yes}} || {{Yes}}
| {{Yes}}4
| {{G|[[rEFInd#サポートされているファイルシステム|拡張可能]]2,5}}
| 明示的な構成なしでカーネルとパラメーターの自動検出をサポートします。そして、fastboot をサポートします[https://bbs.archlinux.org/viewtopic.php?id=258805]。
|-
! [[Syslinux]]
| {{Yes}}
| {{Y|[[Syslinux#UEFI Syslinux の制限|部分的]]1}}
| {{Yes}} || {{Yes}}
| {{Y|[[Syslinux#チェインロード|部分的]]}}
| {{Y|[[Syslinux#サポートされているファイルシステム|制限有り]]}}
| ファイルシステムの特定の機能はサポートされていません。 Syslinux が[[Syslinux#チェインロード|インストールされている]]ファイルシステムにしかアクセスできません。
|-
! [[systemd-boot]]
| {{No}}
| {{Yes}}3
| {{Y|[https://github.com/systemd/systemd/issues/1125 手動]}} || {{Yes}}
| {{Yes}}4
| {{G|[[systemd-boot#サポートされているファイルシステム|拡張可能]]2,5}}
| systemd-boot がインストールされている [[ESP]]、または、同じディスク上の Extended Boot Loader Partition (XBOOTLDR パーティション) 内のバイナリしか起動できません。 {{ic|''esp''/EFI/Linux/}} 内の [[unified カーネルイメージ]] を自動的に検出します。
|-
! {{Grey|[[GRUB Legacy]]}}
| {{Yes}}
| {{No}}
| {{Yes}} || {{No}}
| {{Yes}}
| {{Y|[[GRUB Legacy#サポートされているファイルシステム|制限有り]]}}
| [https://www.gnu.org/software/grub/grub-legacy.html 開発停止]。[[GRUB]] に移行。
|-
! {{Grey|[[LILO]]}}
| {{Yes}}
| {{No}}
| {{Yes}} || {{Y|[https://salsa.debian.org/joowie-guest/upstream_lilo/-/commit/29a64e6b92cac22d472f4b352de5b1535e4afc5f 部分的]}}
| {{Yes}}
| {{Y|[[LILO#サポートされているファイルシステム|制限有り]]}}
| (Btrfs、GPT、RAID、暗号化などの) 制限により[https://web.archive.org/web/20180323163248/http://lilo.alioth.debian.org/ 開発停止]。
|}

# バイナリは[[セキュアブート]]のために署名することはできますが、検証はされません。なので、信用の鎖はここで切れてしまいます。
# ファイルシステムのサポートはファームウェアから継承されます。UEFI 仕様では、FAT12、FAT16、および FAT32 ファイルシステムのサポートが義務付けられていますが [https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#file-system-format-1]、ベンダーはオプションで追加のファイルシステムのサポートを追加できます。たとえば、Apple [[Mac]] のファームウェアは HFS+ ファイルシステムをサポートしています。ファームウェアが起動時に [[Unified Extensible Firmware Interface#UEFI ドライバ|UEFIドライバー]] をロードするためのインターフェースを提供する場合、ファイルシステムドライバーを(個別に取得して)ロードすることにより、追加のファイルシステムのサポートを追加できます。
# Mixed mode ブートをサポートしています。つまり、[[Unified Extensible Firmware Interface#UEFI ファームウェアのビット数|32 ビット IA32 UEFI]] 上で 64 ビット x86_64 Linux カーネルをブートできます。
# [https://www.rodsbooks.com/efi-bootloaders/principles.html ブートマネージャー]。他の EFI アプリケーション、たとえば {{ic | 1 = CONFIG_EFI_STUB = y}} フラグありでビルドされた Linux カーネルイメージおよび [https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/boot-and-uefi#understanding-the-windows-boot-manager Windows Boot Manager] ({{ic|bootmgfw.efi}}) のみを起動できます。
# [[Unified Extensible Firmware Interface#UEFI ドライバ|UEFI ファイルシステムドライバ]]の読み込みをサポートしています。

[[Wikipedia:Comparison of boot loaders]] も参照してください。

== カーネル ==

[[#ブートローダー|ブートローダー]] は、[[カーネル]]を含んでいる [[Wikipedia:ja:vmlinux|vmlinux イメージ]]を起動します。

カーネルは、マシンのハードウェアとプログラムとの間を仲介する低いレベル(''カーネル空間'')で機能します。カーネルは、ユーザスペースに移行する前にまずハードウェアの列挙と初期化を行います。より詳細な説明は [[Wikipedia:ja:カーネル]] と [[Wikipedia:ja:Linuxカーネル]] を見てください。

== initramfs ==

{{ic|/}} のルートファイルシステムは空の [https://www.kernel.org/doc/html/latest/filesystems/ramfs-rootfs-initramfs.html rootfs] として始まります。これは ramfs や tmpfs の特殊なインスタンスです。これは一時的なルートファイルシステムで、initramfs (''init''ial ''RAM'' ''f''ile ''s''ystem) イメージがここへ解凍されます。

Initramfs の主な目的は root ファイルシステムにアクセスできる位置にシステムをブートストラップすることです (詳しくは [[FHS]] を見て下さい)。これには、[[dm-crypt]]、[[dm-verity]]、{{man|8|systemd-repart}} などを通してルートファイルシステムが存在しているであろうストレージスタックのセットアップなどが含まれます。また、[[udev]] を介して[[永続的なブロックデバイスの命名]]を実際のデバイスに解決することも行われます。これは NVMe、SATA、SAS、eMMC、USB (外部ハードウェアから起動する場合) などのデバイスのために必要なモジュールがカーネルに入っていない場合 initramfs からモジュールをロードできなくてはならないということを意味しています; (プログラムやスクリプトから明示的に指定されるか [[udev]] を通すかして) 正しいモジュールがロードされると、ブートプロセスが再開されます。従って、initramfs に含めなくてはならないのは root ファイルシステムにアクセスするために必要なモジュールだけで、使用する全てのモジュールを入れる必要はありません。ほとんどのモジュールは後の init プロセス中に、ルート ({{ic|/}}) を実際のルートファイルシステムに切り替えた後で [[udev]] によってロードされます。

まず、カーネルは組み込みの initramfs を一時的なルートファイルシステムに解凍します。Arch Linux の[[カーネル#公式サポートカーネル|公式カーネル]]では組み込みの initramfs として空のアーカイブが用いられます(Linux のビルドの際のデフォルトです)。そして、カーネルは、[[#ブートローダー|ブートローダー]]から渡されたコマンドラインにより指定された外部の initramfs ファイルを解凍します。この際、組み込みの initramfs にあったファイルは上書きされます。このような外部の initramfs イメージは [[mkinitcpio]] や [[dracut]]、[[booster]] によって生成でき、Arch の''初期ユーザ空間''のセットアップの方法として推奨されています。

Initramfs には、ルートファイルシステムをセットアップする以外の役割もあります。ルートファイルシステムがマウントされる前にしか行うことができないタスク ([[fsck]] や[[ハイバネート]]からの復帰など) が存在するのです。

また、Linux [[カーネル]]は、カーネルが開始された最初のルートファイルシステムを[https://github.com/torvalds/linux/blob/1b907d0507354b74a4f2c286380cd6059af79248/fs/namespace.c#L4222 留めておきます]。Initramfs が使用されなかった場合、シャットダウン時に実際のルートファイルシステムが正しくアンマウントされない可能性があります。

=== initramfs無しで起動 ===

6.13.8から公式にサポートされたカーネルの[[Btrfs]]と[[Ext4]]のドライバはbuilt-inです。 [https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/commit/a7e2a17f9c0e55937ea3e18c4d5b905a8e4f8047].

これは、カーネルがそれらのファイルシステムのrootパーティションを、他のモジュールなしに直接使用できる事を意味しています。
それでも、いくつか癖があります:

* [[Systemd#GPT パーティションの自動マウント]]は使えず、{{ic|root}} [[カーネルパラメータ]]が必要です。
* {{ic|root}}の続的なブロックデバイスの命名は{{ic|PARTUUID}}と{{ic|PARTLABEL}}だけ使えます [https://github.com/torvalds/linux/blob/v6.14/block/early-lookup.c#L216-L243].
* マウントオプションの{{ic|rootflags}}には制限があります,例えば{{ic|noatime}}は動きません。 [https://bugzilla.kernel.org/show_bug.cgi?id=61601]. 後で[[fstab]]等で再マントしてください。
* {{man|8|systemd-gpt-auto-generator}}はBtrfsを使っているとinitramfs無しでは使えません。 [https://github.com/systemd/systemd/issues/16953] {{ic|1=systemd.gpt_auto=no}}で無効化してください。

現時点でSCSI/SATA/AHCIドライバがbuilt-inです。他のストレージデバイス(NVMe,USB,Device mapper等)は動きません。LVMや暗号化も使えません。

[[マイクロコード#早期ロード]]もinitramfsが必要ですが、イメージ全体をビルドする必要はなく、[[マイクロコード#別個のマイクロコード initramfs ファイルを使う]]を使えます.

If no initramfs image is provided, the kernel always contains still an empty image to start from [https://docs.kernel.org/filesystems/ramfs-rootfs-initramfs.html#populating-initramfs]. So there should be no issues with root partition [https://github.com/torvalds/linux/blob/1b907d0507354b74a4f2c286380cd6059af79248/fs/namespace.c#L4222 pinning].

== 初期ユーザ空間 ==

''初期ユーザ空間''の段階は一時的なルートファイルシステムがマウントされている状態で行われ、[[#initramfs|initramfs]] により提供されたファイルで動作します。

初期ユーザ空間の機能は[[Mkinitcpio#HOOKS|設定可能]]ですが、一般的に以下のようなことを行います:

* {{man|8|systemd-modules-load}} がカーネルモジュールを読み込みます。例えば、本物のルートファイルシステムをマウントするために必要なブロックデバイスモジュールなどです。
* 必要ならば、本物のルートファイルシステムの復号処理を行います。
* DRM モジュールをロードします。[[カーネルモード設定#KMS の早期開始|KMS の早期開始]]は、ツリー内のモジュールに対してはデフォルトで有効化されています。

初期ユーザー空間の最終段階として、本物のルートファイルシステムが {{ic|/sysroot/}} ([[systemd]] ベースの initramfs の場合) または {{ic|/new_root/}} (busybox ベースの場合) にマウントされ、それに切り替わります。本物のルートファイルシステムから [[init]] プログラムを実行することにより、後期ユーザ空間が始まります。

== 後期ユーザ空間 ==

[[init]] プロセスにより後期ユーザ空間のスタートアップが実行されます。Arch では公式には、ユニットとサービスの概念の上に構築された [[systemd]] が用いられます。しかし、ここで言及している機能は他の init システムと重なります。

=== getty ===

init プロセスは [[Wikipedia:Virtual console|仮想コンソール]](典型的には6つ)ごとに [[getty]] を1回呼び出します。''getty'' はそれぞれのターミナルを初期化して、認証されていないユーザからターミナルを保護します。ユーザ名とパスワードが与えられると、''getty'' はそれらを {{ic|/etc/passwd}} と {{ic|/etc/shadow}} と照合し、{{man|1|login}} を呼び出します。

==== ログイン ====

''ログイン'' プログラムは、環境変数を設定し、{{ic|/etc/passwd}} に基づいてユーザーのシェルを起動することによって、ユーザーのセッションを開始します。''ログイン'' プログラムは、ログインに成功するとログインシェルを実行する直前に [[Wikipedia:motd (Unix) |/etc/motd]] (''m''essage ''o''f ''t''he ''d''ay) の内容を表示します。利用規約を表示してユーザーに地域のポリシーや伝えたいことを思い出させるのに適した場所です。

==== シェル ====

ユーザーの[[シェル]]が起動されると、通常はユーザーにプロンプトを表示する前に [[bashrc]] などの実行時設定ファイルが実行されます。アカウントが[[ログイン時に X を起動]]するように設定されている場合、実行時設定ファイルは [[startx]] または [[xinit]] を呼び出します。最後については [[#グラフィカルセッション (Xorg)]] を見てください。

=== ディスプレイマネージャ ===

さらに、[[init]] は、指定した仮想コンソールで ''getty'' の代わりに[[ディスプレイマネージャ]]を起動するように設定できます。そうするには、該当する [[systemd#ユニットを使う|systemd service ファイル]]を手動で[[有効化]]する必要があります。そうしたら、ディスプレイマネージャーがグラフィカルセッションを起動します。

==== グラフィカルセッション (Xorg) ====

[[xinit]] はユーザの [[xinitrc]] ランタイム設定ファイルを実行し、通常、[[ウィンドウマネージャ]]や[[デスクトップ環境]]を開始します。ユーザが終了すると、''xinit''、 ''startx''、シェル、ログインの順序で終了して [[#getty|getty]]、またはディスプレイマネージャに戻ります。

== 参照 ==

* [[Wikipedia:Booting process of Linux]]
* [https://web.archive.org/web/20230313210814/https://developer.ibm.com/articles/l-linuxboot/ Inside the Linux boot process]
* [https://www.rodsbooks.com/efi-bootloaders/ Rod Smith - Managing EFI Boot Loaders for Linux]
* [https://neosmart.net/wiki/mbr-boot-process/ NeoSmart: The BIOS/MBR Boot Process]
* [https://0pointer.net/blog/linux-boot-partitions.html Lennart Poettering - Linux Boot Partitions and How to Set Them Up]
* [[Wikipedia:initrd]]
* [https://web.archive.org/web/20150430223035/http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ Early Userspace in Arch Linux]
* [https://www.linux.com/learn/kernel-newbie-corner-initrd-and-initramfs-whats Kernel Newbie Corner: initrd and initramfs]
* {{man|7|bootup}} (Systemd initrd とユーザー空間に関する部分についてがほとんど)

{{TranslationStatus|Arch boot process|2024-12-27|824035}}

電源管理

2025-04-05T17:07:15Z

Oech3: 同期:マウスとキーボード以外のUSB デバイス/* USB の自動サスペンド */

[[Category:電源管理]]
[[en:Power management]]
[[es:Power management]]
[[pt:Power management]]
[[ru:Power management]]
[[zh-hans:Power management]]
{{Related articles start}}
{{Related|電源管理/サスペンドとハイバネート}}
{{Related|電源管理/復帰トリガー}}
{{Related|CPU 周波数スケーリング}}
{{Related|Display Power Management Signaling}}
{{Related|ハイブリッドグラフィック}}
{{Related|sysctl}}
{{Related articles end}}
[[Wikipedia:Power management|電源管理]]とは、アクティブでない時に電源を切ったりシステムのコンポーネントを低電力状態に切り替えたりする機能です。

Arch Linux では、電源管理は主に2つの部分からなります:

# Linux [[カーネル]]の設定。ハードウェアと対話します。
#* [[カーネルパラメータ]]
#* [[カーネルモジュール]]
#* [[udev]] ルール
# ユーザスペースのツールの設定。カーネルと対話し、カーネルのイベントに応答します。ユーザスペースのツールの多くは、"ユーザフレンドリー"な方法でカーネルの設定を変更することもできます。利用可能なツールは [[#ユーザースペースツール]] を参照してください。

== ユーザースペースツール ==

以下のツールを使うことで、設定ファイルを手動で編集せずに多くの設定を変更できます。どのツールも多かれ少なかれ同じような動作をするので、衝突を避けるためにツールはどれか'''一つだけ'''を実行してください。[[:Category:電源管理|電源管理カテゴリ]]を見れば、Arch Linux にどんな電源管理の選択肢が存在するかわかります。

以下は省電力設定をするために作られた人気のあるスクリプトやツールです:

=== コンソール ===

* {{App|[[acpid]]|ACPI の電源管理イベントを届けるデーモン。netlink をサポート。|https://sourceforge.net/projects/acpid2/|{{Pkg|acpid}}}}
* {{App|[[Laptop Mode Tools]]|ノートパソコンの省電力設定をするユーティリティ。多少設定が要りますが省電力設定ユーティリティのデファクトスタンダードとされています。|https://github.com/rickysarraf/laptop-mode-tools|{{AUR|laptop-mode-tools}}}}
* {{App|libsmbios|Dell SMBIOS テーブルと対話するためのライブラリおよびツール。|https://github.com/dell/libsmbios|{{Pkg|libsmbios}}}}
* {{App|[[powertop]]|消費電力や電源管理の問題を診断して省電力設定を補助するツール。|https://github.com/fenrus75/powertop|{{Pkg|powertop}}}}
* {{App|powerstat|ACPI や Intel RAPL インターフェイスを使用して電力消費量を測定するツール。|https://github.com/ColinIanKing/powerstat|{{AUR|powerstat}}}}
* {{App|[[systemd]]|システムおよびサービスマネージャ。|https://systemd.io/|{{Pkg|systemd}}}}
* {{App|[[TLP]]|Linux 向けの先進的な電源管理。|https://linrunner.de/tlp|{{Pkg|tlp}}}}
* {{App|TuneD|システム上のデバイスの監視と状況に応じた設定を行うデーモン。|https://tuned-project.org|{{Pkg|tuned}}}}
* {{App|[[Wikipedia:UPower|UPower]]|電源デバイスの列挙、デバイスイベントの監視、履歴と統計のクエリを行う抽象化レイヤー。|https://upower.freedesktop.org|{{Pkg|upower}}}}
* {{App|[[power-profiles-daemon]]|D-Bus 経由での電源プロファイルの管理を可能にします。|https://gitlab.freedesktop.org/upower/power-profiles-daemon|{{Pkg|power-profiles-daemon}}}}

=== グラフィカル ===

* {{App|batsignal|libnotify を使用してバッテリレベルの低下を警告する軽量バッテリモニタ。|https://github.com/electrickite/batsignal|{{Pkg|batsignal}}}}
* {{App|cbatticon|軽量で高速なバッテリアイコンをシステムトレイに表示。|https://github.com/valr/cbatticon|{{Pkg|cbatticon}}}}
* {{App|GNOME Power Statistics|GNOME のシステム電力情報および統計。|https://gitlab.gnome.org/GNOME/gnome-power-manager|{{Pkg|gnome-power-manager}}}}
* {{App|KDE Power Devil|Plasma 用の電源管理モジュール。|https://invent.kde.org/plasma/powerdevil|{{Pkg|powerdevil}}}}
* {{App|LXQt Power Management|LXQt 用の電源管理モジュール。|https://github.com/lxqt/lxqt-powermanagement|{{Pkg|lxqt-powermanagement}}}}
* {{App|MATE Power Management|MATE 用電源管理ツール。|https://github.com/mate-desktop/mate-power-manager|{{Pkg|mate-power-manager}}}}
* {{App|MATE Power Statistics|MATE のシステム電力情報と統計。|https://github.com/mate-desktop/mate-power-manager|{{Pkg|mate-power-manager}}}}
* {{App|poweralertd|UPower 通知を伝播するデーモン。|https://git.sr.ht/~kennylevinsen/poweralertd|{{AUR|poweralertd}}}}
* {{App|powerkit|デスクトップに依存しない電源マネージャー。|https://github.com/rodlie/powerkit|{{AUR|powerkit}}}}
* {{App|Xfce Power Manager|Xfce 用の電源マネージャ。|https://docs.xfce.org/xfce/xfce4-power-manager/start|{{Pkg|xfce4-power-manager}}}}
* {{App|vattery|システムトレイ内のラップトップバッテリのステータスを表示する、 Vala で書かれたバッテリ監視アプリケーション。|https://www.jezra.net/projects/vattery.html|{{AUR|vattery}}}}

== ACPI イベント ==

''systemd'' は一部の電源関連の [[Wikipedia:ja:Advanced Configuration and Power Interface|ACPI]] イベントを処理します。これらのイベントの動作は {{ic|/etc/systemd/logind.conf}} や {{ic|/etc/systemd/logind.conf.d/*.conf}} で設定できます ({{man|5|logind.conf}} を参照)。専用の電源マネージャを持たないシステムでは、この方法は [[acpid]] デーモンの代わりになりえます。ちなみに、[[acpid]] は通常、ACPI イベントに対応するために使われるデーモンです。

イベントの動作には、{{ic|ignore}}、{{ic|poweroff}}、{{ic|reboot}}、{{ic|halt}}、{{ic|suspend}}、{{ic|hibernate}}、{{ic|hybrid-sleep}}、{{ic|suspend-then-hibernate}}、{{ic|lock}}、{{ic|kexec}} のいずれかを指定することができます。ハイバーネートとサスペンドの場合は、適切に[[電源管理/サスペンドとハイバネート|セットアップ]]しなければなりません。イベントが設定されていない場合、''systemd'' はデフォルトの動作を使用します。

{| class="wikitable sortable"
!イベントハンドラ
!説明
!デフォルトの動作
|-
|{{ic|HandlePowerKey}}
|電源キー/ボタンが押された時にトリガされます。
|{{ic|poweroff}}
|-
|{{ic|HandleSuspendKey}}
|サスペンドキー/ボタンが押された時にトリガされます。
|{{ic|suspend}}
|-
|{{ic|HandleHibernateKey}}
|ハイバネートキー/ボタンが押された時にトリガされます。
|{{ic|hibernate}}
|-
|{{ic|HandleLidSwitch}}
|ラップトップPCなどの蓋が閉じられた時に (以下のケースを除いて) トリガされます。
|{{ic|suspend}}
|-
|{{ic|HandleLidSwitchDocked}}
|システムがドッキングステーションに繋がれている場合や、複数のディスプレイに繋がれている場合に蓋が閉じられるとトリガされます。
|{{ic|ignore}}
|-
|{{ic|HandleLidSwitchExternalPower}}
|システムが外部電源に接続されている状況で蓋が閉じられた時にトリガされます。
|{{ic|HandleLidSwitch}} に対して設定されている動作
|}

変更を適用するには、{{ic|systemd-logind.service}} を[[リロード|再読み込み]]してください。

{{Note|
* ''systemd'' は AC とバッテリの ACPI イベントを処理することができません。なので、[[Laptop Mode Tools]] や他の似たようなツールを使用している場合、[[acpid]] が依然として必要です。
* 蓋のスイッチを短い間隔で動作させると、''logind'' は、ドックが存在するかどうかを検出するために 90 秒までサスペンドアクションを遅らせます。[https://lists.freedesktop.org/archives/systemd-devel/2015-January/027131.html] この遅延は systemd v220 で設定可能になりました。[https://github.com/systemd/systemd/commit/9d10cbee89ca7f82d29b9cb27bef11e23e3803ba] {{ic|logind.conf}} か、このファイルのドロップインファイルで {{ic|1=HoldoffTimeoutSec=30s}} のように設定できます。
}}

=== 電源マネージャ ===

一部の[[デスクトップ環境]]には、''systemd'' の ACPI 設定の一部あるいは全てを [https://systemd.io/INHIBITOR_LOCKS/ inhibit] する (一時的にオフにする) 電源マネージャが含まれています。そのような電源マネージャが実行されている場合、電源マネージャだけで ACPI イベントに対する動作を設定することができます。{{ic|/etc/systemd/logind.conf}} や {{ic|/etc/systemd/logind.conf.d/*.conf}} を変更する必要があるのは、電源マネージャによって inhibit されていないイベントに対する挙動を設定したい場合のみです。

注意点として、電源マネージャが適切なイベントに対して ''systemd'' を inhibit しないと、''systemd'' がシステムをサスペンドし、その後サスペンドから復帰すると今度は電源マネージャがシステムを再びサスペンドしてしまうという状況に陥る可能性があります。[[GNOME]]、[[MATE]]、[[Plasma]]、そして [[Xfce]] の電源マネージャは、必要な ''inhibited'' コマンドを発行します。''inhibited'' コマンドが発行されない場合 ([[acpid]] などを使って ACPI イベントを処理している場合)、{{ic|Handle}} オプションを {{ic|ignore}} に設定してください。{{man|1|systemd-inhibit}} も参照してください。

=== xss-lock ===

{{pkg|xss-lock}} は systemd の {{ic|suspend}}、{{ic|hibernate}}、{{ic|lock-session}}、{{ic|unlock-session}} イベントで適切なアクションを実行します (ロッカーを実行し、ユーザがロッカーをアンロックまたは kill するまで待機する)。''xss-lock'' は [[DPMS]] イベントにも反応し、それに応じてロッカーを実行したり kill したりします。

例えば、以下のコマンドを[[自動起動]]します:

$ xss-lock -- i3lock -n -i ''background_image.png'' &

== 省電力 ==

{{Note|ノート PC 固有の電源管理 (バッテリーモニタリングなど) については [[ノートパソコン#電源管理]] を参照してください。また、使用している CPU と GPU に関するページも参照してください (例: [[Ryzen]]、[[AMDGPU]])。}}

このセクションは、カスタムスクリプトや udev ルールなどの省電力設定をの作成するためのリファレンスです。競合を避けるために、設定が[[#ユーザースペースツール|他のユーティリティ]]によって管理されていないことを確認してください。

コンピュータが AC 電源またはバッテリーで動作しているかに関わらず、ここに記載されているほとんど全ての機能には使用する価値があります。ここで挙げている機能のほとんどは、パフォーマンスへの影響は無視できるレベルであり、大抵、壊れているハードウェアやドライバのせいでデフォルトで有効化されていないだけです。電力の使用量を減らすことは発熱を減らすことでもあり、[[Wikipedia:ja:インテルターボ・ブースト・テクノロジー|動的なオーバークロック]]によって、最近の Intel や AMD の CPU ではパフォーマンスの向上につながることもあります。

=== Intel Hardware P-state をサポートする CPU ===

Intel Hardware P-state (HWP) 対応プロセッサで利用可能なエネルギー設定は、{{ic|default}}、{{ic|performance}}、{{ic|balance_performance}}、{{ic|balance_power}}、{{ic|power}} です。

以下を実行することで、利用可能な設定を確認できます:

$ cat /sys/devices/system/cpu/cpufreq/policy*/energy_performance_available_preferences

以下のファイルを作成することで、より多くのエネルギーを節約するように設定できます:

{{hc|/etc/tmpfiles.d/energy_performance_preference.conf|
w /sys/devices/system/cpu/cpufreq/policy*/energy_performance_preference - - - - balance_power
}}

Intel プロセッサの電力とパフォーマンスのポリシーに関する詳細は {{man|8|x86_energy_perf_policy}} man ページを参照してください。一時ファイル/ディレクトリに関する詳細は man ページ {{man|8|systemd-tmpfiles}} や {{man|5|tmpfiles.d}} も参照してください。

=== オーディオ ===

省電力がデフォルトでオンになっているかどうかは、ドライバによります (例えば HD Audio ではオンです)。使用しているモジュールを[[Advanced Linux Sound Architecture#ロードされているモジュールの特定|特定]]し、{{ic|modinfo ''module_name''}} を実行して、省電力機能を調整あるいは無効化する ({{ic|power_save}} のような) [[カーネルモジュールパラメータ]] を探してください。

{{Note|省電力機能はクリックノイズ (ポップ音) や他の問題を引き起こすかもしれません。それらの解決策は専用のページを参照してください:

* [[Advanced Linux Sound Architecture/トラブルシューティング#省電力]]
* [[PipeWire#再生開始時に明らかな音声の遅延やポップノイズ/音割れが発生する]]
* [[PulseAudio/トラブルシューティング#音声の再生時と停止時に破裂音]]
}}

=== バックライト ===

[[バックライト]]を見て下さい。

=== Bluetooth ===

[[Bluetooth]] を完全に無効化するには、{{ic|btusb}} と {{ic|bluetooth}} モジュールを[[ブラックリスト]]に入れてください。

あるいは、以下の udev ルールを作成してください:

{{hc|/etc/udev/rules.d/50-bluetooth.rules|2=
# disable bluetooth
SUBSYSTEM=="rfkill", ATTR{type}=="bluetooth", ATTR{state}="0"
}}

Bluetooth を一時的にオフにしたい場合は、{{man|8|rfkill}} を使ってください:

# rfkill block bluetooth

=== ウェブカメラ ===

内蔵のウェブカメラを使わない場合、{{ic|uvcvideo}} モジュールを[[ブラックリスト]]に入れてください。

=== カーネルパラメータ ===

このセクションでは {{ic|/etc/sysctl.d/}} 内の設定を使います。このディレクトリは、''"カーネルの sysctl パラメータ用のドロップインディレクトリです"''。詳細は、[http://0pointer.de/blog/projects/the-new-configuration-files The New Configuration Files] や、より詳しい {{man|5|sysctl.d}} を見てください。

==== NMI watchdog の無効化 ====

[[Wikipedia:Non-maskable interrupt|NMI]] watchdog は、カーネルパニックを引き起こすハードウェアのハングアップをキャッチするデバッグ機能です。システムによっては大量の割り込みが発生するため、消費電力の増加につながっていることがあります:

{{hc|/etc/sysctl.d/disable_watchdog.conf|2=
kernel.nmi_watchdog = 0
}}

もしくは起動の初期で完全に無効化するには[[カーネルパラメータ|カーネルライン]]に {{ic|1=nmi_watchdog=0}} を追加してください。

==== ライトバック時間 ====

仮想メモリのダーティライトバック時間を増やすことでディスク I/O がまとめられて、断続的なディスクの書き込みが減って、消費電力が抑えられます。この値を60秒に設定するには (デフォルトは5秒です):

{{hc|/etc/sysctl.d/dirty.conf|2=
vm.dirty_writeback_centisecs = 6000
}}

ジャーナルをサポートしているファイルシステム (ext4 や btrfs など) でジャーナルコミットでも同じことをするには、[[fstab]] でオプションとして {{ic|1=commit=60}} を使用します。

この値は、以下の Laptop Mode 設定の副作用として変更されてしまうことに注意してください。また、I/O パフォーマンスと省電力に影響を与える他のパラメータは [[sysctl#仮想メモリ]] を参照してください。

==== Laptop Mode ====

ラップトップモードの"ノブ"については[https://docs.kernel.org/admin-guide/laptops/laptop-mode.html カーネルドキュメント]を見て下さい。''"このノブの妥当な値は5秒です。"''

{{hc|/etc/sysctl.d/laptop.conf|2=
vm.laptop_mode = 5
}}

{{Note|この設定は主に回転ディスクドライブに関連しています。}}

=== ネットワークインターフェイス ===

[[Wake-on-LAN]] は便利な機能ですが、利用しない場合はサスペンド中にマジックパケットが来るのを待つのに無駄な電力を消耗するだけです。[[Wake-on-LAN#udev]] ルールを調整することで、全てのイーサネットインターフェイスに対してこの機能を無効化することができます。{{Pkg|iw}} を使って全てのワイヤレスインターフェイスで省電力を有効化するには:

{{hc|/etc/udev/rules.d/'''81'''-wifi-powersave.rules|2=
ACTION=="add", SUBSYSTEM=="net", KERNEL=="wl*", RUN+="/usr/bin/iw dev $name set power_save on"
}}

この設定ファイルの名前は重要です。Systemd の[[ネットワーク設定#インターフェイス名の変更|永続的なデバイス名]]を使用することで、上記のネットワークルールは、辞書順で {{ic|80-net-setup-link.rules}} の'''後'''に来るので、ネットワークデバイスの名前が永続的な名前に変更 (例: {{ic|wlan0}} から {{ic|wlp3s0}}) された後で適用されます。{{ic|RUN}} のコマンドは、全てのルールが処理された後で実行され、永続的な名前 (マッチするデバイスは {{ic|$name}} で利用できます) を使用する必要があることに注意してください。

==== Intel ワイヤレスカード (iwlwifi) ====

{{ic|iwlwifi}} ドライバによる Intel ワイヤレスカードの追加の省電力機能は、適切なパラメータをカーネルモジュールに渡すことで有効化できます。{{ic|/etc/modprobe.d/iwlwifi.conf}} ファイルに以下の記述を追加することで、パラメータを永続化させることができます:

options iwlwifi power_save=1

以下のオプションは、レイテンシの中央値を増加させる可能性があります:

options iwlwifi uapsd_disable=0

5.4 より前のカーネルでは、以下のオプションを使用できますが、スループットの最大値を減少させる可能性があります:

options iwlwifi d0i3_disable=0

ワイヤレスカードによっては、以下の2つのオプションのうちいずれかが適用されます:

options iwlmvm power_scheme=3

options iwldvm force_cam=0

以下のコマンドで、どちらのモジュールが動作しているかを確認することで、どちらが関連しているかを確認できます:

# lsmod | grep '^iwl.vm'

これらの省電力オプションは実験的であり、システムを不安定にする可能性があることに注意してください。

=== バスパワーの管理 ===

==== Active State Power Management ====

[[Wikipedia:Active State Power Management|Wikipedia]] から:

: '''Active-state power management''' ('''ASPM''') とは、PCI Express デバイスが完全にアクティブな状態にある時に電力を節約するための電源管理メカニズムです。主に、active-state link power management を介して行われます。つまり、PCI Express シリアルリンクは、トラフィックが存在しない時にパワーダウンされます。これは通常、ノート PC や他のモバイルインターネットデバイスでバッテリーの寿命を伸ばすために使用されます。

ブート時に BIOS は、ハードウェアのサポートが存在するかどうかに応じて ASPM を有効化または無効化します。サポートの有無を確認するには以下を実行してください:

# lspci -vv | grep 'ASPM.*abled;'

利用可能な ASPM ポリシーと、現在のデフォルトのポリシーを調べるには、以下を実行してください:

{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|
[default] performance powersave powersupersave
}}

ASPM は、しばしば以下の理由によって無効化されることがあります [https://wireless.wiki.kernel.org/en/users/documentation/ASPM]{{Dead link|2024|10|12|status=404}}:

# BIOS が何らかの理由で ASPM を無効化した (コンフリクトが起こるから?)。
# PCIE が ASPM を必要とするが、L0s は任意である (なので、L0s は無効化され、L1 だけが有効化されるかもしれません)。
# ASPM 用に BIOS がプログラムされていないか、BIOS にバグが存在する。

上記で ASPM がサポートされていないと報告されたが、ハードウェアが ASPM をサポートしていると思われる場合は、カーネルが ASPM を管理できるようにするために {{ic|1=pcie_aspm=force}} [[カーネルパラメータ]]で ASPM を強制的に有効化できます。

{{Warning|
* ASPM を、サポートされていないシステム上で強制的に有効化すると、電力消費量が増加する場合があります。さらに、システムのフリーズやカーネルパニックの危険性もあります。なので、そのような場合に備えてこのオプションをもとに戻す手段を確保しておくべきです。
* ASPM の強制はカーネル内で行われます。なので、ハードウェアで無効化されている場合には、有効化できません。ハードウェアで ASPM が無効化されているかどうか確認するには、root として {{ic|dmesg {{!}} grep ASPM}} と実行してください。あなたのハードウェア固有の情報については、対応する Wiki の記事を参照してください (もし存在すれば)。
}}

ASPM がサポートされており、かつ、有効化されていれば、現在のセッションに対して任意のポリシーを選択することができます。例えば、現在のセッションに対して {{ic|powersupersave}} を設定するには、以下を実行してください:

# echo powersupersave > /sys/module/pcie_aspm/parameters/policy

システムのブート時に特定の ASPM 状態 (例として {{ic|powersupersave}}) を有効化させるには、{{ic|1=pcie_aspm.policy=powersupersave}} を[[カーネルパラメータ]]に追加してください。

==== PCI Runtime Power Management ====

{{hc|/etc/udev/rules.d/pci_pm.rules|2=
SUBSYSTEM=="pci", ATTR{power/control}="auto"
SUBSYSTEM=="ata_port", KERNEL=="ata*", ATTR{device/power/control}="auto"
}}

上記のルールは未使用のデバイスを全てパワーダウンしますが、一部のデバイスが復帰しなくなってしまいます。サポートしていることが分かっているデバイスのみに対して Runtime Power Management を有効化するには、ベンダ ID とデバイス ID を使って、特定のデバイスにだけマッチするようにしてください (ID を入手するには {{ic|lspci -nn}} を使ってください):

{{hc|/etc/udev/rules.d/pci_pm.rules|2=
# whitelist for pci autosuspend
SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="auto"
}}

または、PCI Runtime Power Management が機能しないデバイスを除外して、その他の全てのデバイスに対して有効化するには:

{{hc|/etc/udev/rules.d/pci_pm.rules|2=
# blacklist for pci runtime power management
SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="on", GOTO="pci_pm_end"

SUBSYSTEM=="pci", ATTR{power/control}="auto"
LABEL="pci_pm_end"
}}

==== USB の自動サスペンド ====

Linux カーネルは USB デバイスが使用されていないときに USB デバイスを自動的にサスペンドさせることができます。これによって電力を相当カットできるときもありますが、USB の省電力機能に対応していない USB デバイスではおかしな挙動が起こる可能性もあります (特に USB マウスやキーボード)。ホワイトリストとブラックリストでフィルタリングする [[udev]] ルールを使うことで問題は軽減されます。

マウスとキーボード以外のUSB デバイスで自動サスペンドを有効にする例:

{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=
ACTION=="add", SUBSYSTEM=="usb", ATTR{product}!="*Mouse", ATTR{product}!="*Keyboard", TEST=="power/control", ATTR{power/control}="auto"
}}

自動サスペンドが動作するデバイスにだけ自動サスペンドを有効にするには、ベンダー ID とプロダクト ID でマッチングを行います (これらの ID を入手するには ''lsusb'' を使ってください):

{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=
# whitelist for usb autosuspend
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", ATTR{power/control}="auto"
}}

もしくは、USB 自動サスペンドが使えないデバイスをブラックリストに入れて、他の全てのデバイスで自動サスペンドを有効にするには:

{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=
# blacklist for usb autosuspend
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", GOTO="power_usb_rules_end"

ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"
LABEL="power_usb_rules_end"
}}

自動サスペンドに入るデフォルトのアイドル遅延時間は {{ic|usbcore}} 組み込み[[カーネルモジュール]]の {{ic|autosuspend}} パラメータによって制御されています。遅延時間をデフォルトの2秒から5秒に設定するには、以下の[[カーネルパラメータ]]を追加してください:

{{bc|1=usbcore.autosuspend=5}}

{{ic|power/control}} と同じように、{{ic|power/autosuspend}} 属性を設定することで遅延時間はデバイスごとに細かく設定することができます。また、{{ic|power/autosuspend}} を -1 (つまり、自動サスペンドしない) に設定することで、自動サスペンドを無効化することができます:

{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", ATTR{power/autosuspend}="-1"
}}

USB の電源管理に関する詳細は [https://docs.kernel.org/driver-api/usb/power-management.html Linux カーネルドキュメント]を見て下さい。

==== SATA Active Link Power Management ====

現在の設定は {{ic|/sys/class/scsi_host/host*/link_power_management_policy}} で確認したり設定したりできます:

$ grep . /sys/class/scsi_host/host*/link_power_management_policy
$ echo "med_power_with_dipm" >/sys/class/scsi_host/host''N''/link_power_management_policy

{| class="wikitable"
|+ 利用可能な ALPM 設定
! 設定
! 説明
! 省電力効果
|-
| max_performance
| 現在のデフォルト
| 無し
|-
| medium_power
| -
| 約 1.0 ワット
|-
| med_power_with_dipm
| 推奨される設定1
| 約 1.5 ワット
|-
| min_power
| '''警告: データ損失の可能性あり'''2
| 約 1.5 ワット
|}
# Linux 4.15 から、{{ic|med_power_with_dipm}} と呼ばれる[https://hansdegoede.livejournal.com/18412.html 設定]が存在しています。これは、Windows IRST ドライバ設定の動作と一致するものであり、最近の SSD や HDD ではデータの損失は発生しないはずです。[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebb82e3c79d2a956366d0848304a53648bd6350b (アイドル状態で) 1.0 から 1.5 ワット]の節約になることもあります。これは、Linux 4.16 から Intel ベースのノート PC でデフォルトの設定となっています [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebb82e3c79d2a956366d0848304a53648bd6350b]。
# {{Warning|{{ic|min_power}} SATA Active Link Power Management 設定は一部のデバイスでデータ損失が発生する可能性があります。バックアップを頻繁に取っていない限り、この設定を有効化しないでください。}}

[[udev]] ルールファイルを作成することで link_power_management_policy の設定を永続化させることができます。例えば:

{{hc|/etc/udev/rules.d/hd_power_save.rules|2=
ACTION=="add", SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="med_power_with_dipm"
}}

{{Note|
* この設定を行うとアイドル状態になっているドライブにアクセスするときに遅延が発生するようになります。AC 電源を使用するかどうかによって変えるべき設定です。
* SATA ホストコントローラとストレージデバイスの組み合わせによっては、デフォルト設定の {{ic|med_power_with_dipm}} ではうまく動作しません。例えば:
** linux-6.8.1 の時点では、Intel 7 Series Chipset コントローラから Crucial M550 SSD に (MU02 ファームウェアで) アクセスするとタイムアウトとリンク速度の低下が発生します。
** linux-6.9.6 の時点では、AMD 600 Series Chipset SATA コントローラを HL-DT-ST BDDVDRW GGC-H20L 光学ディスクドライブに使用した際に、数分おきに再初期化して ROM ドライブが音を立てる問題が発生します。
::このような場合には、{{ic|medium_power}} に設定すると解決します。
}}

=== ハードディスクドライブ ===

設定できるドライブのパラメータについては [[hdparm#電源管理の設定]] を見て下さい。

多数のプログラムがディスクに頻繁に書き込みをおこなう場合は省電力は効率的ではありません。全てのプログラムを調査して、いつどのようにプログラムがディスクに書き込むを行うのか調べるのがディスクの使用量を減らす道です。{{Pkg|iotop}} を使えばどのプログラムがディスクに頻繁に書き込みしているかわかります。他のヒントは [[パフォーマンスの向上#ストレージデバイス]] を見て下さい。

[[Fstab#atime オプション|noatime]] オプションを設定するなどの小さなことも馬鹿にできません。十分な RAM がある場合、[[スワップ#Swappiness|swappiness]] を無効化したり制限することでディスクへの書き込みが減る可能性があります。

[https://www.seagate.com/files/docs/pdf/en-GB/whitepaper/tp608-powerchoice-tech-provides-gb.pdf PowerChoice] テクノロジーを搭載した Seagate ドライブの場合、''EPC'' (Extended Power Conditions) 機能により [[hdparm]] から APM を設定するテクニックはうまく行きません。APM を設定する代わりに、{{AUR|openseachest}} パッケージを[[インストール]]し、ドライブの EPC を完全に無効化することができます (''X'' は実際のドライブレターに置き換えてください):

# openSeaChest_PowerControl --scan
# openSeaChest_PowerControl -d /dev/sd''X'' -i
# openSeaChest_PowerControl -d /dev/sd''X'' --showEPCSettings
# openSeaChest_PowerControl -d /dev/sd''X'' --EPCfeature disable
# openSeaChest_PowerControl -d /dev/sd''X'' --showEPCSettings

最後のコマンドでは、以下が出力されます:

==========================================================================================
openSeaChest_PowerControl - openSeaChest drive utilities - NVMe Enabled
Copyright (c) 2014-2023 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
openSeaChest_PowerControl Version: 3.3.1-4_1_1 X86_64
Build Date: Jul 4 2023
Today: Tue Jul 4 17:49:36 2023 User: root
==========================================================================================

/dev/sd''X'' - ST1000NM0008-2F2100 - ZFA19JG2 - SN02 - ATA

===EPC Settings===
* = timer is enabled
C column = Changeable
S column = Savable
All times are in 100 milliseconds

Name Current Timer Default Timer Saved Timer Recovery Time C S
Idle A 0 *10 *10 1 Y Y
Idle B 0 *1200 *1200 3 Y Y
Idle C 0 6000 6000 16 Y Y
Standby Z 0 9000 9000 46 Y Y

最初の列の 0 は、パーキングとスピンダウンが正常に無効化されたことを意味します。

== ツールとスクリプト ==

=== スクリプトと udev ルールを使う ===

systemd ユーザーは {{ic|systemctl suspend}} や {{ic|systemctl hibernate}} でサスペンドとハイバネートを行うことができ、{{ic|/etc/systemd/logind.conf}} で acpi イベントを処理することができるので、[[pm-utils]] と [[acpid]] を削除するということに興味を引かれるかもしれません。systemd が行えないことがたったひとつだけ存在します (systemd-204 現在): システムが AC 電源で動作しているのか、バッテリーで動作しているのかで条件分岐を行う電源管理です。このギャップをなくすには、AC アダプタが抜き差しされたときにスクリプトを実行する [[udev]] ルールを作成します:

{{hc|/etc/udev/rules.d/powersave.rules|2=
SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/path/to/your/script true"
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/path/to/your/script false"
}}

{{Note|''pm-powersave'' が使用しているのと同じスクリプトを使うことができます。[[実行可能属性]]を付与して別の所に保存する必要があります (例えば {{ic|/usr/local/bin/}})。}}

powersave スクリプトのサンプル:

* [https://github.com/supplantr/ftw ftw] (パッケージ: {{AUR|ftw-git}})
* [https://github.com/Unia/powersave powersave]
* [https://bbs.archlinux.org/viewtopic.php?id=180762 throttlectl] ({{AUR|throttlectl}})

上記の udev ルールはちゃんと動作するはずですが、電源設定がサスペンドやハイバネートをした後に更新されない場合、以下の内容で {{ic|/usr/lib/systemd/system-sleep/}} にスクリプトを追加してください:

{{hc|/usr/lib/systemd/system-sleep/00powersave|
#!/bin/sh

case $1 in
pre) /path/to/your/script false ;;
post)
if cat /sys/class/power_supply/AC0/online {{!}} grep 0 > /dev/null 2>&1
then
/path/to/your/script true
else
/path/to/your/script false
fi
;;
esac
exit 0
}}

忘れずに実行可能属性を付与してください。

{{Note|ノートパソコンによっては AC0 が異なっている可能性があります。その場合は変更してください。}}

=== 電源設定の表示 ===

以下のスクリプトは USB や PCI デバイスの電源設定などのプロパティを表示します。全ての設定を見るには root 権限が必要なので注意して下さい。

{{bc|1=
#!/bin/bash

for i in $(find /sys/devices -name "bMaxPower")
do
busdir=${i%/*}
busnum=$(<$busdir/busnum)
devnum=$(<$busdir/devnum)
title=$(lsusb -s $busnum:$devnum)

printf "\n\n+++ %s\n -%s\n" "$title" "$busdir"

for ff in $(find $busdir/power -type f ! -empty 2>/dev/null)
do
v=$(cat $ff 2>/dev/null{{!}}tr -d "\n")
[[ ${#v} -gt 0 ]] && echo -e " ${ff##*/}=$v";
v=;
done {{!}} sort -g;
done;

printf "\n\n\n+++ %s\n" "Kernel Modules"
for mod in $(lspci -k {{!}} sed -n '/in use:/s,^.*: ,,p' {{!}} sort -u)
do
echo "+ $mod";
systool -v -m $mod 2> /dev/null {{!}} sed -n "/Parameters:/,/^$/p";
done
}}

== ユーザにシャットダウンを許可する ==

=== ボタンと蓋スイッチのイベント ===

サスペンド、電源オフ、そしてハイバネートのボタンのイベントと、蓋を閉じた時のイベントは、[[#ACPI イベント]] で説明されているように ''logind'' によって処理されます。

=== systemd-logind を使う ===

{{Pkg|polkit}} を使用している場合、非リモートセッションのユーザは、[[一般的なトラブルシューティング#セッションのパーミッション|セッションが壊れていない]]限り、電源関連のコマンドを発行することができます。

セッションがアクティブであることを確認するには:
$ loginctl show-session $XDG_SESSION_ID --property=Active

アクティブであるならば、ユーザはコマンドラインで ''systemctl'' のコマンドを使用したり、メニューに追加したりできます:
$ systemctl poweroff
$ systemctl reboot

{{ic|systemctl suspend}} や {{ic|systemctl hibernate}} といった他のコマンドも使用できます。{{man|1|systemctl}} の ''System Commands'' セクションを参照してください。

=== sudo を使う ===

{{Pkg|sudo}} を[[インストール]]し、[[sudo|sudo 権限]]をユーザに与えてください。sudo 権限が与えられたユーザは、{{ic|sudo systemctl}} コマンド (例: {{ic|sudo systemctl poweroff}}、{{ic|sudo systemctl reboot}}、{{ic|sudo systemctl suspend}}、{{ic|sudo systemctl hibernate}}) を使用できるようになります。{{man|1|systemctl}} の ''System Commands'' セクションを参照してください。

==== sudo 権限の無いユーザ ====

ユーザにシャットダウンコマンドのみを使用できるようにし、sudo 権限を与えないようにする必要がある場合、{{ic|visudo}} コマンドを root として使って {{ic|/etc/sudoers}} の末尾に以下を追加してください。''user'' の部分は適切なユーザ名に、''hostname'' の部分はマシンのホスト名に置き換えてください。

''user'' ''hostname'' =NOPASSWD: /usr/bin/systemctl poweroff,/usr/bin/systemctl halt,/usr/bin/systemctl reboot

ここで設定したユーザは、{{ic|sudo systemctl poweroff}} でシャットダウンを、{{ic|sudo systemctl reboot}} で再起動を行うことができるようになります。システムをシャットダウンしたいユーザは、{{ic|sudo systemctl halt}} も使用できます。パスワードのプロンプトを表示させたくない場合は、{{ic|NOPASSWD:}} タグを使用してください。

== 参照 ==

* [https://www.thinkwiki.org/wiki/How_to_reduce_power_consumption ThinkWiki:How to reduce power consumption]
* [https://ivanvojtko.blogspot.sk/2016/04/how-to-get-longer-battery-life-on-linux.html How to get longer battery life on Linux]

{{TranslationStatus|Power management|2024-12-27|823979}}

電源管理

2025-04-05T17:01:51Z

Oech3: ataN用のルール/* PCI Runtime Power Management */

[[Category:電源管理]]
[[en:Power management]]
[[es:Power management]]
[[pt:Power management]]
[[ru:Power management]]
[[zh-hans:Power management]]
{{Related articles start}}
{{Related|電源管理/サスペンドとハイバネート}}
{{Related|電源管理/復帰トリガー}}
{{Related|CPU 周波数スケーリング}}
{{Related|Display Power Management Signaling}}
{{Related|ハイブリッドグラフィック}}
{{Related|sysctl}}
{{Related articles end}}
[[Wikipedia:Power management|電源管理]]とは、アクティブでない時に電源を切ったりシステムのコンポーネントを低電力状態に切り替えたりする機能です。

Arch Linux では、電源管理は主に2つの部分からなります:

# Linux [[カーネル]]の設定。ハードウェアと対話します。
#* [[カーネルパラメータ]]
#* [[カーネルモジュール]]
#* [[udev]] ルール
# ユーザスペースのツールの設定。カーネルと対話し、カーネルのイベントに応答します。ユーザスペースのツールの多くは、"ユーザフレンドリー"な方法でカーネルの設定を変更することもできます。利用可能なツールは [[#ユーザースペースツール]] を参照してください。

== ユーザースペースツール ==

以下のツールを使うことで、設定ファイルを手動で編集せずに多くの設定を変更できます。どのツールも多かれ少なかれ同じような動作をするので、衝突を避けるためにツールはどれか'''一つだけ'''を実行してください。[[:Category:電源管理|電源管理カテゴリ]]を見れば、Arch Linux にどんな電源管理の選択肢が存在するかわかります。

以下は省電力設定をするために作られた人気のあるスクリプトやツールです:

=== コンソール ===

* {{App|[[acpid]]|ACPI の電源管理イベントを届けるデーモン。netlink をサポート。|https://sourceforge.net/projects/acpid2/|{{Pkg|acpid}}}}
* {{App|[[Laptop Mode Tools]]|ノートパソコンの省電力設定をするユーティリティ。多少設定が要りますが省電力設定ユーティリティのデファクトスタンダードとされています。|https://github.com/rickysarraf/laptop-mode-tools|{{AUR|laptop-mode-tools}}}}
* {{App|libsmbios|Dell SMBIOS テーブルと対話するためのライブラリおよびツール。|https://github.com/dell/libsmbios|{{Pkg|libsmbios}}}}
* {{App|[[powertop]]|消費電力や電源管理の問題を診断して省電力設定を補助するツール。|https://github.com/fenrus75/powertop|{{Pkg|powertop}}}}
* {{App|powerstat|ACPI や Intel RAPL インターフェイスを使用して電力消費量を測定するツール。|https://github.com/ColinIanKing/powerstat|{{AUR|powerstat}}}}
* {{App|[[systemd]]|システムおよびサービスマネージャ。|https://systemd.io/|{{Pkg|systemd}}}}
* {{App|[[TLP]]|Linux 向けの先進的な電源管理。|https://linrunner.de/tlp|{{Pkg|tlp}}}}
* {{App|TuneD|システム上のデバイスの監視と状況に応じた設定を行うデーモン。|https://tuned-project.org|{{Pkg|tuned}}}}
* {{App|[[Wikipedia:UPower|UPower]]|電源デバイスの列挙、デバイスイベントの監視、履歴と統計のクエリを行う抽象化レイヤー。|https://upower.freedesktop.org|{{Pkg|upower}}}}
* {{App|[[power-profiles-daemon]]|D-Bus 経由での電源プロファイルの管理を可能にします。|https://gitlab.freedesktop.org/upower/power-profiles-daemon|{{Pkg|power-profiles-daemon}}}}

=== グラフィカル ===

* {{App|batsignal|libnotify を使用してバッテリレベルの低下を警告する軽量バッテリモニタ。|https://github.com/electrickite/batsignal|{{Pkg|batsignal}}}}
* {{App|cbatticon|軽量で高速なバッテリアイコンをシステムトレイに表示。|https://github.com/valr/cbatticon|{{Pkg|cbatticon}}}}
* {{App|GNOME Power Statistics|GNOME のシステム電力情報および統計。|https://gitlab.gnome.org/GNOME/gnome-power-manager|{{Pkg|gnome-power-manager}}}}
* {{App|KDE Power Devil|Plasma 用の電源管理モジュール。|https://invent.kde.org/plasma/powerdevil|{{Pkg|powerdevil}}}}
* {{App|LXQt Power Management|LXQt 用の電源管理モジュール。|https://github.com/lxqt/lxqt-powermanagement|{{Pkg|lxqt-powermanagement}}}}
* {{App|MATE Power Management|MATE 用電源管理ツール。|https://github.com/mate-desktop/mate-power-manager|{{Pkg|mate-power-manager}}}}
* {{App|MATE Power Statistics|MATE のシステム電力情報と統計。|https://github.com/mate-desktop/mate-power-manager|{{Pkg|mate-power-manager}}}}
* {{App|poweralertd|UPower 通知を伝播するデーモン。|https://git.sr.ht/~kennylevinsen/poweralertd|{{AUR|poweralertd}}}}
* {{App|powerkit|デスクトップに依存しない電源マネージャー。|https://github.com/rodlie/powerkit|{{AUR|powerkit}}}}
* {{App|Xfce Power Manager|Xfce 用の電源マネージャ。|https://docs.xfce.org/xfce/xfce4-power-manager/start|{{Pkg|xfce4-power-manager}}}}
* {{App|vattery|システムトレイ内のラップトップバッテリのステータスを表示する、 Vala で書かれたバッテリ監視アプリケーション。|https://www.jezra.net/projects/vattery.html|{{AUR|vattery}}}}

== ACPI イベント ==

''systemd'' は一部の電源関連の [[Wikipedia:ja:Advanced Configuration and Power Interface|ACPI]] イベントを処理します。これらのイベントの動作は {{ic|/etc/systemd/logind.conf}} や {{ic|/etc/systemd/logind.conf.d/*.conf}} で設定できます ({{man|5|logind.conf}} を参照)。専用の電源マネージャを持たないシステムでは、この方法は [[acpid]] デーモンの代わりになりえます。ちなみに、[[acpid]] は通常、ACPI イベントに対応するために使われるデーモンです。

イベントの動作には、{{ic|ignore}}、{{ic|poweroff}}、{{ic|reboot}}、{{ic|halt}}、{{ic|suspend}}、{{ic|hibernate}}、{{ic|hybrid-sleep}}、{{ic|suspend-then-hibernate}}、{{ic|lock}}、{{ic|kexec}} のいずれかを指定することができます。ハイバーネートとサスペンドの場合は、適切に[[電源管理/サスペンドとハイバネート|セットアップ]]しなければなりません。イベントが設定されていない場合、''systemd'' はデフォルトの動作を使用します。

{| class="wikitable sortable"
!イベントハンドラ
!説明
!デフォルトの動作
|-
|{{ic|HandlePowerKey}}
|電源キー/ボタンが押された時にトリガされます。
|{{ic|poweroff}}
|-
|{{ic|HandleSuspendKey}}
|サスペンドキー/ボタンが押された時にトリガされます。
|{{ic|suspend}}
|-
|{{ic|HandleHibernateKey}}
|ハイバネートキー/ボタンが押された時にトリガされます。
|{{ic|hibernate}}
|-
|{{ic|HandleLidSwitch}}
|ラップトップPCなどの蓋が閉じられた時に (以下のケースを除いて) トリガされます。
|{{ic|suspend}}
|-
|{{ic|HandleLidSwitchDocked}}
|システムがドッキングステーションに繋がれている場合や、複数のディスプレイに繋がれている場合に蓋が閉じられるとトリガされます。
|{{ic|ignore}}
|-
|{{ic|HandleLidSwitchExternalPower}}
|システムが外部電源に接続されている状況で蓋が閉じられた時にトリガされます。
|{{ic|HandleLidSwitch}} に対して設定されている動作
|}

変更を適用するには、{{ic|systemd-logind.service}} を[[リロード|再読み込み]]してください。

{{Note|
* ''systemd'' は AC とバッテリの ACPI イベントを処理することができません。なので、[[Laptop Mode Tools]] や他の似たようなツールを使用している場合、[[acpid]] が依然として必要です。
* 蓋のスイッチを短い間隔で動作させると、''logind'' は、ドックが存在するかどうかを検出するために 90 秒までサスペンドアクションを遅らせます。[https://lists.freedesktop.org/archives/systemd-devel/2015-January/027131.html] この遅延は systemd v220 で設定可能になりました。[https://github.com/systemd/systemd/commit/9d10cbee89ca7f82d29b9cb27bef11e23e3803ba] {{ic|logind.conf}} か、このファイルのドロップインファイルで {{ic|1=HoldoffTimeoutSec=30s}} のように設定できます。
}}

=== 電源マネージャ ===

一部の[[デスクトップ環境]]には、''systemd'' の ACPI 設定の一部あるいは全てを [https://systemd.io/INHIBITOR_LOCKS/ inhibit] する (一時的にオフにする) 電源マネージャが含まれています。そのような電源マネージャが実行されている場合、電源マネージャだけで ACPI イベントに対する動作を設定することができます。{{ic|/etc/systemd/logind.conf}} や {{ic|/etc/systemd/logind.conf.d/*.conf}} を変更する必要があるのは、電源マネージャによって inhibit されていないイベントに対する挙動を設定したい場合のみです。

注意点として、電源マネージャが適切なイベントに対して ''systemd'' を inhibit しないと、''systemd'' がシステムをサスペンドし、その後サスペンドから復帰すると今度は電源マネージャがシステムを再びサスペンドしてしまうという状況に陥る可能性があります。[[GNOME]]、[[MATE]]、[[Plasma]]、そして [[Xfce]] の電源マネージャは、必要な ''inhibited'' コマンドを発行します。''inhibited'' コマンドが発行されない場合 ([[acpid]] などを使って ACPI イベントを処理している場合)、{{ic|Handle}} オプションを {{ic|ignore}} に設定してください。{{man|1|systemd-inhibit}} も参照してください。

=== xss-lock ===

{{pkg|xss-lock}} は systemd の {{ic|suspend}}、{{ic|hibernate}}、{{ic|lock-session}}、{{ic|unlock-session}} イベントで適切なアクションを実行します (ロッカーを実行し、ユーザがロッカーをアンロックまたは kill するまで待機する)。''xss-lock'' は [[DPMS]] イベントにも反応し、それに応じてロッカーを実行したり kill したりします。

例えば、以下のコマンドを[[自動起動]]します:

$ xss-lock -- i3lock -n -i ''background_image.png'' &

== 省電力 ==

{{Note|ノート PC 固有の電源管理 (バッテリーモニタリングなど) については [[ノートパソコン#電源管理]] を参照してください。また、使用している CPU と GPU に関するページも参照してください (例: [[Ryzen]]、[[AMDGPU]])。}}

このセクションは、カスタムスクリプトや udev ルールなどの省電力設定をの作成するためのリファレンスです。競合を避けるために、設定が[[#ユーザースペースツール|他のユーティリティ]]によって管理されていないことを確認してください。

コンピュータが AC 電源またはバッテリーで動作しているかに関わらず、ここに記載されているほとんど全ての機能には使用する価値があります。ここで挙げている機能のほとんどは、パフォーマンスへの影響は無視できるレベルであり、大抵、壊れているハードウェアやドライバのせいでデフォルトで有効化されていないだけです。電力の使用量を減らすことは発熱を減らすことでもあり、[[Wikipedia:ja:インテルターボ・ブースト・テクノロジー|動的なオーバークロック]]によって、最近の Intel や AMD の CPU ではパフォーマンスの向上につながることもあります。

=== Intel Hardware P-state をサポートする CPU ===

Intel Hardware P-state (HWP) 対応プロセッサで利用可能なエネルギー設定は、{{ic|default}}、{{ic|performance}}、{{ic|balance_performance}}、{{ic|balance_power}}、{{ic|power}} です。

以下を実行することで、利用可能な設定を確認できます:

$ cat /sys/devices/system/cpu/cpufreq/policy*/energy_performance_available_preferences

以下のファイルを作成することで、より多くのエネルギーを節約するように設定できます:

{{hc|/etc/tmpfiles.d/energy_performance_preference.conf|
w /sys/devices/system/cpu/cpufreq/policy*/energy_performance_preference - - - - balance_power
}}

Intel プロセッサの電力とパフォーマンスのポリシーに関する詳細は {{man|8|x86_energy_perf_policy}} man ページを参照してください。一時ファイル/ディレクトリに関する詳細は man ページ {{man|8|systemd-tmpfiles}} や {{man|5|tmpfiles.d}} も参照してください。

=== オーディオ ===

省電力がデフォルトでオンになっているかどうかは、ドライバによります (例えば HD Audio ではオンです)。使用しているモジュールを[[Advanced Linux Sound Architecture#ロードされているモジュールの特定|特定]]し、{{ic|modinfo ''module_name''}} を実行して、省電力機能を調整あるいは無効化する ({{ic|power_save}} のような) [[カーネルモジュールパラメータ]] を探してください。

{{Note|省電力機能はクリックノイズ (ポップ音) や他の問題を引き起こすかもしれません。それらの解決策は専用のページを参照してください:

* [[Advanced Linux Sound Architecture/トラブルシューティング#省電力]]
* [[PipeWire#再生開始時に明らかな音声の遅延やポップノイズ/音割れが発生する]]
* [[PulseAudio/トラブルシューティング#音声の再生時と停止時に破裂音]]
}}

=== バックライト ===

[[バックライト]]を見て下さい。

=== Bluetooth ===

[[Bluetooth]] を完全に無効化するには、{{ic|btusb}} と {{ic|bluetooth}} モジュールを[[ブラックリスト]]に入れてください。

あるいは、以下の udev ルールを作成してください:

{{hc|/etc/udev/rules.d/50-bluetooth.rules|2=
# disable bluetooth
SUBSYSTEM=="rfkill", ATTR{type}=="bluetooth", ATTR{state}="0"
}}

Bluetooth を一時的にオフにしたい場合は、{{man|8|rfkill}} を使ってください:

# rfkill block bluetooth

=== ウェブカメラ ===

内蔵のウェブカメラを使わない場合、{{ic|uvcvideo}} モジュールを[[ブラックリスト]]に入れてください。

=== カーネルパラメータ ===

このセクションでは {{ic|/etc/sysctl.d/}} 内の設定を使います。このディレクトリは、''"カーネルの sysctl パラメータ用のドロップインディレクトリです"''。詳細は、[http://0pointer.de/blog/projects/the-new-configuration-files The New Configuration Files] や、より詳しい {{man|5|sysctl.d}} を見てください。

==== NMI watchdog の無効化 ====

[[Wikipedia:Non-maskable interrupt|NMI]] watchdog は、カーネルパニックを引き起こすハードウェアのハングアップをキャッチするデバッグ機能です。システムによっては大量の割り込みが発生するため、消費電力の増加につながっていることがあります:

{{hc|/etc/sysctl.d/disable_watchdog.conf|2=
kernel.nmi_watchdog = 0
}}

もしくは起動の初期で完全に無効化するには[[カーネルパラメータ|カーネルライン]]に {{ic|1=nmi_watchdog=0}} を追加してください。

==== ライトバック時間 ====

仮想メモリのダーティライトバック時間を増やすことでディスク I/O がまとめられて、断続的なディスクの書き込みが減って、消費電力が抑えられます。この値を60秒に設定するには (デフォルトは5秒です):

{{hc|/etc/sysctl.d/dirty.conf|2=
vm.dirty_writeback_centisecs = 6000
}}

ジャーナルをサポートしているファイルシステム (ext4 や btrfs など) でジャーナルコミットでも同じことをするには、[[fstab]] でオプションとして {{ic|1=commit=60}} を使用します。

この値は、以下の Laptop Mode 設定の副作用として変更されてしまうことに注意してください。また、I/O パフォーマンスと省電力に影響を与える他のパラメータは [[sysctl#仮想メモリ]] を参照してください。

==== Laptop Mode ====

ラップトップモードの"ノブ"については[https://docs.kernel.org/admin-guide/laptops/laptop-mode.html カーネルドキュメント]を見て下さい。''"このノブの妥当な値は5秒です。"''

{{hc|/etc/sysctl.d/laptop.conf|2=
vm.laptop_mode = 5
}}

{{Note|この設定は主に回転ディスクドライブに関連しています。}}

=== ネットワークインターフェイス ===

[[Wake-on-LAN]] は便利な機能ですが、利用しない場合はサスペンド中にマジックパケットが来るのを待つのに無駄な電力を消耗するだけです。[[Wake-on-LAN#udev]] ルールを調整することで、全てのイーサネットインターフェイスに対してこの機能を無効化することができます。{{Pkg|iw}} を使って全てのワイヤレスインターフェイスで省電力を有効化するには:

{{hc|/etc/udev/rules.d/'''81'''-wifi-powersave.rules|2=
ACTION=="add", SUBSYSTEM=="net", KERNEL=="wl*", RUN+="/usr/bin/iw dev $name set power_save on"
}}

この設定ファイルの名前は重要です。Systemd の[[ネットワーク設定#インターフェイス名の変更|永続的なデバイス名]]を使用することで、上記のネットワークルールは、辞書順で {{ic|80-net-setup-link.rules}} の'''後'''に来るので、ネットワークデバイスの名前が永続的な名前に変更 (例: {{ic|wlan0}} から {{ic|wlp3s0}}) された後で適用されます。{{ic|RUN}} のコマンドは、全てのルールが処理された後で実行され、永続的な名前 (マッチするデバイスは {{ic|$name}} で利用できます) を使用する必要があることに注意してください。

==== Intel ワイヤレスカード (iwlwifi) ====

{{ic|iwlwifi}} ドライバによる Intel ワイヤレスカードの追加の省電力機能は、適切なパラメータをカーネルモジュールに渡すことで有効化できます。{{ic|/etc/modprobe.d/iwlwifi.conf}} ファイルに以下の記述を追加することで、パラメータを永続化させることができます:

options iwlwifi power_save=1

以下のオプションは、レイテンシの中央値を増加させる可能性があります:

options iwlwifi uapsd_disable=0

5.4 より前のカーネルでは、以下のオプションを使用できますが、スループットの最大値を減少させる可能性があります:

options iwlwifi d0i3_disable=0

ワイヤレスカードによっては、以下の2つのオプションのうちいずれかが適用されます:

options iwlmvm power_scheme=3

options iwldvm force_cam=0

以下のコマンドで、どちらのモジュールが動作しているかを確認することで、どちらが関連しているかを確認できます:

# lsmod | grep '^iwl.vm'

これらの省電力オプションは実験的であり、システムを不安定にする可能性があることに注意してください。

=== バスパワーの管理 ===

==== Active State Power Management ====

[[Wikipedia:Active State Power Management|Wikipedia]] から:

: '''Active-state power management''' ('''ASPM''') とは、PCI Express デバイスが完全にアクティブな状態にある時に電力を節約するための電源管理メカニズムです。主に、active-state link power management を介して行われます。つまり、PCI Express シリアルリンクは、トラフィックが存在しない時にパワーダウンされます。これは通常、ノート PC や他のモバイルインターネットデバイスでバッテリーの寿命を伸ばすために使用されます。

ブート時に BIOS は、ハードウェアのサポートが存在するかどうかに応じて ASPM を有効化または無効化します。サポートの有無を確認するには以下を実行してください:

# lspci -vv | grep 'ASPM.*abled;'

利用可能な ASPM ポリシーと、現在のデフォルトのポリシーを調べるには、以下を実行してください:

{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|
[default] performance powersave powersupersave
}}

ASPM は、しばしば以下の理由によって無効化されることがあります [https://wireless.wiki.kernel.org/en/users/documentation/ASPM]{{Dead link|2024|10|12|status=404}}:

# BIOS が何らかの理由で ASPM を無効化した (コンフリクトが起こるから?)。
# PCIE が ASPM を必要とするが、L0s は任意である (なので、L0s は無効化され、L1 だけが有効化されるかもしれません)。
# ASPM 用に BIOS がプログラムされていないか、BIOS にバグが存在する。

上記で ASPM がサポートされていないと報告されたが、ハードウェアが ASPM をサポートしていると思われる場合は、カーネルが ASPM を管理できるようにするために {{ic|1=pcie_aspm=force}} [[カーネルパラメータ]]で ASPM を強制的に有効化できます。

{{Warning|
* ASPM を、サポートされていないシステム上で強制的に有効化すると、電力消費量が増加する場合があります。さらに、システムのフリーズやカーネルパニックの危険性もあります。なので、そのような場合に備えてこのオプションをもとに戻す手段を確保しておくべきです。
* ASPM の強制はカーネル内で行われます。なので、ハードウェアで無効化されている場合には、有効化できません。ハードウェアで ASPM が無効化されているかどうか確認するには、root として {{ic|dmesg {{!}} grep ASPM}} と実行してください。あなたのハードウェア固有の情報については、対応する Wiki の記事を参照してください (もし存在すれば)。
}}

ASPM がサポートされており、かつ、有効化されていれば、現在のセッションに対して任意のポリシーを選択することができます。例えば、現在のセッションに対して {{ic|powersupersave}} を設定するには、以下を実行してください:

# echo powersupersave > /sys/module/pcie_aspm/parameters/policy

システムのブート時に特定の ASPM 状態 (例として {{ic|powersupersave}}) を有効化させるには、{{ic|1=pcie_aspm.policy=powersupersave}} を[[カーネルパラメータ]]に追加してください。

==== PCI Runtime Power Management ====

{{hc|/etc/udev/rules.d/pci_pm.rules|2=
SUBSYSTEM=="pci", ATTR{power/control}="auto"
SUBSYSTEM=="ata_port", KERNEL=="ata*", ATTR{device/power/control}="auto"
}}

上記のルールは未使用のデバイスを全てパワーダウンしますが、一部のデバイスが復帰しなくなってしまいます。サポートしていることが分かっているデバイスのみに対して Runtime Power Management を有効化するには、ベンダ ID とデバイス ID を使って、特定のデバイスにだけマッチするようにしてください (ID を入手するには {{ic|lspci -nn}} を使ってください):

{{hc|/etc/udev/rules.d/pci_pm.rules|2=
# whitelist for pci autosuspend
SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="auto"
}}

または、PCI Runtime Power Management が機能しないデバイスを除外して、その他の全てのデバイスに対して有効化するには:

{{hc|/etc/udev/rules.d/pci_pm.rules|2=
# blacklist for pci runtime power management
SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="on", GOTO="pci_pm_end"

SUBSYSTEM=="pci", ATTR{power/control}="auto"
LABEL="pci_pm_end"
}}

==== USB の自動サスペンド ====

Linux カーネルは USB デバイスが使用されていないときに USB デバイスを自動的にサスペンドさせることができます。これによって電力を相当カットできるときもありますが、USB の省電力機能に対応していない USB デバイスではおかしな挙動が起こる可能性もあります (特に USB マウスやキーボード)。ホワイトリストとブラックリストでフィルタリングする [[udev]] ルールを使うことで問題は軽減されます。

マウスとキーボード以外の、全ての USB デバイスで自動サスペンドを有効にする例:

{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"
ACTION=="add",SUBSYSTEM=="usb",ATTR{product}=="*Mouse",ATTR{power/control}="on"
ACTION=="add",SUBSYSTEM=="usb",ATTR{product}=="*Keyboard",ATTR{power/control}="on"
}}

自動サスペンドが動作するデバイスにだけ自動サスペンドを有効にするには、ベンダー ID とプロダクト ID でマッチングを行います (これらの ID を入手するには ''lsusb'' を使ってください):

{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=
# whitelist for usb autosuspend
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", ATTR{power/control}="auto"
}}

もしくは、USB 自動サスペンドが使えないデバイスをブラックリストに入れて、他の全てのデバイスで自動サスペンドを有効にするには:

{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=
# blacklist for usb autosuspend
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", GOTO="power_usb_rules_end"

ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"
LABEL="power_usb_rules_end"
}}

自動サスペンドに入るデフォルトのアイドル遅延時間は {{ic|usbcore}} 組み込み[[カーネルモジュール]]の {{ic|autosuspend}} パラメータによって制御されています。遅延時間をデフォルトの2秒から5秒に設定するには、以下の[[カーネルパラメータ]]を追加してください:

{{bc|1=usbcore.autosuspend=5}}

{{ic|power/control}} と同じように、{{ic|power/autosuspend}} 属性を設定することで遅延時間はデバイスごとに細かく設定することができます。また、{{ic|power/autosuspend}} を -1 (つまり、自動サスペンドしない) に設定することで、自動サスペンドを無効化することができます:

{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", ATTR{power/autosuspend}="-1"
}}

USB の電源管理に関する詳細は [https://docs.kernel.org/driver-api/usb/power-management.html Linux カーネルドキュメント]を見て下さい。

==== SATA Active Link Power Management ====

現在の設定は {{ic|/sys/class/scsi_host/host*/link_power_management_policy}} で確認したり設定したりできます:

$ grep . /sys/class/scsi_host/host*/link_power_management_policy
$ echo "med_power_with_dipm" >/sys/class/scsi_host/host''N''/link_power_management_policy

{| class="wikitable"
|+ 利用可能な ALPM 設定
! 設定
! 説明
! 省電力効果
|-
| max_performance
| 現在のデフォルト
| 無し
|-
| medium_power
| -
| 約 1.0 ワット
|-
| med_power_with_dipm
| 推奨される設定1
| 約 1.5 ワット
|-
| min_power
| '''警告: データ損失の可能性あり'''2
| 約 1.5 ワット
|}
# Linux 4.15 から、{{ic|med_power_with_dipm}} と呼ばれる[https://hansdegoede.livejournal.com/18412.html 設定]が存在しています。これは、Windows IRST ドライバ設定の動作と一致するものであり、最近の SSD や HDD ではデータの損失は発生しないはずです。[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebb82e3c79d2a956366d0848304a53648bd6350b (アイドル状態で) 1.0 から 1.5 ワット]の節約になることもあります。これは、Linux 4.16 から Intel ベースのノート PC でデフォルトの設定となっています [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebb82e3c79d2a956366d0848304a53648bd6350b]。
# {{Warning|{{ic|min_power}} SATA Active Link Power Management 設定は一部のデバイスでデータ損失が発生する可能性があります。バックアップを頻繁に取っていない限り、この設定を有効化しないでください。}}

[[udev]] ルールファイルを作成することで link_power_management_policy の設定を永続化させることができます。例えば:

{{hc|/etc/udev/rules.d/hd_power_save.rules|2=
ACTION=="add", SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="med_power_with_dipm"
}}

{{Note|
* この設定を行うとアイドル状態になっているドライブにアクセスするときに遅延が発生するようになります。AC 電源を使用するかどうかによって変えるべき設定です。
* SATA ホストコントローラとストレージデバイスの組み合わせによっては、デフォルト設定の {{ic|med_power_with_dipm}} ではうまく動作しません。例えば:
** linux-6.8.1 の時点では、Intel 7 Series Chipset コントローラから Crucial M550 SSD に (MU02 ファームウェアで) アクセスするとタイムアウトとリンク速度の低下が発生します。
** linux-6.9.6 の時点では、AMD 600 Series Chipset SATA コントローラを HL-DT-ST BDDVDRW GGC-H20L 光学ディスクドライブに使用した際に、数分おきに再初期化して ROM ドライブが音を立てる問題が発生します。
::このような場合には、{{ic|medium_power}} に設定すると解決します。
}}

=== ハードディスクドライブ ===

設定できるドライブのパラメータについては [[hdparm#電源管理の設定]] を見て下さい。

多数のプログラムがディスクに頻繁に書き込みをおこなう場合は省電力は効率的ではありません。全てのプログラムを調査して、いつどのようにプログラムがディスクに書き込むを行うのか調べるのがディスクの使用量を減らす道です。{{Pkg|iotop}} を使えばどのプログラムがディスクに頻繁に書き込みしているかわかります。他のヒントは [[パフォーマンスの向上#ストレージデバイス]] を見て下さい。

[[Fstab#atime オプション|noatime]] オプションを設定するなどの小さなことも馬鹿にできません。十分な RAM がある場合、[[スワップ#Swappiness|swappiness]] を無効化したり制限することでディスクへの書き込みが減る可能性があります。

[https://www.seagate.com/files/docs/pdf/en-GB/whitepaper/tp608-powerchoice-tech-provides-gb.pdf PowerChoice] テクノロジーを搭載した Seagate ドライブの場合、''EPC'' (Extended Power Conditions) 機能により [[hdparm]] から APM を設定するテクニックはうまく行きません。APM を設定する代わりに、{{AUR|openseachest}} パッケージを[[インストール]]し、ドライブの EPC を完全に無効化することができます (''X'' は実際のドライブレターに置き換えてください):

# openSeaChest_PowerControl --scan
# openSeaChest_PowerControl -d /dev/sd''X'' -i
# openSeaChest_PowerControl -d /dev/sd''X'' --showEPCSettings
# openSeaChest_PowerControl -d /dev/sd''X'' --EPCfeature disable
# openSeaChest_PowerControl -d /dev/sd''X'' --showEPCSettings

最後のコマンドでは、以下が出力されます:

==========================================================================================
openSeaChest_PowerControl - openSeaChest drive utilities - NVMe Enabled
Copyright (c) 2014-2023 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
openSeaChest_PowerControl Version: 3.3.1-4_1_1 X86_64
Build Date: Jul 4 2023
Today: Tue Jul 4 17:49:36 2023 User: root
==========================================================================================

/dev/sd''X'' - ST1000NM0008-2F2100 - ZFA19JG2 - SN02 - ATA

===EPC Settings===
* = timer is enabled
C column = Changeable
S column = Savable
All times are in 100 milliseconds

Name Current Timer Default Timer Saved Timer Recovery Time C S
Idle A 0 *10 *10 1 Y Y
Idle B 0 *1200 *1200 3 Y Y
Idle C 0 6000 6000 16 Y Y
Standby Z 0 9000 9000 46 Y Y

最初の列の 0 は、パーキングとスピンダウンが正常に無効化されたことを意味します。

== ツールとスクリプト ==

=== スクリプトと udev ルールを使う ===

systemd ユーザーは {{ic|systemctl suspend}} や {{ic|systemctl hibernate}} でサスペンドとハイバネートを行うことができ、{{ic|/etc/systemd/logind.conf}} で acpi イベントを処理することができるので、[[pm-utils]] と [[acpid]] を削除するということに興味を引かれるかもしれません。systemd が行えないことがたったひとつだけ存在します (systemd-204 現在): システムが AC 電源で動作しているのか、バッテリーで動作しているのかで条件分岐を行う電源管理です。このギャップをなくすには、AC アダプタが抜き差しされたときにスクリプトを実行する [[udev]] ルールを作成します:

{{hc|/etc/udev/rules.d/powersave.rules|2=
SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/path/to/your/script true"
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/path/to/your/script false"
}}

{{Note|''pm-powersave'' が使用しているのと同じスクリプトを使うことができます。[[実行可能属性]]を付与して別の所に保存する必要があります (例えば {{ic|/usr/local/bin/}})。}}

powersave スクリプトのサンプル:

* [https://github.com/supplantr/ftw ftw] (パッケージ: {{AUR|ftw-git}})
* [https://github.com/Unia/powersave powersave]
* [https://bbs.archlinux.org/viewtopic.php?id=180762 throttlectl] ({{AUR|throttlectl}})

上記の udev ルールはちゃんと動作するはずですが、電源設定がサスペンドやハイバネートをした後に更新されない場合、以下の内容で {{ic|/usr/lib/systemd/system-sleep/}} にスクリプトを追加してください:

{{hc|/usr/lib/systemd/system-sleep/00powersave|
#!/bin/sh

case $1 in
pre) /path/to/your/script false ;;
post)
if cat /sys/class/power_supply/AC0/online {{!}} grep 0 > /dev/null 2>&1
then
/path/to/your/script true
else
/path/to/your/script false
fi
;;
esac
exit 0
}}

忘れずに実行可能属性を付与してください。

{{Note|ノートパソコンによっては AC0 が異なっている可能性があります。その場合は変更してください。}}

=== 電源設定の表示 ===

以下のスクリプトは USB や PCI デバイスの電源設定などのプロパティを表示します。全ての設定を見るには root 権限が必要なので注意して下さい。

{{bc|1=
#!/bin/bash

for i in $(find /sys/devices -name "bMaxPower")
do
busdir=${i%/*}
busnum=$(<$busdir/busnum)
devnum=$(<$busdir/devnum)
title=$(lsusb -s $busnum:$devnum)

printf "\n\n+++ %s\n -%s\n" "$title" "$busdir"

for ff in $(find $busdir/power -type f ! -empty 2>/dev/null)
do
v=$(cat $ff 2>/dev/null{{!}}tr -d "\n")
[[ ${#v} -gt 0 ]] && echo -e " ${ff##*/}=$v";
v=;
done {{!}} sort -g;
done;

printf "\n\n\n+++ %s\n" "Kernel Modules"
for mod in $(lspci -k {{!}} sed -n '/in use:/s,^.*: ,,p' {{!}} sort -u)
do
echo "+ $mod";
systool -v -m $mod 2> /dev/null {{!}} sed -n "/Parameters:/,/^$/p";
done
}}

== ユーザにシャットダウンを許可する ==

=== ボタンと蓋スイッチのイベント ===

サスペンド、電源オフ、そしてハイバネートのボタンのイベントと、蓋を閉じた時のイベントは、[[#ACPI イベント]] で説明されているように ''logind'' によって処理されます。

=== systemd-logind を使う ===

{{Pkg|polkit}} を使用している場合、非リモートセッションのユーザは、[[一般的なトラブルシューティング#セッションのパーミッション|セッションが壊れていない]]限り、電源関連のコマンドを発行することができます。

セッションがアクティブであることを確認するには:
$ loginctl show-session $XDG_SESSION_ID --property=Active

アクティブであるならば、ユーザはコマンドラインで ''systemctl'' のコマンドを使用したり、メニューに追加したりできます:
$ systemctl poweroff
$ systemctl reboot

{{ic|systemctl suspend}} や {{ic|systemctl hibernate}} といった他のコマンドも使用できます。{{man|1|systemctl}} の ''System Commands'' セクションを参照してください。

=== sudo を使う ===

{{Pkg|sudo}} を[[インストール]]し、[[sudo|sudo 権限]]をユーザに与えてください。sudo 権限が与えられたユーザは、{{ic|sudo systemctl}} コマンド (例: {{ic|sudo systemctl poweroff}}、{{ic|sudo systemctl reboot}}、{{ic|sudo systemctl suspend}}、{{ic|sudo systemctl hibernate}}) を使用できるようになります。{{man|1|systemctl}} の ''System Commands'' セクションを参照してください。

==== sudo 権限の無いユーザ ====

ユーザにシャットダウンコマンドのみを使用できるようにし、sudo 権限を与えないようにする必要がある場合、{{ic|visudo}} コマンドを root として使って {{ic|/etc/sudoers}} の末尾に以下を追加してください。''user'' の部分は適切なユーザ名に、''hostname'' の部分はマシンのホスト名に置き換えてください。

''user'' ''hostname'' =NOPASSWD: /usr/bin/systemctl poweroff,/usr/bin/systemctl halt,/usr/bin/systemctl reboot

ここで設定したユーザは、{{ic|sudo systemctl poweroff}} でシャットダウンを、{{ic|sudo systemctl reboot}} で再起動を行うことができるようになります。システムをシャットダウンしたいユーザは、{{ic|sudo systemctl halt}} も使用できます。パスワードのプロンプトを表示させたくない場合は、{{ic|NOPASSWD:}} タグを使用してください。

== 参照 ==

* [https://www.thinkwiki.org/wiki/How_to_reduce_power_consumption ThinkWiki:How to reduce power consumption]
* [https://ivanvojtko.blogspot.sk/2016/04/how-to-get-longer-battery-life-on-linux.html How to get longer battery life on Linux]

{{TranslationStatus|Power management|2024-12-27|823979}}

Wayland

2025-04-05T16:39:33Z

Oech3: 何で動作するか?/* ディスプレイマネージャ */

[[Category:グラフィカルユーザーインターフェイス]]
[[en:Wayland]]
[[es:Wayland]]
[[pt:Wayland]]
[[ru:Wayland]]
[[zh-hans:Wayland]]
{{Related articles start}}
{{Related|カーネルモード設定}}
{{Related|Xorg}}
{{Related|スクリーンショットの取得#Wayland}}
{{Related articles end}}

[https://wayland.freedesktop.org/ Wayland] はディスプレイサーバープロトコルです。[[Xorg|X Window System]] の後継となることを目指しています。[[Wikipedia:Wayland_(display_server_protocol)#Differences_between_Wayland_and_X|Wikipedia に Wayland と Xorg の比較]] が掲載されています。

Wayland プロトコルを使用するディスプレイサーバは、[[Wikipedia:ja:コンポジット型ウィンドウマネージャ|コンポジット型ウィンドウマネージャ]] としても機能するため、'''コンポジタ''' と呼ばれます。以下に[[#コンポジタ|Wayland コンポジタのリスト]]を示します。

ネイティブな X11 アプリケーションをシームレスに動かすための後方互換性として、[[#Xwayland|Xwayland]] を使うことができます。これは Wayland に X サーバを提供します。

== 要件 ==

ほとんどの Wayland コンポジタは、[[カーネルモード設定]]を利用しているシステムでのみ動作します。Wayland それ自体はグラフィカルな環境を提供しません。ゆえに、Wayland に加えてコンポジタ (以下のセクションを参照)、あるいは、コンポジタを含むデスクトップ環境 (例: [[GNOME]]、[[Plasma]]) が必要となります。

GPU ドライバと Wayland コンポジタは、同一のバッファ API に対応している場合に互換性があります。主要な API は2つ存在します: [[Wikipedia:Generic Buffer Management|GBM]] と [https://www.phoronix.com/scan.php?page=news_item&px=XDC2016-Device-Memory-API EGLStreams] です。

{| class="wikitable"
! バッファ API !! GPU ドライバーのサポート !! Wayland コンポジタのサポート
|-
| GBM || [[NVIDIA]] < 495* 以外の全てのドライバー || 全て
|-
| EGLStreams || [[NVIDIA]] || [[GNOME]]
|}

: * Nvidia ≥ 495 は EGLStreams と GBM の両方をサポートします。[https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-495.44-Linux-Driver]

NVIDIA が GBM のサポートを導入して以来、NVIDIA ≥ 495 で多くのコンポジタ (Mutter と KWin を含む) がデフォルトで GBM を使用し始めました。GBM は一般的にベターでより幅広いサポートがあると考えられています。EGLStreams がサポートされていた理由は、NVIDIA GPU をプロプライエタリドライバで Wayland 下で使用する代替の方法を NVIDIA が提供しなかったからだけです。さらに、GBM が NVIDIA に導入された後、KWin は [https://invent.kde.org/plasma/kwin/-/merge_requests/1638 EGLStreams のサポートを打ち切りました]。

人気なデスクトップ環境/コンポジタと、NVIDIA によってまだサポートされている GPU を使用している場合、おそらくすでに GBM バックエンドを使用しています。確認するには、次を実行してください: {{ic|journalctl -b 0 --grep "renderer for"}}。GBM をバックエンドとして強制的に使用させるには、次の[[環境変数]]を設定してください:

GBM_BACKEND=nvidia-drm
__GLX_VENDOR_LIBRARY_NAME=nvidia

== コンポジタ ==

'''タイル型''', '''スタック型''', '''ダイナミック型''' の違いについては、[[ウィンドウマネージャ#種類]] を参照してください。

=== スタック型 ===

* {{App|[[Enlightenment]]|[[Enlightenment]]|[[Enlightenment#手動]] を参照してください。詳細: [https://git.enlightenment.org/enlightenment/enlightenment/src/branch/master/README.md] [https://www.enlightenment.org/about-wayland]|https://www.enlightenment.org/|{{Pkg|enlightenment}}}}
* {{App|hikari|FreeBSD で活発に開発されている [[cwm]] にインスパイアされた wlroots ベースのコンポジタ。Linux もサポートしています。|https://hikari.acmelabs.space/|{{AUR|hikari}}}}
* {{App|KDE [[w:KWin|KWin]]|[[KDE#Plasma の起動]] を参照。|https://userbase.kde.org/KWin|{{Pkg|kwin}}}}
* {{App|Liri Shell|[[Liri]] の一部、しかし、QtQuick と QtCompositor を使って Wayland 用のコンポジタとして作られています。|https://github.com/lirios/shell|{{AUR|liri-shell-git}}}}
* {{App|labwc|Openbox にインスパイアされた wlroots ベースのコンポジタ。|https://github.com/labwc/labwc|{{Pkg|labwc}}}}
* {{App|[[w:Mutter (software)|Mutter]]|[[GNOME#GNOME の起動]] を参照。|https://gitlab.gnome.org/GNOME/mutter|{{Pkg|mutter}}}}
* {{App|wayfire|[[Compiz]] にインスパイアされ、wlroots に基づく 3D コンポジタ。|https://wayfire.org/|{{AUR|wayfire}}}}
* {{App|[[Weston]]|正しさ、信頼性、予測可能性、性能のために設計された Wayland コンポジタ。|https://gitlab.freedesktop.org/wayland/weston|{{Pkg|weston}}}}
* {{App|wio|Plan 9 のリオデスクトップのルックアンドフィールを複製することを目的とする wlroots ベースのコンポジタ。|https://gitlab.com/Rubo/wio|{{AUR|wio-wl}}}}

=== タイル型 ===

* {{App|[[Cagebreak]]|cage をベースに、[[ratpoison]] にインスパイアされています。|https://github.com/project-repo/cagebreak|{{AUR|cagebreak}}}}
* {{App|niri|スクロール可能なタイル型 Wayland コンポジタ。|https://github.com/YaLTeR/niri/|{{Pkg|niri}}}}
* {{App|Polonium|[[KDE]] 6 上でタイル型ウィンドウを使用できる、Bismuth の後継。|https://github.com/zeroxoneafour/polonium|{{AUR|kwin-polonium}}}}
* {{App|[[Qtile]]|Python で記述および設定されたフル機能のハッキング可能なタイリングウィンドウマネージャーと Wayland コンポジタ。|https://github.com/qtile/qtile|{{Pkg|qtile}}}}
* {{App|[[Sway]]|wlroots ベースの [[i3]] 互換 Wayland コンポジタ。|https://github.com/swaywm/sway|{{Pkg|sway}}}}
* {{App|SwayFx|魅力的な視覚効果機能を追加した [[Sway]]。|https://github.com/WillPower3309/swayfx|{{AUR|swayfx}}}}
* {{App|Velox|swc ベースのシンプルなウィンドウマネージャです。[[dwm]] と [[xmonad]] の影響を受けています。|https://github.com/michaelforney/velox|{{AUR|velox-git}}}}

=== ダイナミック型 ===

* {{App|[[dwl]]|wlroots ベースの [[dwm]] ライクな Wayland コンポジタ。|https://codeberg.org/dwl/dwl|{{AUR|dwl}}}}
* {{App|[[Hyprland]]|見た目を犠牲にしないダイナミックなタイリング Wayland コンポジタ。|https://hyprland.org|{{Pkg|hyprland}}}}
* {{App|japokwm|wlroots ベースの、レイアウト作成を中心とした動的な Wayland タイリングコンポジタ。|https://github.com/werererer/japokwm|{{AUR|japokwm-git}}}}
* {{App|[[river]]|dwm と [[bspwm]] にインスパイアされた動的なタイル型 Wayland コンポジタ。|https://codeberg.org/river/river|{{Pkg|river}}}}
* {{App|Vivarium|wlroots を使用するダイナミックタイル型 Wayland コンポジタ。[[xmonad]] にインスパイアされたデスクトップセマンティクスを持ちます。|https://github.com/inclement/vivarium|{{AUR|vivarium-git}}}}

=== その他 ===

* {{App|Cage|キオスクのような単一のフルスクリーンアプリケーションを表示します。|https://www.hjdskes.nl/projects/cage/|{{Pkg|cage}}}}
* {{App|nwg-shell|Sway と Hyprland Wayland コンポジタのための GTK ベースシェル。|https://github.com/nwg-piotr/nwg-shell|{{Pkg|nwg-shell}}}}
* {{App|kiwmi|完全にプログラミング可能な Wayland コンポジタ。|https://github.com/buffet/kiwmi|{{AUR|kiwmi-git}}}}
* {{App|phoc|モバイル端末のための wlroots ベースの小さなコンポジタ。|https://gitlab.gnome.org/World/Phosh/phoc|{{Pkg|phoc}}}}

上記のいくつかは [[ディスプレイマネージャ]] をサポートする場合があります。
それらがどのように開始されるかを {{ic|/usr/share/wayland-sessions/''compositor''.desktop}} を見て確認してください。

== ディスプレイマネージャ ==

Wayland コンポジタの実行をサポートしている[[ディスプレイマネージャ]]は以下の表の通りです。

{| class="wikitable sortable"
! 名前
! 何で動作するか
! 説明
|-
| {{Pkg|emptty}}
| TTY
| TTY で動作するシンプルな CLI ディスプレイマネージャ。
|-
| [[GDM]]
| Wayland/Xorg
| [[GNOME]] ディスプレイマネージャ。
|-
| [[greetd]]
| Wayland/Xorg/TTY
| 最小でありながら柔軟なログインデーモン。
|-
| {{Pkg|lemurs}}
| TTY
| Rust で書かれた TUI ディスプレイマネージャ。
|-
| [[LightDM]]
| Xorg[https://github.com/canonical/lightdm/issues/267]
| 様々なデスクトップに対応したディスプレイマネージャ。
|-
| [[Ly]]
| TTY
| C で書かれた TUI ディスプレイマネージャ。
|-
| [[SDDM]]
| Wayland/Xorg
| QML ベースのディスプレイマネージャ。
|-
| [[tbsm]]
| TTY
| bash のみに依存するシンプルな CLI セッションランチャー。
|-
| [[Universal_Wayland_Session_Manager|UWSM]]
| TTY
| Systemd のメカニズムを使用するスタンドアローンなコンポジタのための、セッションと XDG autostart のマネージャ。
|}

== Xwayland ==

[https://wayland.freedesktop.org/xserver.html Xwayland] は、Wayland の下で実行される X サーバーで、Wayland サポートをまだ提供していないネイティブな [[X11]] アプリケーションに互換性を提供します。これを使用するには、{{Pkg|xorg-xwayland}} パッケージを[[インストール]]します。

Xwayland はコンポジタを介して開始されるため、あなたの使用しているコンポジタのドキュメントを読み、Xwayland との互換性についてや、Xwayland の起動方法に関する指示を確認しておく必要があります。

{{Note|
* セキュリティ: Xwayland は X サーバーであるため、 Wayland のセキュリティ機能はありません。
* パフォーマンス: Xwayland は X11 と[https://openbenchmarking.org/result/2202053-NE-NVIDIARTX35 ほぼ同等のパフォーマンス]を発揮します。しかし、一部のケースで (特に NVIDIA カード上で) パフォーマンスの低下を感じるかもしれません。
* 互換性: Xwayland は X11 と完全な後方互換性があるわけではありません。一部のアプリケーションは Xwayland 下では正しく動作しない場合があります。}}

=== NVIDIA ドライバ ===

{{Note|バージョン 470 より前の Nvidia ドライバ(例: {{aur|nvidia-390xx-dkms}}) はハードウェア支援のある Xwayland をサポートしておらず、非 Wayland ネイティブなアプリケーションは Wayland セッションでのパフォーマンスが低下します。}}

なお、[[NVIDIA#DRM カーネルモード設定|DRM KMS]] を有効にする必要があります。また、お使いのディスプレイマネージャ(例: [[GDM#Wayland と独自の NVIDIA ドライバ|GDM]])の[https://download.nvidia.com/XFree86/Linux-x86_64/515.48.07/README/xwayland.html 公式ドキュメント]に記載されている情報も見てください。

=== Kwin Wayland デバッグコンソール ===

{{pkg|kwin}} を使用している場合、以下を実行すると、どのウィンドウが Xwayland とネイティブ Wayland を使用しているか、表面、入力イベント、クリップボードの内容などを確認することができます。

$ qdbus6 org.kde.KWin /KWin org.kde.KWin.showDebugConsole

=== Xwayland アプリケーションであることを視認する ===

アプリケーションが Xwayland 経由で実行されているかどうかを判断するには、{{AUR|extramaus}} を使用します。
アプリケーションのウィンドウ上にマウスポインタを移動して、マウスポインタが赤くなる場合は、アプリケーションが Xwayland 経由で実行されています。

または、{{pkg|xorg-xeyes}} を使用して、アプリケーションウィンドウ上でマウスポインタを移動するときに、目が動いているかどうかで確認することもできます。

他の方法として、({{Pkg|xorg-xwininfo}} の) ''xwininfo'' をターミナルウィンドウで実行するというものがあります。Xwayland ウィンドウ上にマウスポインタをホバーすると、マウスポインタが + マークに変わります。ウィンドウをクリックすると、xwininfo は情報を表示して終了しますが、ネイティブな Wayland ウィンドウでは何も起こりません。{{ic|Ctrl+C}} を押すことで xwininfo を終了できます。

あるいは、''xlsclients'' ({{Pkg|xorg-xlsclients}} パッケージ) を使用することもできます。Xwayland で動作中のアプリケーションを全てリストアップするには、{{ic|xlsclients -l}} を実行してください。

== GUI ライブラリ ==

[https://wayland.freedesktop.org/toolkits.html 公式ウェブサイト] で詳細を確認してください。

=== GTK ===

{{Pkg|gtk3}} と {{Pkg|gtk4}} パッケージは Wayland バックエンドが有効になっています。GTK ではデフォルトで Wayland バックエンドを使いますが、[[環境変数]]を設定することで Xwayland を使うように上書きできます: {{ic|1=GDK_BACKEND=x11}}。

テーマの問題は [[GTK#Wayland バックエンド]] を見てください。

=== Qt ===

[[Qt]] 5 または 6 で Wayland のサポートを有効化するには、Qt 5 と 6 に対してそれぞれ {{Pkg|qt5-wayland}} または {{Pkg|qt6-wayland}} パッケージをインストールしてください。これで、Qt アプリケーションは Wayland セッション上では Wayland で動作するようになります。

必須ではないはずですが、明示的に Wayland プラグインを使って Qt 5 アプリケーションを動作させるには、[https://wiki.qt.io/QtWayland#How_do_I_use_QtWayland.3F] にあるように、{{ic|1=-platform wayland}} を使用するか、[[環境変数]] {{ic|1=QT_QPA_PLATFORM=wayland}} をセットして下さい。

一方、Wayland セッション上で [[X11]] を使用させるには、{{ic|1=QT_QPA_PLATFORM=xcb}} と設定してください。これは、システムの Qt の実装を使用しない一部のプロプライエタリアプリケーションで必要になる場合があります。
また、{{ic|1=QT_QPA_PLATFORM="wayland;xcb"}} を使用すると、Qt が Wayland を利用できない場合に、代わりに xcb (X11)プラグインを使用させることができます。[https://www.qt.io/blog/2018/05/29/whats-new-in-qt-5-11-for-the-wayland-platform-plugin]

[[sway]] などの一部のコンポジターでは、ネイティブに実行されている Qt アプリケーションの機能が不足している場合があります。たとえば、[https://keepassxc.org KeepassXC] はトレイに最小化できません。これは、アプリケーションを実行する前に {{Pkg|qt5ct}} をインストールし、{{ic|1=QT_QPA_PLATFORMTHEME=qt5ct}} を設定することで解決できます。

=== Clutter ===

Clutter ツールキットには Wayland バックエンドがあり、Clutter を Wayland のクライアントとして動作させることが可能です。このバックエンドは {{Pkg|clutter}} パッケージで有効になっています。

Clutter アプリを Wayland 上で動作させるには、環境変数 {{ic|1=CLUTTER_BACKEND=wayland}} を設定する必要があります。

=== SDL2 ===

SDL2 アプリケーションを Wayland 上で動作させるには、{{ic|1=SDL_VIDEODRIVER=wayland}} を設定してください。

{{ic|1=SDL_VIDEODRIVER="wayland,x11"}} とすることにより、Wayland が利用できない場合に代わりに X11 ビデオドライバを使用するように SDL2 を設定できます [https://wiki.libsdl.org/SDL2/FAQUsingSDL]。ウィンドウ装飾を有効化するために {{Pkg|libdecor}} をインストールすると良いかもしれません (例えば、GNOME で)。

=== GLFW ===

{{Pkg|glfw}} パッケージには Wayland に対するサポートがあります。{{ic|1=XDG_SESSION_TYPE}} が {{ic|1=wayland}} に設定されていて、かつアプリケーションの開発者が特定のバックエンドを使用するようにしていなければ、Wayland バックエンドが使用されます。

詳細は GLFW の[https://github.com/glfw/glfw/blob/3.4/src/platform.c#L87-L99 ソースコード]を参照してください。

=== GLEW ===

{{AUR|glew-wayland}} パッケージは現在のところ、多くの GLEW ベースのアプリケーションでまだ動作しませんので、唯一の選択肢は Xwayland で {{Pkg|glew}} を使うことです。{{Bug|62713}} を参照してください。

=== EFL ===

EFL は Wayland を完全にサポートしています。Wayland で EFL アプリケーションを動かすには、Wayland の [https://wayland.freedesktop.org/efl.html プロジェクトページ] を見て下さい。

=== winit ===

Winit は [[Rust]] で書かれたウィンドウ管理ライブラリです。デフォルトでは Wayland が X11 より優先される仕様ですが、環境変数を設定することで Xwayland を使うように上書きすることができます:

* バージョン 0.29.2 より前の場合、{{ic|1=WINIT_UNIX_BACKEND=x11}} を設定してください。
* バージョン 0.29.2 以降の場合、{{ic|1=WAYLAND_DISPLAY}} を unset してください。そうすることで、強制的に {{ic|1=DISPLAY}} 変数を使用して X にフォールバックされます。[https://github.com/rust-windowing/winit/blob/baf10de95843f156b0fbad6b10c3137f1ebd4f1e/src/changelog/v0.29.md?plain=1#L134]

=== Electron ===

Wayland サポートを有効化する方法は次の2つです: アプリケーションごとのコマンドラインフラグを使って有効化するか、設定ファイルを使ってグローバルに有効化するかです。

アプリケーションがどの electron バージョンを使用しているか確認する方法については [https://stackoverflow.com/q/50345957] を見てください。

{{Note|Plasma では、一部の Electron アプリケーションで間違ったアイコン (デフォルトの Wayland アイコン) がウィンドウに表示され、一方タスクバーには正しいアイコンが表示されることがあります。この問題は、デスクトップファイルの名前を強制する特殊なアプリケーション/ウィンドウルールを作成することで解決できます。}}

==== 環境変数 ====

Electron 28 及びそれ以降を使用するアプリケーションは、[[環境変数]] [https://www.electronjs.org/docs/latest/api/environment-variables#electron_ozone_platform_hint-linux ELECTRON_OZONE_PLATFORM_HINT] を {{ic|auto}} または {{ic|wayland}} に設定することで、Wayland モードを使用することができます。

コマンドラインフラグは、この環境変数より優先されます。

==== コマンドラインフラグ ====

Electron がベースとしている Chromium とは異なり、Electron アプリケーションはデフォルトで PipeWire による WebRTC 画面共有を有効化しません。なので、Wayland 上で画面共有の問題を防ぐために {{ic|1=--enable-features=WebRTCPipeWireCapturer}} を使用することが推奨されます。画面共有は {{Pkg|xdg-desktop-portal}} をベースとしています。

環境変数を使うことが望ましくない、または不可能である場合に、{{Pkg|electron}} ベースのアプリケーションを Wayland でネイティブに使用するには、Electron 20 以降では {{ic|1=--ozone-platform-hint=auto}} フラグを使用することで可能です。

トップバーが消失してしまう場合、{{ic|1=--enable-features=WaylandWindowDecorations}} フラグを使用することで解決します。これは、典型的には [[GNOME]] で必須です ([https://github.com/electron/electron/pull/29618 electron17] からsパオートされています)。

これらのフラグを永続的に設定する方法は2つあります。1つ目は、アプリケーションの [[デスクトップエントリ#desktop ファイルの変更|.desktop ファイルを変更]]して {{ic|1=Exec=}} 行の末尾にフラグを追加する方法。もう一つは、以下で説明している設定ファイルを使用する方法で、こちらはよりきれいに設定できます。

{{Note|一部のアプリケーションは、Electron に対してフラグを渡さないため、そのアプリケーションの開発者が解決策を実装する必要があります。}}

==== 設定ファイル ====

Electron 系のパッケージは {{ic|1=~/.config/electron''XX''-flags.conf}} を読み込みます。ここで、''XX'' は Electron のバージョンです。該当するバージョンのファイルが存在しない場合、{{ic|1=~/.config/electron-flags.conf}} を代わりに読み込みます。

前述のフラグを一行ずつ書き込んでください:

{{hc|~/.config/electron-flags.conf|2=
--enable-features=WaylandWindowDecorations
--ozone-platform-hint=auto
}}

{{Note|このような設定ファイルは、公式リポジトリ内の Electron のパッケージと、それらの設定ファイルを使用するパッケージでのみ機能します。{{AUR|slack-desktop}} などのような Electron の独自のビルドをバンドルしているパッケージでは機能しません。{{AUR|slack-electron}} のように代替のパッケージが存在する場合があります。}}

==== 古い Electron バージョン ====

{{ic|electron25-flags.conf}} は Electron バージョン 25 に対してだけ適用されます。それより古い Electron のバージョンは {{ic|electron<バージョン>-flags.conf}} ファイルで設定できます。

古いバージョンでは、対応する Chromium バージョンによって異なるフラグが必要になる場合があります。例えば、以下のフラグは Electron 13 で機能します:

{{hc|~/.config/electron13-flags.conf|2=
--enable-features=UseOzonePlatform
--ozone-platform=wayland
}}

=== Java ===

[[Java]] プラットフォームのオープンソース実装である OpenJDK は、まだ Wayland のネイティブサポートを備えていません。
OpenJDK に Wayland を実装することを目的としたプロジェクトである [https://openjdk.java.net/projects/wakefield/ Wakefield] が実用できるようになるまでは、Xwayland を代わりに使用できます。

[[Debian:Wayland#Java Programs (supported since OpenJDK 16?)]] を参照してください:

:OpenJDK 16から、JRE は (Wayland をサポートしている) GTK3 を動的にロードできるようになりました。この[https://stackoverflow.com/questions/39197208/java-gui-support-on-wayland 議論]によると、これがサポートされているかもしれません。
:{{ic|_JAVA_AWT_WM_NONREPARENTING}} [[環境変数]]を "1" に設定することで、アプリケーションが空白の画面で起動する不具合を修正することができます。

== ヒントとテクニック ==

=== 自動化 ===

* [https://github.com/ReimuNotMoe/ydotool ydotool] ({{Pkg|ydotool}}) - 汎用のコマンドラインツール (wayland 以外でも利用可能)。{{ic|ydotool.service}} [[ユーザーユニット]]を[[起動/有効化]]してください。{{man|8|ydotoold}}、{{man|1|ydotool|url=https://github.com/ReimuNotMoe/ydotool/blob/master/manpage/ydotool.1.scd}} を参照。
* [https://github.com/atx/wtype wtype] ({{Pkg|wtype}}) - Wayland 用 xdotool type。{{man|1|wtype}} を参照。
* [https://github.com/boppreh/keyboard keyboard] - Windows と Linux で動作する Python ライブラリ。実験的な OS X サポートあり。[https://github.com/boppreh/mouse mouse] ライブラリも参照。
* [https://git.sr.ht/~brocellous/wlrctl wlrctl] ({{AUR|wlrctl}}) - 雑多な wlroots 拡張のためのコマンドラインユーティリティ (foreign-toplevel-management、virtual-keyboard、virtual-pointer をサポート)。

=== キーボードやマウスキーのリマップ ===

[[入力リマップユーティリティ]] を見てください。

=== X11 アプリケーションで Wayland ウィンドウをスクリーンキャストする ===

[[スクリーンキャプチャ#X11 アプリケーションで Wayland ウィンドウをスクリーンキャストする]] を見てください。

=== Chromium で完全に最大化出来ない ===

chrome://settings/appearance ''メニューから'' Use system title bar and borders'' を有効にする必要があります。

=== Waylandコンポジタをsystemdサービスとして自動的に起動する ===
{{Note|この設定はdbusセッションを破壊し,[[PipeWire#WebRTC 画面共有]]を破壊するかも知れません.}}
ディスプレイマネージャーやシェルを使いたくなければ、Waylandコンポジタを[[systemd]]サービスを使って自動的に起動できます。{{ic|ExecStart}}行を使いたいコンポジタに変えて下さい:

{{hc|/etc/systemd/system/wayland-compositor.service|2=
[Unit]
After=graphical.target systemd-user-sessions.service modprobe@drm.service
Conflicts=getty@tty1.service

[Service]
User=''username''
WorkingDirectory=~

PAMName=login
TTYPath=/dev/tty1
UnsetEnvironment=TERM

StandardOutput=journal
ExecStart=/bin/labwc -s gtklock

[Install]
WantedBy=graphical.target
}}

{{Note|[[セキュリティ#物理セキュリティ]]の為に、{{Pkg|swaylock}}や{{Pkg|gtklock}}等のスクリーンロッカーを、コンポジタの設定を通して自動的に起動する必要があるかも知れません。}}

==トラブルシューティング==

=== 色補正 ===

[[バックライト#色補正]]を参照。

=== 動作が遅い、表示がおかしい、クラッシュする ===

Gnome-shell で X から Wayland に切り替えるとグラフィック表示に問題が発生することがあります。原因として Xorg ベースの gnome-shell 用に {{ic|1=CLUTTER_PAINT=disable-clipped-redraws:disable-culling}} が設定されている可能性があります。{{ic|/etc/environment}} や rc ファイルから該当箇所を削除してみてください。

=== リモートディスプレイ ===

* ([[sway]] で使用されている) {{pkg|wlroots}} は、バージョン 0.10 より、{{Pkg|wayvnc}} を使って VNC バックエンドを提供しています。RDP バックエンドは削除されました [https://github.com/swaywm/wlroots/releases/tag/0.10.0]。
* {{pkg|mutter}} はコンパイル時にリモートデスクトップが有効化されています。詳細は [https://wiki.gnome.org/Projects/Mutter/RemoteDesktop] と {{Pkg|gnome-remote-desktop}} を見てください。
* {{pkg|krfb}} は {{pkg|kwin}} に VNC サーバを提供します。{{ic|krfb-virtualmonitor}} を使えば、他のデバイスを外部モニタとしてセットアップすることが可能です。
* 2013年に FreeRDP が Weston にマージされました。コンパイルフラグで有効化されています。{{Pkg|weston}} パッケージは、バージョン 6.0.0 より、FreeRDP が有効化されています。
* {{Pkg|waypipe}} は Wayland アプリケーションの透過プロキシです。[[SSH]] 上で動作するラッパーコマンドあり。
** 以下は、Plasma デスクトップでリモートの KDE kcalc を起動する例です:
$ waypipe ssh example.local env QT_QPA_PLATFORM=wayland-egl QT_QPA_PLATFORMTHEME=KDE dbus-launch kcalc

=== ゲームやリモートデスクトップ、仮想マシンウィンドウでの入力捕捉 ===

Xorg と異なり、Wayland では入力デバイスを独占 (グラブ) することができません (例: [https://tronche.com/gui/x/xlib/input/XGrabKeyboard.html キーボード]、[https://tronche.com/gui/x/xlib/input/XGrabPointer.html マウス])。キーボードショートカットやポインタデバイスをアプリケーションウィンドウに渡すのは Wayland コンポジタの役目となっています。

入力グラブが変わったことで以下のように既存のアプリケーションで問題が発生します:

* ホットキーや修飾キーがコンポジタによって認識されてしまい、リモートデスクトップや仮想マシンのウィンドウに送信されなくなります。
* マウスポインタがアプリケーションウィンドウに制限されなくなるため、仮想マシンやリモートデスクトップのウィンドウ内のマウスポインタの位置がホスト環境のマウスポインタとずれるようになります。

Wayland と Xwayland にプロトコル拡張を追加することで解決を図っていますが、Wayland コンポジタが拡張をサポートしている必要があり、ネイティブの Wayland クライアントの場合、ウィジェットツールキット (例: GTK, Qt) やアプリケーション自身が拡張に対応していなければなりません。Xorg アプリケーションの場合、Xwayland のサポートで十分であるため、アプリケーションやウィジェット・ツールキットに変更を加える必要はありません。

これらの拡張はすでに {{pkg|wayland-protocols}} に含まれており、{{pkg|xorg-xwayland}} によってサポートされています。

関連する拡張:

* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml Xwayland keyboard grabbing protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml Compositor shortcuts inhibit protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/relative-pointer/relative-pointer-unstable-v1.xml Relative pointer protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml Pointer constraints protocol]

サポートしている Wayland コンポジタ:

* Mutter, [[GNOME]] のコンポジタ ([https://bugzilla.gnome.org/show_bug.cgi?id=783342 リリース 3.28] 以降)。
* wlroots (Relative pointer protocols と Pointer constraints protocol に対応)
* Kwin
** [[KDE#Wayland で X11 のショートカットが衝突する]]
** [https://invent.kde.org/plasma/kwin/-/blob/master/src/wayland/keyboard_shortcuts_inhibit_v1_interface.cpp Keyboard shortcuts inhibit]

サポートしているウィジェットツールキット:

* GTK (リリース 3.22.18 以降)

=== GTK テーマが動かない ===

https://github.com/swaywm/sway/wiki/GTK-3-settings-on-Wayland を参照してください。

=== NVIDIA モジュールを読み込まないようにする ===

[[sway]] などの Wayland コンポジターを起動する前に {{ic|1=__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json}} を [[環境変数]] として追加します。

=== 拡大/サーフェススケーリング ===

スクリーンの拡大は、まだ解決していません。[https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/145 wp-surface-scale プロトコルを提供する]プルリクエストが2022年半ばにマージされました。

=== カーネル 6.11.2 (AMD) 以降、Wayland にラグ/スタッタリングが発生する ===

将来のカーネルリリースでこの問題が修正されるまで、回避策は、コマンドラインに {{ic|1=amdgpu.dcdebugmask=0x400}} を追加することです。

こちらを参照: https://community.frame.work/t/wayland-lag-stuttering-since-kernel-6-11-2/59422

== 参照 ==

* [https://wayland.freedesktop.org/docs/html/ Wayland オンラインドキュメント]
* [https://gitlab.freedesktop.org/wayland 公式リポジトリ]
* [[Fedora:How to debug Wayland problems]]
* [https://arewewaylandyet.com/ Are we Wayland yet?]
* [https://awesomeopensource.com/projects/wayland Awesome Wayland projects]
* [[カーソルテーマ]]
* [https://bbs.archlinux.org/viewtopic.php?id=107499 Arch Linux forum discussion]
* [https://github.com/swaywm/sway/wiki/i3-Migration-Guide#common-x11-apps-used-on-i3-with-wayland-alternatives i3 Migration Guide - Common X11 apps used on i3 with Wayland alternatives]
* [https://wayland.app/protocols/ Wayland Explorer - A better way to read Wayland documentation]
* [https://askubuntu.com/questions/1393618/how-can-i-tell-if-an-application-is-using-xwayland How can I tell if an application is using XWayland]

{{TranslationStatus|Wayland|2024-08-24|814878}}

Wayland

2025-04-05T16:05:30Z

Oech3: zoomを削除/* Qt */

[[Category:グラフィカルユーザーインターフェイス]]
[[en:Wayland]]
[[es:Wayland]]
[[pt:Wayland]]
[[ru:Wayland]]
[[zh-hans:Wayland]]
{{Related articles start}}
{{Related|カーネルモード設定}}
{{Related|Xorg}}
{{Related|スクリーンショットの取得#Wayland}}
{{Related articles end}}

[https://wayland.freedesktop.org/ Wayland] はディスプレイサーバープロトコルです。[[Xorg|X Window System]] の後継となることを目指しています。[[Wikipedia:Wayland_(display_server_protocol)#Differences_between_Wayland_and_X|Wikipedia に Wayland と Xorg の比較]] が掲載されています。

Wayland プロトコルを使用するディスプレイサーバは、[[Wikipedia:ja:コンポジット型ウィンドウマネージャ|コンポジット型ウィンドウマネージャ]] としても機能するため、'''コンポジタ''' と呼ばれます。以下に[[#コンポジタ|Wayland コンポジタのリスト]]を示します。

ネイティブな X11 アプリケーションをシームレスに動かすための後方互換性として、[[#Xwayland|Xwayland]] を使うことができます。これは Wayland に X サーバを提供します。

== 要件 ==

ほとんどの Wayland コンポジタは、[[カーネルモード設定]]を利用しているシステムでのみ動作します。Wayland それ自体はグラフィカルな環境を提供しません。ゆえに、Wayland に加えてコンポジタ (以下のセクションを参照)、あるいは、コンポジタを含むデスクトップ環境 (例: [[GNOME]]、[[Plasma]]) が必要となります。

GPU ドライバと Wayland コンポジタは、同一のバッファ API に対応している場合に互換性があります。主要な API は2つ存在します: [[Wikipedia:Generic Buffer Management|GBM]] と [https://www.phoronix.com/scan.php?page=news_item&px=XDC2016-Device-Memory-API EGLStreams] です。

{| class="wikitable"
! バッファ API !! GPU ドライバーのサポート !! Wayland コンポジタのサポート
|-
| GBM || [[NVIDIA]] < 495* 以外の全てのドライバー || 全て
|-
| EGLStreams || [[NVIDIA]] || [[GNOME]]
|}

: * Nvidia ≥ 495 は EGLStreams と GBM の両方をサポートします。[https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-495.44-Linux-Driver]

NVIDIA が GBM のサポートを導入して以来、NVIDIA ≥ 495 で多くのコンポジタ (Mutter と KWin を含む) がデフォルトで GBM を使用し始めました。GBM は一般的にベターでより幅広いサポートがあると考えられています。EGLStreams がサポートされていた理由は、NVIDIA GPU をプロプライエタリドライバで Wayland 下で使用する代替の方法を NVIDIA が提供しなかったからだけです。さらに、GBM が NVIDIA に導入された後、KWin は [https://invent.kde.org/plasma/kwin/-/merge_requests/1638 EGLStreams のサポートを打ち切りました]。

人気なデスクトップ環境/コンポジタと、NVIDIA によってまだサポートされている GPU を使用している場合、おそらくすでに GBM バックエンドを使用しています。確認するには、次を実行してください: {{ic|journalctl -b 0 --grep "renderer for"}}。GBM をバックエンドとして強制的に使用させるには、次の[[環境変数]]を設定してください:

GBM_BACKEND=nvidia-drm
__GLX_VENDOR_LIBRARY_NAME=nvidia

== コンポジタ ==

'''タイル型''', '''スタック型''', '''ダイナミック型''' の違いについては、[[ウィンドウマネージャ#種類]] を参照してください。

=== スタック型 ===

* {{App|[[Enlightenment]]|[[Enlightenment]]|[[Enlightenment#手動]] を参照してください。詳細: [https://git.enlightenment.org/enlightenment/enlightenment/src/branch/master/README.md] [https://www.enlightenment.org/about-wayland]|https://www.enlightenment.org/|{{Pkg|enlightenment}}}}
* {{App|hikari|FreeBSD で活発に開発されている [[cwm]] にインスパイアされた wlroots ベースのコンポジタ。Linux もサポートしています。|https://hikari.acmelabs.space/|{{AUR|hikari}}}}
* {{App|KDE [[w:KWin|KWin]]|[[KDE#Plasma の起動]] を参照。|https://userbase.kde.org/KWin|{{Pkg|kwin}}}}
* {{App|Liri Shell|[[Liri]] の一部、しかし、QtQuick と QtCompositor を使って Wayland 用のコンポジタとして作られています。|https://github.com/lirios/shell|{{AUR|liri-shell-git}}}}
* {{App|labwc|Openbox にインスパイアされた wlroots ベースのコンポジタ。|https://github.com/labwc/labwc|{{Pkg|labwc}}}}
* {{App|[[w:Mutter (software)|Mutter]]|[[GNOME#GNOME の起動]] を参照。|https://gitlab.gnome.org/GNOME/mutter|{{Pkg|mutter}}}}
* {{App|wayfire|[[Compiz]] にインスパイアされ、wlroots に基づく 3D コンポジタ。|https://wayfire.org/|{{AUR|wayfire}}}}
* {{App|[[Weston]]|正しさ、信頼性、予測可能性、性能のために設計された Wayland コンポジタ。|https://gitlab.freedesktop.org/wayland/weston|{{Pkg|weston}}}}
* {{App|wio|Plan 9 のリオデスクトップのルックアンドフィールを複製することを目的とする wlroots ベースのコンポジタ。|https://gitlab.com/Rubo/wio|{{AUR|wio-wl}}}}

=== タイル型 ===

* {{App|[[Cagebreak]]|cage をベースに、[[ratpoison]] にインスパイアされています。|https://github.com/project-repo/cagebreak|{{AUR|cagebreak}}}}
* {{App|niri|スクロール可能なタイル型 Wayland コンポジタ。|https://github.com/YaLTeR/niri/|{{Pkg|niri}}}}
* {{App|Polonium|[[KDE]] 6 上でタイル型ウィンドウを使用できる、Bismuth の後継。|https://github.com/zeroxoneafour/polonium|{{AUR|kwin-polonium}}}}
* {{App|[[Qtile]]|Python で記述および設定されたフル機能のハッキング可能なタイリングウィンドウマネージャーと Wayland コンポジタ。|https://github.com/qtile/qtile|{{Pkg|qtile}}}}
* {{App|[[Sway]]|wlroots ベースの [[i3]] 互換 Wayland コンポジタ。|https://github.com/swaywm/sway|{{Pkg|sway}}}}
* {{App|SwayFx|魅力的な視覚効果機能を追加した [[Sway]]。|https://github.com/WillPower3309/swayfx|{{AUR|swayfx}}}}
* {{App|Velox|swc ベースのシンプルなウィンドウマネージャです。[[dwm]] と [[xmonad]] の影響を受けています。|https://github.com/michaelforney/velox|{{AUR|velox-git}}}}

=== ダイナミック型 ===

* {{App|[[dwl]]|wlroots ベースの [[dwm]] ライクな Wayland コンポジタ。|https://codeberg.org/dwl/dwl|{{AUR|dwl}}}}
* {{App|[[Hyprland]]|見た目を犠牲にしないダイナミックなタイリング Wayland コンポジタ。|https://hyprland.org|{{Pkg|hyprland}}}}
* {{App|japokwm|wlroots ベースの、レイアウト作成を中心とした動的な Wayland タイリングコンポジタ。|https://github.com/werererer/japokwm|{{AUR|japokwm-git}}}}
* {{App|[[river]]|dwm と [[bspwm]] にインスパイアされた動的なタイル型 Wayland コンポジタ。|https://codeberg.org/river/river|{{Pkg|river}}}}
* {{App|Vivarium|wlroots を使用するダイナミックタイル型 Wayland コンポジタ。[[xmonad]] にインスパイアされたデスクトップセマンティクスを持ちます。|https://github.com/inclement/vivarium|{{AUR|vivarium-git}}}}

=== その他 ===

* {{App|Cage|キオスクのような単一のフルスクリーンアプリケーションを表示します。|https://www.hjdskes.nl/projects/cage/|{{Pkg|cage}}}}
* {{App|nwg-shell|Sway と Hyprland Wayland コンポジタのための GTK ベースシェル。|https://github.com/nwg-piotr/nwg-shell|{{Pkg|nwg-shell}}}}
* {{App|kiwmi|完全にプログラミング可能な Wayland コンポジタ。|https://github.com/buffet/kiwmi|{{AUR|kiwmi-git}}}}
* {{App|phoc|モバイル端末のための wlroots ベースの小さなコンポジタ。|https://gitlab.gnome.org/World/Phosh/phoc|{{Pkg|phoc}}}}

上記のいくつかは [[ディスプレイマネージャ]] をサポートする場合があります。
それらがどのように開始されるかを {{ic|/usr/share/wayland-sessions/''compositor''.desktop}} を見て確認してください。

== ディスプレイマネージャ ==

Wayland コンポジタの実行をサポートしている[[ディスプレイマネージャ]]は以下の表の通りです。

{| class="wikitable sortable"
! 名前
! それ自体は Wayland で動作するか?
! 説明
|-
| {{Pkg|emptty}}
| {{No}}
| TTY で動作するシンプルな CLI ディスプレイマネージャ。
|-
| [[GDM]]
| {{Yes}}
| [[GNOME]] ディスプレイマネージャ。
|-
| [[greetd]]
| {{G|Wayland の greeter を使用した場合}}
| 最小でありながら柔軟なログインデーモン。
|-
| {{Pkg|lemurs}}
| {{No}}
| Rust で書かれた TUI ディスプレイマネージャ。
|-
| [[LightDM]]
| {{No|https://github.com/canonical/lightdm/issues/267}}
| 様々なデスクトップに対応したディスプレイマネージャ。
|-
| [[Ly]]
| {{No}}
| C で書かれた TUI ディスプレイマネージャ。
|-
| [[SDDM]]
| {{Yes}}
| QML ベースのディスプレイマネージャ。
|-
| [[tbsm]]
| {{No}}
| bash のみに依存するシンプルな CLI セッションランチャー。
|-
| [[Universal_Wayland_Session_Manager|UWSM]]
| {{No}}
| Systemd のメカニズムを使用するスタンドアローンなコンポジタのための、セッションと XDG autostart のマネージャ。
|}

== Xwayland ==

[https://wayland.freedesktop.org/xserver.html Xwayland] は、Wayland の下で実行される X サーバーで、Wayland サポートをまだ提供していないネイティブな [[X11]] アプリケーションに互換性を提供します。これを使用するには、{{Pkg|xorg-xwayland}} パッケージを[[インストール]]します。

Xwayland はコンポジタを介して開始されるため、あなたの使用しているコンポジタのドキュメントを読み、Xwayland との互換性についてや、Xwayland の起動方法に関する指示を確認しておく必要があります。

{{Note|
* セキュリティ: Xwayland は X サーバーであるため、 Wayland のセキュリティ機能はありません。
* パフォーマンス: Xwayland は X11 と[https://openbenchmarking.org/result/2202053-NE-NVIDIARTX35 ほぼ同等のパフォーマンス]を発揮します。しかし、一部のケースで (特に NVIDIA カード上で) パフォーマンスの低下を感じるかもしれません。
* 互換性: Xwayland は X11 と完全な後方互換性があるわけではありません。一部のアプリケーションは Xwayland 下では正しく動作しない場合があります。}}

=== NVIDIA ドライバ ===

{{Note|バージョン 470 より前の Nvidia ドライバ(例: {{aur|nvidia-390xx-dkms}}) はハードウェア支援のある Xwayland をサポートしておらず、非 Wayland ネイティブなアプリケーションは Wayland セッションでのパフォーマンスが低下します。}}

なお、[[NVIDIA#DRM カーネルモード設定|DRM KMS]] を有効にする必要があります。また、お使いのディスプレイマネージャ(例: [[GDM#Wayland と独自の NVIDIA ドライバ|GDM]])の[https://download.nvidia.com/XFree86/Linux-x86_64/515.48.07/README/xwayland.html 公式ドキュメント]に記載されている情報も見てください。

=== Kwin Wayland デバッグコンソール ===

{{pkg|kwin}} を使用している場合、以下を実行すると、どのウィンドウが Xwayland とネイティブ Wayland を使用しているか、表面、入力イベント、クリップボードの内容などを確認することができます。

$ qdbus6 org.kde.KWin /KWin org.kde.KWin.showDebugConsole

=== Xwayland アプリケーションであることを視認する ===

アプリケーションが Xwayland 経由で実行されているかどうかを判断するには、{{AUR|extramaus}} を使用します。
アプリケーションのウィンドウ上にマウスポインタを移動して、マウスポインタが赤くなる場合は、アプリケーションが Xwayland 経由で実行されています。

または、{{pkg|xorg-xeyes}} を使用して、アプリケーションウィンドウ上でマウスポインタを移動するときに、目が動いているかどうかで確認することもできます。

他の方法として、({{Pkg|xorg-xwininfo}} の) ''xwininfo'' をターミナルウィンドウで実行するというものがあります。Xwayland ウィンドウ上にマウスポインタをホバーすると、マウスポインタが + マークに変わります。ウィンドウをクリックすると、xwininfo は情報を表示して終了しますが、ネイティブな Wayland ウィンドウでは何も起こりません。{{ic|Ctrl+C}} を押すことで xwininfo を終了できます。

あるいは、''xlsclients'' ({{Pkg|xorg-xlsclients}} パッケージ) を使用することもできます。Xwayland で動作中のアプリケーションを全てリストアップするには、{{ic|xlsclients -l}} を実行してください。

== GUI ライブラリ ==

[https://wayland.freedesktop.org/toolkits.html 公式ウェブサイト] で詳細を確認してください。

=== GTK ===

{{Pkg|gtk3}} と {{Pkg|gtk4}} パッケージは Wayland バックエンドが有効になっています。GTK ではデフォルトで Wayland バックエンドを使いますが、[[環境変数]]を設定することで Xwayland を使うように上書きできます: {{ic|1=GDK_BACKEND=x11}}。

テーマの問題は [[GTK#Wayland バックエンド]] を見てください。

=== Qt ===

[[Qt]] 5 または 6 で Wayland のサポートを有効化するには、Qt 5 と 6 に対してそれぞれ {{Pkg|qt5-wayland}} または {{Pkg|qt6-wayland}} パッケージをインストールしてください。これで、Qt アプリケーションは Wayland セッション上では Wayland で動作するようになります。

必須ではないはずですが、明示的に Wayland プラグインを使って Qt 5 アプリケーションを動作させるには、[https://wiki.qt.io/QtWayland#How_do_I_use_QtWayland.3F] にあるように、{{ic|1=-platform wayland}} を使用するか、[[環境変数]] {{ic|1=QT_QPA_PLATFORM=wayland}} をセットして下さい。

一方、Wayland セッション上で [[X11]] を使用させるには、{{ic|1=QT_QPA_PLATFORM=xcb}} と設定してください。これは、システムの Qt の実装を使用しない一部のプロプライエタリアプリケーションで必要になる場合があります。
また、{{ic|1=QT_QPA_PLATFORM="wayland;xcb"}} を使用すると、Qt が Wayland を利用できない場合に、代わりに xcb (X11)プラグインを使用させることができます。[https://www.qt.io/blog/2018/05/29/whats-new-in-qt-5-11-for-the-wayland-platform-plugin]

[[sway]] などの一部のコンポジターでは、ネイティブに実行されている Qt アプリケーションの機能が不足している場合があります。たとえば、[https://keepassxc.org KeepassXC] はトレイに最小化できません。これは、アプリケーションを実行する前に {{Pkg|qt5ct}} をインストールし、{{ic|1=QT_QPA_PLATFORMTHEME=qt5ct}} を設定することで解決できます。

=== Clutter ===

Clutter ツールキットには Wayland バックエンドがあり、Clutter を Wayland のクライアントとして動作させることが可能です。このバックエンドは {{Pkg|clutter}} パッケージで有効になっています。

Clutter アプリを Wayland 上で動作させるには、環境変数 {{ic|1=CLUTTER_BACKEND=wayland}} を設定する必要があります。

=== SDL2 ===

SDL2 アプリケーションを Wayland 上で動作させるには、{{ic|1=SDL_VIDEODRIVER=wayland}} を設定してください。

{{ic|1=SDL_VIDEODRIVER="wayland,x11"}} とすることにより、Wayland が利用できない場合に代わりに X11 ビデオドライバを使用するように SDL2 を設定できます [https://wiki.libsdl.org/SDL2/FAQUsingSDL]。ウィンドウ装飾を有効化するために {{Pkg|libdecor}} をインストールすると良いかもしれません (例えば、GNOME で)。

=== GLFW ===

{{Pkg|glfw}} パッケージには Wayland に対するサポートがあります。{{ic|1=XDG_SESSION_TYPE}} が {{ic|1=wayland}} に設定されていて、かつアプリケーションの開発者が特定のバックエンドを使用するようにしていなければ、Wayland バックエンドが使用されます。

詳細は GLFW の[https://github.com/glfw/glfw/blob/3.4/src/platform.c#L87-L99 ソースコード]を参照してください。

=== GLEW ===

{{AUR|glew-wayland}} パッケージは現在のところ、多くの GLEW ベースのアプリケーションでまだ動作しませんので、唯一の選択肢は Xwayland で {{Pkg|glew}} を使うことです。{{Bug|62713}} を参照してください。

=== EFL ===

EFL は Wayland を完全にサポートしています。Wayland で EFL アプリケーションを動かすには、Wayland の [https://wayland.freedesktop.org/efl.html プロジェクトページ] を見て下さい。

=== winit ===

Winit は [[Rust]] で書かれたウィンドウ管理ライブラリです。デフォルトでは Wayland が X11 より優先される仕様ですが、環境変数を設定することで Xwayland を使うように上書きすることができます:

* バージョン 0.29.2 より前の場合、{{ic|1=WINIT_UNIX_BACKEND=x11}} を設定してください。
* バージョン 0.29.2 以降の場合、{{ic|1=WAYLAND_DISPLAY}} を unset してください。そうすることで、強制的に {{ic|1=DISPLAY}} 変数を使用して X にフォールバックされます。[https://github.com/rust-windowing/winit/blob/baf10de95843f156b0fbad6b10c3137f1ebd4f1e/src/changelog/v0.29.md?plain=1#L134]

=== Electron ===

Wayland サポートを有効化する方法は次の2つです: アプリケーションごとのコマンドラインフラグを使って有効化するか、設定ファイルを使ってグローバルに有効化するかです。

アプリケーションがどの electron バージョンを使用しているか確認する方法については [https://stackoverflow.com/q/50345957] を見てください。

{{Note|Plasma では、一部の Electron アプリケーションで間違ったアイコン (デフォルトの Wayland アイコン) がウィンドウに表示され、一方タスクバーには正しいアイコンが表示されることがあります。この問題は、デスクトップファイルの名前を強制する特殊なアプリケーション/ウィンドウルールを作成することで解決できます。}}

==== 環境変数 ====

Electron 28 及びそれ以降を使用するアプリケーションは、[[環境変数]] [https://www.electronjs.org/docs/latest/api/environment-variables#electron_ozone_platform_hint-linux ELECTRON_OZONE_PLATFORM_HINT] を {{ic|auto}} または {{ic|wayland}} に設定することで、Wayland モードを使用することができます。

コマンドラインフラグは、この環境変数より優先されます。

==== コマンドラインフラグ ====

Electron がベースとしている Chromium とは異なり、Electron アプリケーションはデフォルトで PipeWire による WebRTC 画面共有を有効化しません。なので、Wayland 上で画面共有の問題を防ぐために {{ic|1=--enable-features=WebRTCPipeWireCapturer}} を使用することが推奨されます。画面共有は {{Pkg|xdg-desktop-portal}} をベースとしています。

環境変数を使うことが望ましくない、または不可能である場合に、{{Pkg|electron}} ベースのアプリケーションを Wayland でネイティブに使用するには、Electron 20 以降では {{ic|1=--ozone-platform-hint=auto}} フラグを使用することで可能です。

トップバーが消失してしまう場合、{{ic|1=--enable-features=WaylandWindowDecorations}} フラグを使用することで解決します。これは、典型的には [[GNOME]] で必須です ([https://github.com/electron/electron/pull/29618 electron17] からsパオートされています)。

これらのフラグを永続的に設定する方法は2つあります。1つ目は、アプリケーションの [[デスクトップエントリ#desktop ファイルの変更|.desktop ファイルを変更]]して {{ic|1=Exec=}} 行の末尾にフラグを追加する方法。もう一つは、以下で説明している設定ファイルを使用する方法で、こちらはよりきれいに設定できます。

{{Note|一部のアプリケーションは、Electron に対してフラグを渡さないため、そのアプリケーションの開発者が解決策を実装する必要があります。}}

==== 設定ファイル ====

Electron 系のパッケージは {{ic|1=~/.config/electron''XX''-flags.conf}} を読み込みます。ここで、''XX'' は Electron のバージョンです。該当するバージョンのファイルが存在しない場合、{{ic|1=~/.config/electron-flags.conf}} を代わりに読み込みます。

前述のフラグを一行ずつ書き込んでください:

{{hc|~/.config/electron-flags.conf|2=
--enable-features=WaylandWindowDecorations
--ozone-platform-hint=auto
}}

{{Note|このような設定ファイルは、公式リポジトリ内の Electron のパッケージと、それらの設定ファイルを使用するパッケージでのみ機能します。{{AUR|slack-desktop}} などのような Electron の独自のビルドをバンドルしているパッケージでは機能しません。{{AUR|slack-electron}} のように代替のパッケージが存在する場合があります。}}

==== 古い Electron バージョン ====

{{ic|electron25-flags.conf}} は Electron バージョン 25 に対してだけ適用されます。それより古い Electron のバージョンは {{ic|electron<バージョン>-flags.conf}} ファイルで設定できます。

古いバージョンでは、対応する Chromium バージョンによって異なるフラグが必要になる場合があります。例えば、以下のフラグは Electron 13 で機能します:

{{hc|~/.config/electron13-flags.conf|2=
--enable-features=UseOzonePlatform
--ozone-platform=wayland
}}

=== Java ===

[[Java]] プラットフォームのオープンソース実装である OpenJDK は、まだ Wayland のネイティブサポートを備えていません。
OpenJDK に Wayland を実装することを目的としたプロジェクトである [https://openjdk.java.net/projects/wakefield/ Wakefield] が実用できるようになるまでは、Xwayland を代わりに使用できます。

[[Debian:Wayland#Java Programs (supported since OpenJDK 16?)]] を参照してください:

:OpenJDK 16から、JRE は (Wayland をサポートしている) GTK3 を動的にロードできるようになりました。この[https://stackoverflow.com/questions/39197208/java-gui-support-on-wayland 議論]によると、これがサポートされているかもしれません。
:{{ic|_JAVA_AWT_WM_NONREPARENTING}} [[環境変数]]を "1" に設定することで、アプリケーションが空白の画面で起動する不具合を修正することができます。

== ヒントとテクニック ==

=== 自動化 ===

* [https://github.com/ReimuNotMoe/ydotool ydotool] ({{Pkg|ydotool}}) - 汎用のコマンドラインツール (wayland 以外でも利用可能)。{{ic|ydotool.service}} [[ユーザーユニット]]を[[起動/有効化]]してください。{{man|8|ydotoold}}、{{man|1|ydotool|url=https://github.com/ReimuNotMoe/ydotool/blob/master/manpage/ydotool.1.scd}} を参照。
* [https://github.com/atx/wtype wtype] ({{Pkg|wtype}}) - Wayland 用 xdotool type。{{man|1|wtype}} を参照。
* [https://github.com/boppreh/keyboard keyboard] - Windows と Linux で動作する Python ライブラリ。実験的な OS X サポートあり。[https://github.com/boppreh/mouse mouse] ライブラリも参照。
* [https://git.sr.ht/~brocellous/wlrctl wlrctl] ({{AUR|wlrctl}}) - 雑多な wlroots 拡張のためのコマンドラインユーティリティ (foreign-toplevel-management、virtual-keyboard、virtual-pointer をサポート)。

=== キーボードやマウスキーのリマップ ===

[[入力リマップユーティリティ]] を見てください。

=== X11 アプリケーションで Wayland ウィンドウをスクリーンキャストする ===

[[スクリーンキャプチャ#X11 アプリケーションで Wayland ウィンドウをスクリーンキャストする]] を見てください。

=== Chromium で完全に最大化出来ない ===

chrome://settings/appearance ''メニューから'' Use system title bar and borders'' を有効にする必要があります。

=== Waylandコンポジタをsystemdサービスとして自動的に起動する ===
{{Note|この設定はdbusセッションを破壊し,[[PipeWire#WebRTC 画面共有]]を破壊するかも知れません.}}
ディスプレイマネージャーやシェルを使いたくなければ、Waylandコンポジタを[[systemd]]サービスを使って自動的に起動できます。{{ic|ExecStart}}行を使いたいコンポジタに変えて下さい:

{{hc|/etc/systemd/system/wayland-compositor.service|2=
[Unit]
After=graphical.target systemd-user-sessions.service modprobe@drm.service
Conflicts=getty@tty1.service

[Service]
User=''username''
WorkingDirectory=~

PAMName=login
TTYPath=/dev/tty1
UnsetEnvironment=TERM

StandardOutput=journal
ExecStart=/bin/labwc -s gtklock

[Install]
WantedBy=graphical.target
}}

{{Note|[[セキュリティ#物理セキュリティ]]の為に、{{Pkg|swaylock}}や{{Pkg|gtklock}}等のスクリーンロッカーを、コンポジタの設定を通して自動的に起動する必要があるかも知れません。}}

==トラブルシューティング==

=== 色補正 ===

[[バックライト#色補正]]を参照。

=== 動作が遅い、表示がおかしい、クラッシュする ===

Gnome-shell で X から Wayland に切り替えるとグラフィック表示に問題が発生することがあります。原因として Xorg ベースの gnome-shell 用に {{ic|1=CLUTTER_PAINT=disable-clipped-redraws:disable-culling}} が設定されている可能性があります。{{ic|/etc/environment}} や rc ファイルから該当箇所を削除してみてください。

=== リモートディスプレイ ===

* ([[sway]] で使用されている) {{pkg|wlroots}} は、バージョン 0.10 より、{{Pkg|wayvnc}} を使って VNC バックエンドを提供しています。RDP バックエンドは削除されました [https://github.com/swaywm/wlroots/releases/tag/0.10.0]。
* {{pkg|mutter}} はコンパイル時にリモートデスクトップが有効化されています。詳細は [https://wiki.gnome.org/Projects/Mutter/RemoteDesktop] と {{Pkg|gnome-remote-desktop}} を見てください。
* {{pkg|krfb}} は {{pkg|kwin}} に VNC サーバを提供します。{{ic|krfb-virtualmonitor}} を使えば、他のデバイスを外部モニタとしてセットアップすることが可能です。
* 2013年に FreeRDP が Weston にマージされました。コンパイルフラグで有効化されています。{{Pkg|weston}} パッケージは、バージョン 6.0.0 より、FreeRDP が有効化されています。
* {{Pkg|waypipe}} は Wayland アプリケーションの透過プロキシです。[[SSH]] 上で動作するラッパーコマンドあり。
** 以下は、Plasma デスクトップでリモートの KDE kcalc を起動する例です:
$ waypipe ssh example.local env QT_QPA_PLATFORM=wayland-egl QT_QPA_PLATFORMTHEME=KDE dbus-launch kcalc

=== ゲームやリモートデスクトップ、仮想マシンウィンドウでの入力捕捉 ===

Xorg と異なり、Wayland では入力デバイスを独占 (グラブ) することができません (例: [https://tronche.com/gui/x/xlib/input/XGrabKeyboard.html キーボード]、[https://tronche.com/gui/x/xlib/input/XGrabPointer.html マウス])。キーボードショートカットやポインタデバイスをアプリケーションウィンドウに渡すのは Wayland コンポジタの役目となっています。

入力グラブが変わったことで以下のように既存のアプリケーションで問題が発生します:

* ホットキーや修飾キーがコンポジタによって認識されてしまい、リモートデスクトップや仮想マシンのウィンドウに送信されなくなります。
* マウスポインタがアプリケーションウィンドウに制限されなくなるため、仮想マシンやリモートデスクトップのウィンドウ内のマウスポインタの位置がホスト環境のマウスポインタとずれるようになります。

Wayland と Xwayland にプロトコル拡張を追加することで解決を図っていますが、Wayland コンポジタが拡張をサポートしている必要があり、ネイティブの Wayland クライアントの場合、ウィジェットツールキット (例: GTK, Qt) やアプリケーション自身が拡張に対応していなければなりません。Xorg アプリケーションの場合、Xwayland のサポートで十分であるため、アプリケーションやウィジェット・ツールキットに変更を加える必要はありません。

これらの拡張はすでに {{pkg|wayland-protocols}} に含まれており、{{pkg|xorg-xwayland}} によってサポートされています。

関連する拡張:

* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml Xwayland keyboard grabbing protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml Compositor shortcuts inhibit protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/relative-pointer/relative-pointer-unstable-v1.xml Relative pointer protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml Pointer constraints protocol]

サポートしている Wayland コンポジタ:

* Mutter, [[GNOME]] のコンポジタ ([https://bugzilla.gnome.org/show_bug.cgi?id=783342 リリース 3.28] 以降)。
* wlroots (Relative pointer protocols と Pointer constraints protocol に対応)
* Kwin
** [[KDE#Wayland で X11 のショートカットが衝突する]]
** [https://invent.kde.org/plasma/kwin/-/blob/master/src/wayland/keyboard_shortcuts_inhibit_v1_interface.cpp Keyboard shortcuts inhibit]

サポートしているウィジェットツールキット:

* GTK (リリース 3.22.18 以降)

=== GTK テーマが動かない ===

https://github.com/swaywm/sway/wiki/GTK-3-settings-on-Wayland を参照してください。

=== NVIDIA モジュールを読み込まないようにする ===

[[sway]] などの Wayland コンポジターを起動する前に {{ic|1=__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json}} を [[環境変数]] として追加します。

=== 拡大/サーフェススケーリング ===

スクリーンの拡大は、まだ解決していません。[https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/145 wp-surface-scale プロトコルを提供する]プルリクエストが2022年半ばにマージされました。

=== カーネル 6.11.2 (AMD) 以降、Wayland にラグ/スタッタリングが発生する ===

将来のカーネルリリースでこの問題が修正されるまで、回避策は、コマンドラインに {{ic|1=amdgpu.dcdebugmask=0x400}} を追加することです。

こちらを参照: https://community.frame.work/t/wayland-lag-stuttering-since-kernel-6-11-2/59422

== 参照 ==

* [https://wayland.freedesktop.org/docs/html/ Wayland オンラインドキュメント]
* [https://gitlab.freedesktop.org/wayland 公式リポジトリ]
* [[Fedora:How to debug Wayland problems]]
* [https://arewewaylandyet.com/ Are we Wayland yet?]
* [https://awesomeopensource.com/projects/wayland Awesome Wayland projects]
* [[カーソルテーマ]]
* [https://bbs.archlinux.org/viewtopic.php?id=107499 Arch Linux forum discussion]
* [https://github.com/swaywm/sway/wiki/i3-Migration-Guide#common-x11-apps-used-on-i3-with-wayland-alternatives i3 Migration Guide - Common X11 apps used on i3 with Wayland alternatives]
* [https://wayland.app/protocols/ Wayland Explorer - A better way to read Wayland documentation]
* [https://askubuntu.com/questions/1393618/how-can-i-tell-if-an-application-is-using-xwayland How can I tell if an application is using XWayland]

{{TranslationStatus|Wayland|2024-08-24|814878}}

ゲーム

2025-04-05T09:36:18Z

Oech3: デフォルト値の修正/* vm.max_map_count を増やす */

[[Category:ゲーム]]
[[de:Spiele]]
[[en:Gaming]]
[[lt:Games]]
[[zh-hans:Gaming]]
{{Related articles start}}
{{Related|ゲーム一覧}}
{{Related|ビデオゲームプラットフォームエミュレーター}}
{{Related|Xorg}}
{{Related|ゲームパッド}}
{{Related|Wine}}
{{Related articles end}}

Linux は長らく「非公式」のゲーミングプラットフォームと見なされてきました。ほとんどのゲーミング関連組織にとって、Linux へのサポートと Linux のターゲットユーザーは最優先事項ではありません。しかし、2021年以降、この状況に変化が現れ始めました。[[Wikipedia:ja:Valve Corporation|Valve]] などの大企業、[[Wikipedia:CodeWeavers|CodeWeavers]] グループ、そして[[Wikipedia:Open-source software development|コミュニティ]]が、Linux エコシステムに多くの改善を行い、Linux が真にゲーム用として利用可能なプラットフォームになることが可能になりました。さらに、Linux 上でもゲームをコンパイルし実行できるようにするためにクロスプラットフォームのレンダリングエンジンに移行するインディーゲーム開発者が増えつつあります。

ゲームプレイに関して言えば、ユーザーの考えの大部分は、[[Wikipedia:ja:Microsoft Windows|Microsoft Windows]] プラットフォーム専用に開発された人気のある [[Wikipedia:ja:AAA (コンピュータゲーム産業)|AAA ゲーム]]に向けられることがよくあります。これは理解できますが、Windows が唯一プレイ可能な環境であるわけではありません。このページのさらに下にある [[#ゲーム環境]] と [[#ゲームの取得]] 章を見てください。これらの章では、他のプラットフォーム上でゲームを実行するためのソフトウェアが挙げられています。

しかし、[[Wikipedia:ja:Microsoft Windows|Microsoft Windows]] 向けに書かれたゲームを Linux で動作させることに執着している場合は、別の考え方、ツール、およびアプローチが必要で、内部についての理解と機能の代替が必要になることがあります。以下の [[#ゲームの技術的情報]] を読んでください。

== ゲームの技術的情報 ==

Windows 用に開発された [[Wikipedia:ja:AAA (コンピュータゲーム産業)|AAA ゲーム]]を Linux 上でプレイしようとすると、最終的に'''3つの複雑な問題'''が立ち塞がります:

; グラフィックス SDK:
: Linux が認識できない API ([[Wikipedia:ja:DirectX|DirectX]] など) 用に開発されコンパイルされたゲーム。
; 汎用ライブラリの依存関係:
: ゲーム内でのセーブ、設定ファイルの読み込みなど、ゲームプレイ中に行うであろう一般的な操作に必要なライブラリ (例: Microsoft Visual C++、MFC、.NET)。
; 互換性のないインターフェイス:
: 上記のフレームワークとは別に、Linux が認識できない、Windows によって生成されたバイナリフォーマットやコンパイル済みコードによる問題もあります。

グラフィックス SDK は、グラフィックの呼び出しを基底のグラフィックドライバに転送し、グラフィックドライバは GPU ハードウェアと対話します。

[[Wikipedia:ja:DirectX|DirectX]] をメインの SDK として使用しているゲームは数多くあります。一方、Linux は [[Wikipedia:ja:OpenGL|OpenGL]] と [[Wikipedia:ja:Vulkan (API)|Vulkan]] しかネイティブにサポートしていません。Linux それ自体は [[Wikipedia:ja:DirectX|DirectX]] も前述の技術 (Visual C++、MFC、.NET) もサポートしていません。

代わりに、'''同一の'''機能を提供し、最終的にはグラフィックの観点から同一の結果を達成することを試みるオープンソースの代替ソフトウェアがいくつか存在します。これらには、[[Wikipedia:ja:ブラックボックス|ブラックボックス]]の観点から、オリジナルの SDK 呼び出しによって行われるであろう結果を「再発明」することを試みる独自の代替実装が含まれています。人気なものとしては以下があります:

* [[Wine]] (Wine Is Not an Emulator): "ローダー VM"、依存関係の自己記述、相互運用性などを提供します
* [[Proton]]: Wine プロジェクトからフォークされました。Valve の Steam 用に最適化されています。
* [[Wikipedia:ja:Mono (ソフトウェア)|Mono]]: .NET の代替
* [[Wikipedia:ja:Media Foundation|MF-Media]]: media foundation の依存関係

例えば、[[Wikipedia:ja:DirectX|DirectX]] における頂点の読み込み、変換、シェーディングの呼び出しは、Wine の新しい ''.dll''/''.so'' でゼロから書き直され、その関数が水面下で何を行うかについての"仮説"に基づいて呼び出しを [[Wikipedia:ja:OpenGL|OpenGL]] に転送して、実質同じ結果を達成することを試みるかもしれません。これらの呼び出しは直接的には同じであり、DirectX が実行されているかのように扱われ、パフォーマスには影響しません (ただし、これらと対話する際の初期オーバーヘッドを除く)。

しばしば、これらのツールは同時にシステム上のディストリビューションに組み込まれます。'''prefix''' (Wine 用語で、Windows サンドボックスを模倣するディレクトリを指す) が作成・設定された後、依存関係は '''prefix 内に'''インストールされ ("サンドボックス"はゲームの[[Wikipedia:ja:ライブラリ|再配布可能ライブラリ]]が依然として必要です)、しばしば [https://wiki.winehq.org/Winetricks winetricks] もインストールされます。その後、まるで Windows 内であるかのように、ゲームの実行を試みます。

最近では、この方法はほとんどのゲームでうまく行きます (Wine/Proton にはまだ存在しないカーネルドライバが必要な[https://www.keengamer.com/articles/features/opinion-pieces/kernel-level-anti-cheat-and-7-games-or-programs-that-use-it/ アンチチートで保護されているゲーム]を除いて)。ゲームが動作しない場合、通常は、互換性のないパッケージや不足している依存関係、Wine/Proton の未実装の機能が原因です。

Lutris は、ゲームをインストールする際に、依存関係を管理してくれるランナーとサンドボックスを提供するソフトウェアです。上記の手順が退屈または複雑と感じる場合に便利です。

== ゲームの一般的な依存関係 ==

Wine/Proton を使用する場合、どのようなことをしなければならないか、より深く理解するために、ゲームを実行するために必要となる一般的な依存関係を説明します。アーキテクチャについても、x86 か x64 か、できれば両方か、ということを念頭に置く必要があります。

'''ほとんどの''' Windows ゲームでは、以下の依存関係を prefix にインストールする必要があるでしょう。

=== 必須 (広く使用されている) ===

* [[Microsoft フォント|Microsoft Core フォント]]
* Microsoft Visual C++ 2015 (2017 が広く使用されているので、推奨) [2005、2008、2010、2012、2013、2015、2017-2018、2019]
* DirectX 9.0 (11.0 が広く使用されているので、推奨) [June SDK update 2010] {いくつかのコンポーネントの例を挙げると:}
** Direct3D
** Direct2D
** DirectShow
** DirectInput
** DirectPlay
** DirectSound
** DXGI
** XAudio2
* .NET Framework (3.5 がよく使用されます)
* [[OpenGL]]
** OpenAL
** OpenAI
** OpenCL
* [[Vulkan]]

=== 任意 (しかし、よく使われている) ===

* XNA
* PhysX
* Media Foundation
* Quicktime
* Adobe Reader 11
* [[Java]] SRE ([[Minecraft]] などで)

=== 稀 (あまり一般的でない) ===

* Gamespy
* MIDI driver
* ACDSee

== マシン要件 ==

ゲームが必要とする依存関係をプレフィックスに入れるだけでは十分ではありません。カーネルそのものが、ゲームが行う呼び出しに対応する代替が必要です。すでに述べたように、ドライバと代替品が利用可能です。

=== ドライバー ===

* AMD ドライバー: [[AMDGPU]] を参照。
* Intel ドライバー: [[Intel graphics]] を参照。
* NVIDIA ドライバー: [[NVIDIA]] を参照。

=== マシンと代替品への依存性 ===

{{Note|以下の情報は参考程度です。これらのパッケージの一部は、主要なパッケージをインストールした際に一緒にインストールされます。}}

* [[Wine]]
* {{Pkg|wine-gecko}}
* {{Pkg|wine-mono}}
* [[Vulkan]]
* [[OpenGL]]
* [[Proton]] 再配布可能パッケージ (オプションですが、役立つ場合があります)
* {{AUR|wine-ge-custom}} または [https://github.com/Tk-Glitch/PKGBUILDS/tree/master/wine-tkg-git TKG] (オプション。失敗しないかぎり) : 特定のゲームのパッチを含む、特別にコンパイルされた wine バージョン。

== ゲーム環境 ==

Wine/Proton 以外にもゲームをプレイする方法はあります。Linux でゲームをプレイするための環境は様々あり、これらの環境では Windows と同じくらい (あるいはそれ以上) のゲームが存在します:

* ネイティブ – Linux プラットフォーム向けのビルドが存在し、OpenGL や Vulkan グラフィックス API のサポートのあるゲーム。
* [[Wikipedia:ja:エミュレータ|エミュレータ]] – 他のアーキテクチャやシステム用に設計されたソフトウェアを実行する際に必要です。ほとんどのゲームは ROM をエミュレータに読み込ませれば特に設定せずとも動き、問題が発生することは稀です。エミュレータのリストは [[ビデオゲームプラットフォームエミュレーター]] を参照してください。
* [[Java]] - Write once, run everywhere (一度書けば、どこでも動く) なプラットフォームです。Linux でも動く人気なゲームとしては、[[Minecraft]]、[[RuneScape]]、[[Wikipedia:Wurm_Online|Wurm Online]]、[[Wikipedia:Puzzle_Pirates|Puzzle Pirates]] があります。
* ウェブ – ウェブブラウザ内で動くゲームです。
** HTML5 ゲームは canvas と WebGL の技術を使用し、最近のブラウザ全てで動作可能です。
** [[Flash]] ベースのゲーム – プレイするにはプラグインをインストールする必要があります。
* [[Wine]] – Windows 互換レイヤーです。Unix ライクなオペレーティングシステム上で Windows アプリケーション (だけでなく多くのゲームも) を動かせるようにします。[[Wine#DXVK]] を使用すれば、ランタイムで DirectX から Vulkan への変換もサポートし、DirectX しかサポートしていないゲームでパフォーマンスを向上させることができます。
* [[仮想マシン]] – ゲームと互換性のあるオペレーティングシステム (Windows など) をインストールするために使用できます。[[VirtualBox]] には優れた 3D サポートがあります。これに加えて、互換性のあるハードウェアを使用している場合は、Windows KVM ゲストへの VGA パススルー (キーワードは [https://docs.kernel.org/driver-api/vfio.html "virtual function I/O" (VFIO)]) や [[OVMF による PCI パススルー]]も可能です。
* [https://steamcommunity.com/games/221410/announcements/detail/1696055855739350561 Proton/DXVK] – プロプライエタリな {{Pkg|steam}} プラットフォームで使用するために設計された、Wine のフォークです。Wine よりも優れたゲームへのサポートを可能にします。詳細は [[Steam#Proton Steam-Play]] を参照してください。

== ゲームの互換性 ==

=== vm.max_map_count を増やす ===

Arch Linuxでは、 {{ic|vm.max_map_count}}は1048576となっていますが、一部のゲームにおいては小さすぎる可能性があります [https://www.phoronix.com/news/Fedora-39-VM-Max-Map-Count]。なので、以下のような [[sysctl]] 設定ファイルを作成してサイズを永続的に大きくしておきましょう:

{{hc|/etc/sysctl.d/80-gamecompatibility.conf|2=
vm.max_map_count = 2147483642
}}

'''2147483642''' (MAX_INT - 5) は SteamOS でのデフォルト値です。Fedora では、'''1048576''' が安全な値であるとされています [https://www.phoronix.com/news/Fedora-39-Max-Map-Count-Approve]。

再起動せずに変更を適用するには、以下を実行してください:

# sysctl --system

{{Note|この設定により、コアダンプファイルを読み込もうとする古いプログラムとの互換性が壊れる可能性があります [https://github.com/torvalds/linux/blob/v5.18/include/linux/mm.h#L178]。}}

== ゲームの取得 ==

Linux で利用できるゲームであったとしても、それがネイティブに動作するとは限りません。[[Wine]] や [[Proton]] と一緒に事前にパッケージングされていることもあります。

[[公式リポジトリ]]や [[AUR]] にある Arch 用にパッケージングされたゲームのリストは、[[ゲーム一覧]] を見てください。

* {{App|Athenaeum|Steam の代替自由ソフトウェア。|https://gitlab.com/librebob/athenaeum|{{AUR|athenaeum-git}}}}
* {{App|Flathub|[[Flatpak]] の中央リポジトリ。ゲームセクションはまだ小さいですが、大きくなりつつあります。|https://flathub.org/apps/category/Game|{{Pkg|flatpak}}、{{Pkg|discover}}、{{Pkg|gnome-software}}}}
* {{App|[[Wikipedia:ja:GOG.com|GOG.com]]|DRM の無いゲームストア。|https://www.gog.com|{{AUR|lgogdownloader}}、{{AUR|wyvern}}、{{AUR|minigalaxy}}}}
* {{App|Heroic Games Launcher|GOG と Legendary の GUI。Epic Games Launcher のオープンソースな代替ソフトウェア。|https://heroicgameslauncher.com/|{{AUR|heroic-games-launcher}}}}
* {{App|[[Wikipedia:ja:itch.io|itch.io]]|インディーゲームストア。|https://itch.io|{{AUR|itch-setup-bin}}}}
* {{App|Legendary|Epic Games Launcher のフリーでオープンソースな代替ソフトウェア。|https://github.com/derrod/legendary|{{AUR|legendary}}}}
* {{App|[[Wikipedia:Lutris|Lutris]]|Linux 用のオープンなゲーミングプラットフォーム。GOG、Steam、Battle.net、Origin、Uplay、その他多くのソースからゲームを取得できます。Lutris は、様々な[https://lutris.net/games ゲームランナー]を使用しており、完全にカスタマイズ可能な設定オプションを使用してゲームを起動することができます。|https://lutris.net|{{Pkg|lutris}}}}
* {{App|Play.it|ネイティブパッケージのビルドを自動化します。[[Wine]]、[[DOSBox]]、ScummVM のゲームもサポートしています。|https://www.dotslashplay.it/|{{AUR|play.it}}}}
* {{App|Rare|Legendary のもう一つの GUI。PyQt5 をベースとしています。|https://github.com/Dummerle/Rare|{{AUR|rare}}}}
* {{App|[[Steam]]|Valve によって開発されている、デジタル配信及びコミュニケーションのためのプラットフォーム。|https://store.steampowered.com|{{Pkg|steam}}}}

Wine のラッパーに関しては、[[Wine#サードパーティ製アプリケーション]] を参照してください。

== ゲームの設定 ==

特定のゲームや、ゲームのタイプによっては実行するのに特別な設定を必要としたり、または設定されていることが前提になっていることがあります。大抵のゲームは、何も設定をしなくても Arch Linux で動作し、コンパイル時の最適化によって、他のディストリビューションよりもパフォーマンスが出ることもあります。しかしながら、特別な環境を使っている場合、希望通りにゲームをスムーズに実行するために多少の設定やスクリプトが必要になるでしょう。

=== マルチスクリーン環境 ===

マルチスクリーン環境ではフルスクリーンのゲームで問題が発生することがあります。そのようなときは、[[#別の X サーバーでゲームを起動する|別の X サーバーを実行する]]のが一つの解決方法になりえます。他の方法は [[NVIDIA#Twinview を使ってゲームを遊ぶ|NVIDIA の記事]]を見てみて下さい。

=== キーボード操作 ===

多くのゲームはキーボードの入力を横取りするため、ウィンドウの切り替え (alt-tab) ができなくなることがあります。

一部の SDL のゲーム (例: Guacamelee) では {{ic|Ctrl-g}} を押すことでキーボードの占有を無効にすることが可能です。

{{Note|SDL はときどき入力システムを使うことができなくなることが知られています。そのような場合は、数秒間待機すると入力できるようになることがあります。}}

=== 別の X サーバーでゲームを起動する ===

上記のような場合だと、別の X サーバーを実行するのが必要もしくは望ましいかもしれません。もう一つの X サーバーを実行することには複数の利点が存在します。より良いパフォーマンス、{{ic|Ctrl+Alt+F7}}/{{ic|Ctrl+Alt+F8}} を使ってゲームを"最小化"することができる、ゲームがグラフィックドライバーと問題を起こしてもメインの X サーバーはクラッシュしないなどです。新しい X サーバーは ALSA へのリモートアクセスログインと同じく、ユーザーは音声を聞くために {{ic|audio}} グループに入っている必要があります。

別の X サーバーを起動するには次のようにします (例として [https://www.xonotic.org/ Xonotic] を使っています):

$ xinit /usr/bin/xonotic-glx -- :1 vt$XDG_VTNR

さらに、別の X 設定ファイルを使うことでカスタマイズすることもできます:

$ xinit /usr/bin/xonotic-glx -- :1 -xf86config xorg-game.conf vt$XDG_VTNR

別の ''xorg.conf'' を使う理由としては、メインの設定で NVIDIA の Twinview を使って Xonotic のような 3D ゲームをマルチスクリーンの中央、全ての画面にまたがって、レンダリングしている場合などがあります。これが望ましくない場合は、セカンドスクリーンを無効にした設定を使って二番目の X を起動するのが良いでしょう。注意点として、この X 設定ファイルの場所は {{ic|/etc/X11}} ディレクトリからの相対パスとなります。

Openbox を利用してホームディレクトリや {{ic|/usr/local/bin}} でゲームを起動するスクリプトは以下のようになります:

{{hc|~/game.sh|<nowiki>
if [ $# -ge 1 ]; then
game="$(which $1)"
openbox="$(which openbox)"
tmpgame="/tmp/tmpgame.sh"
DISPLAY=:1.0
echo -e "${openbox} &\n${game}" > ${tmpgame}
echo "starting ${game}"
xinit ${tmpgame} -- :1 -xf86config xorg-game.conf || exit 1
else
echo "not a valid argument"
fi
</nowiki>}}

ファイルを[[実行可能属性|実行可能]]にしたら、次のようにしてスクリプトを使うことが可能です:

$ ~/game.sh xonotic-glx

{{Note|{{ic|/etc/X11/xorg.conf.d}} 内の設定ファイルをロードさせたくない場合は、{{ic|-configdir}} オプションを使って、空のディレクトリを指すようにすると良いでしょう。}}

=== マウス検出の調整 ===

マウスの素早い操作が鍵を握るゲームの場合、[[マウスのポーリングレート]]を調整することで精度を上げられます。

=== OpenAL とバイノーラル音声 ===

[[Wikipedia:ja:OpenAL|OpenAL]] を使っているゲームでは、ヘッドフォンを使用している場合、OpenAL の [[Wikipedia:ja:頭部伝達関数|HRTF]] フィルターを使ってより良いポジショナルオーディオを得ることができます。有効にするには、以下のファイルを[[作成]]してください:

{{hc|~/.alsoftrc|2=
hrtf = true
}}

または、AUR から {{AUR|openal-hrtf}} をインストールして、{{ic|/etc/openal/alsoftrc.conf}} のオプションを編集して下さい。

Source エンジンのゲームの場合、HRTF を有効にするにはゲーム内設定の `dsp_slow_cpu` を `1` に設定します。設定しなかった場合は代わりに自前の処理がゲームによって有効にされます。また、ネイティブランタイムを使うように Steam を設定するか、または openal.so のネイティブランタイムのコピーをローカルコピーにリンクさせる必要があります。完全性のために、以下のオプションを使って下さい:

dsp_slow_cpu 1 # Disable in-game spatialiazation
snd_spatialize_roundrobin 1 # Disable spatialization 1.0*100% of sounds
dsp_enhance_stereo 0 # Disable DSP sound effects. You may want to leave this on, if you find it does not interfere with your perception of the sound effects.
snd_pitchquality 1 # Use high quality sounds

=== PulseAudio の調整 ===

[[PulseAudio]] を使っている場合、最適な動作をさせるためにデフォルト設定から変更することができる部分がいくつかあります。

==== Realtime 優先度と負の nice レベルを有効にする ====

PulseAudio はオーディオデーモンとしてリアルタイムの優先度で実行されるようにビルドされます。しかしながら、システムがロックアップする可能性があるというセキュリティ上のリスクのため、デフォルトでは標準のスレッドと同じようにスケジューリングされます。これを変更するには、まずユーザーを {{ic|audio}} グループに追加してください。そして、{{ic|/etc/pulse/daemon.conf}} の以下の行をアンコメント・編集してください:

{{hc|1=/etc/pulse/daemon.conf|2=
high-priority = yes
nice-level = -11

realtime-scheduling = yes
realtime-priority = 5
}}

編集したら pulseaudio を再起動します。

==== 高品質なリミックスを使ってサウンドを良くする ====

Arch の PulseAudio ではリミックスチャンネルにデフォルトで speex-float-0 を使っていますが、これはやや低品質なリミックスとされています。あなたのシステムに負担を増やす余裕がある場合は、以下の設定をすることでサウンドを良くすることが可能です:

resample-method = speex-float-10

==== ハードウェアバッファを Pulse のバッファリングに合わせる ====

バッファをあわせることで音の途切れを減らし、ほんの僅かですがパフォーマンスを向上させることができます。詳しくは [https://forums.linuxmint.com/viewtopic.php?f=42&t=44862 ここ] を見て下さい。

== リモートプレイ ==

[[Wikipedia:ja:クラウドゲーム|クラウドゲーム]]は、クライアント側のハードウェア要件が低いため、近年大きな人気を集めています。クラウドゲームにおいて唯一重要なことは、最低速度が 5 から 10 Mbit/s (ビデオ品質やフレームレートに依ります) の安定したインターネット接続です (イーサネットケーブル接続か 5 GHz WiFi を推奨)。

ネットワーク経由でのゲームパッドの使用を通常サポートしていないサービスで、ネットワーク経由でゲームパッドを使用する方法については、[[ゲームパッド#ネットワークを介して Gamepad を使う]] を見てください。

{{Note|ブラウザで動作するサービスのほとんどは、たいてい {{AUR|google-chrome}} との互換性しか保証していません。}}

{| class="wikitable sortable" style="text-align: center;"
! サービス
! class="unsortable" | インストーラ
! ブラウザクライアントでの利用
! 自身のホストを使う
! ホストの貸出
! フルデスクトップサポート
! コントローラサポート
! class="unsortable" | 備考
|-
| [https://dixper.gg/ Dixper] || {{-}} || {{Yes}} || {{Y|Windows のみ}} || ? || ? || ? || {{-}}
|-
| [https://reemo.io/ Reemo] || {{AUR|reemod-bin}} || {{Y|Chromium ベースブラウザのみ}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Y|Windows のみ}} || ウェブサイトのダウンロードセクションにある公式インストールスクリプトでソフトウェアをインストールすることもできます。
|-
| [https://xbox.com/play Xbox Cloud] || {{AUR|xbox-cloud-gaming}} || {{Yes}} || {{No}} || {{No}} || {{No}} || {{Yes}} || XCloud を使用するには Game Pass Ultimate が必要です。
|-
| [[GeForce Now]] || {{-}} || {{Yes}} || {{No}} || {{No}} || {{Yes}} || {{Yes}} || このサービスを使用するには、Steam、Epic Client、あるいは GOG 上のゲームが必要です。
|-
| [https://moonlight-stream.org/ Moonlight] || {{AUR|moonlight-qt}} || {{No}} || {{Yes}} || {{No}} || {{Yes}} || {{Yes}} || これは単なるクライアントです。ホストマシンは GeForce Experience (Windows のみ) か [https://github.com/SunshineStream/Sunshine Sunshine] (マルチプラットフォーム) を使用しなければなりません。
|-
| [https://parsec.app/ Parsec] || {{AUR|parsec-bin}} || {{Yes}} (実験的) || {{Y|Windows のみ}} || {{No}} || {{Yes}} || {{Yes}} || クラウドホスティングは[https://support.parsecgaming.com/hc/en-us/articles/360031038112-Cloud-Computer-Update もはや利用できなくなっています]{{Dead link|2023|05|06|status=404}}。
|-
| [https://github.com/mbroemme/vdi-stream-client VDI Stream Client] || {{AUR|vdi-stream-client}} || {{No}} || {{Y|Windows のみ}} || {{No}} || {{Yes}} || {{No}} || 3D GPU アクセラレーションと組み込みの USB リダイレクトをサポートしている VDI クライアント。
|-
| [https://playkey.net/ Playkey] || {{AUR|playkey-linux}} || ? || ? || ? || ? || ? || {{-}}
|-
| style="white-space:nowrap" | [https://www.playstation.com/en-gb/ps-now/ps-now-on-pc/ PlayStation Now] || [[Wine]] か [[Steam]] の Proton で動作します。 || {{No}} || {{No}} || {{-}} || {{No}} || {{Yes}} || PC 上で PS4、PS3、PS2 のゲームをプレイできます。あるいは、[[ビデオゲームプラットフォームエミュレーター|エミュレータ]]を使うという手もあります。
|-
| style="white-space:nowrap" | [https://www.playstation.com/en-us/remote-play/ PlayStation Remote Play] || {{AUR|chiaki}} || {{No}} || {{Yes}} || {{-}} || {{Yes}} || {{Yes}} || PS4 や PS5 のゲームを PC でプレイできます。
|-
| [https://rainway.com/ Rainway] || 2019 Q3 に登場予定。 || {{Yes}} || {{Y|Windows のみ}} || {{No}} || {{Yes}} || ? || {{-}}
|-
| [https://shadow.tech/ Shadow] || '''安定版:''' {{AUR|shadow-tech}} '''ベータ版''': {{AUR|shadow-beta}} || {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || コントローラサポートは USB over IP に依存しています。現在、AVC のみのサポートとなっており、HEVC はサポートされていません。
|-
| [[Steam#Steam Remote Play|Steam Remote Play]] || {{pkg|steam}} に含まれています || {{No}} || {{Yes}} || {{No}} || {{No}} || {{Yes}} || {{-}}
|-
|-
| [https://stadia.google.com Stadia] || {{-}} || {{Yes}} || {{No}} || {{No}} || {{Yes}} || {{Yes}} || サービスは2023年1月18日に終了します。
|-
| [https://vortex.gg/ Vortex]{{Dead link|2024|01|29|status=404}} || {{-}} || {{Yes}} || {{No}} || {{-}} || {{No}} || ? || {{-}}
|-
| [[VNC]] || {{pkg|tigervnc}} or {{pkg|x11vnc}} || {{No}} || {{Yes}} || {{No}} || {{Yes}} || {{No}} || 汎用のリモートデスクトッププロトコル。LAN 経由でゲームする場合には、レイテンシは十分に低いはずです。ゲームパッドのサポートについては [[ゲームパッド#ネットワークを介して Gamepad を使う]] を見てください。
|-
| [[xrdp]] || {{AUR|xrdp}} || {{No}} || {{Yes}} || {{No}} || {{Yes}} || {{No}} || もう一つの汎用リモートデスクトッププロトコル。[[xrdp#グラフィックアクセラレーション|グラフィカルアクセラレーション]]を設定すれば、OpenGL 及び Vulkan の両方がサポートされます。LAN 経由でゲームをする場合におすすめです。ゲームパッドのサポートについては [[ゲームパッド#ネットワークを介して Gamepad を使う]] を見てください。
|-
| [[X11 フォワーディング]] || {{pkg|openssh}} || {{No}} || {{Yes}} || {{No}} || {{No}} || {{No}} || [[VirtualGL]] による SSH 経由での X フォワーディングは OpenGL をサポートしており、全てではありませんが一部のゲームで動作します。ゲームパッドのサポートについては [[ゲームパッド#ネットワークを介して Gamepad を使う]] を見てください。
|-
| [https://boosteroid.com/ Boosteroid] || {{AUR|boosteroid}} || {{Yes}} || {{No}} || {{No}} || {{Yes}} || {{Yes}} || このサービスを使用するにはデジタル配信プラットフォーム (Steam、EGS、Origin など) 上のゲームが必要です。全てのゲームが利用できるわけではありません。ゲームの完全なリストを見るにはサインアップ (無料) する必要があります。デジタル配信プラットフォーム上であなたが所有しているゲームを起動するには、サブスクリプションを購入する必要があります。
|-
| [https://www.blacknut.com/ Blacknut] || {{AUR|blacknut-appimage}} または [https://www.blacknut.com/en/download/linux Blacknut AppImage] || {{Yes}} || {{No}} || {{No}} || {{Yes}} || {{Yes}} || このサービスを使用するにはサブスクリプションが必要です。全てのゲームが利用できるわけではありません。
|}

== パフォーマンスを向上させる ==

メインの記事 ([[パフォーマンスの向上]]) も参照してください。Wine プログラムに関しては、[[Wine#パフォーマンス]] を見てください。素晴らしいゲーミング体験のためには、低遅延、(変動のない) 安定した応答時間、十分なスループット (FPS) が必要です。
小さな変動のある源が複数存在すると、それらが時々重なり合って、顕著なカクつきを生み出してしまうでしょう。ゆえに、ほとんどの場合、スループットを少し下げて、応答時間の安定性を増やすことが推奨されます。

=== clock_gettime のスループットを改善する ===

ユーザ空間のプログラム (特にゲーム) は、現在の時刻を取得する {{man|2|clock_gettime}} をたくさん呼び出して、ゲームの物理演算や fps の計算などを行います。時間の使用頻度は以下を実行することで確認できます:

# perf top

read_hept (または acpi_pm_read) のオーバーヘッドを見てください。

あなたが非常に正確なタイマーを必要としていないならば、hpet (high precision event timer) や acpi_pm (ACPI Power Management Timer) から、より高速な TSC (time stamp counter) タイマーに切り替えることができます。TSC を利用可能にし有効化するには、以下の[[カーネルパラメータ]]を追加してください:

tsc=reliable clocksource=tsc

その後、再起動し、以下を実行して clocksource を確認してください:

# cat /sys/devices/system/clocksource/clocksource*/current_clocksource

以下を実行すれば、現在利用可能なタイマーすべてを確認できます:

# cat /sys/devices/system/clocksource/clocksource*/available_clocksource

このコマンドで表示されたタイマー名を current_clocksource に echo する (つまり、書き込む) ことで、タイマーを変更することができます。Zen 3 システムにおける [https://gist.github.com/weirddan455/eb807fa48915652abeca3b6421970ab4] のベンチマークでは、{{ic|hpet}} や {{ic|acpi_pm}} と比べて {{ic|tsc}} のスループットのほうが約50倍良くなっています。

{{Warning|{{ic|tsc}} タイマーの信頼性が乏しい場合にこのタイマーを強制すると、{{ic|clock_gettime(CLOCK_MONOTONIC)}}[https://mastodon.yuuta.moe/@coelacanthus/110996261222325004] の単調増加性 (Firefox はこれに依存しています) が破壊され、Firefox がランダムにクラッシュする原因になります。このタイマーは自己責任で使用してください!}}

=== カーネルパラメータを調整して応答時間を安定化させる ===

リアルタイムカーネルにはデフォルトでいくつかのメリット ([[リアルタイムカーネル]]の記事を参照) がありますが、CPU のスループットが犠牲になり、また割り込み処理が遅延する可能性もあります。ちなみに、リアルタイムカーネルは {{Pkg|nvidia-open-dkms}} とは互換性がなく、デフォルトのプロセススケジューリングタイプである SCHED_NORMAL (SCHED_OTHER とも呼ばれる) のプロセスのスケジューラは変更しません。以下のようにカーネルパラメータを変更すると、リアルタイムカーネルおよび他のカーネル (デフォルトの linux カーネルなど) の応答時間をさらに安定化させます:

(Transparent) Hugepage の割り当てに対する proactive compaction は、割り当ての平均時間を減少させますが、最大時の時間を減らすとは限りません。Proactive compaction は、[https://docs.kernel.org/admin-guide/sysctl/vm.html カーネルのドキュメント]によると応答時間の揺れを生じさせるので ([https://nitingupta.dev/post/proactive-compaction/ 内部での動作])、無効化してください:

# echo 0 > /proc/sys/vm/compaction_proactiveness

メモリの断片化が発生した場合にページブロック1つ (x86_64 では 2MB) だけをデフラグするようにするために、watermark boost factor を減らしてください。こうすることで、メモリの断片化の発生後、アプリケーションのデータがプロセッサキャッシュの最終レベルに残りやすくなります。

# echo 1 > /proc/sys/vm/watermark_boost_factor

RAM の空き領域が十分にある場合、メモリアロケーション時に応答時間が悪化することを防ぐために、minimum free Kilobytes の値を増やしてください: [http://highscalability.com/blog/2015/4/8/the-black-magic-of-systematically-reducing-linux-os-jitter.html][https://docs.kernel.org/admin-guide/sysctl/vm.html]。この値を 1024 KB 以下、もしくはシステムメモリの 5% より大きい値に設定しないでください。1GB を予約するには:

# echo 1048576 > /proc/sys/vm/min_free_kbytes

RAM の空き領域が十分にある場合、アロケーション時に応答時間が増加する可能性をさらに減らすために、watermark scale factor を増やしてください (説明: [https://blogs.oracle.com/linux/post/anticipating-your-memory-needs][https://blogs.oracle.com/linux/post/anticipating-your-memory-needs-2])。Watermark の位置を RAM の 5% に設定するには:

# echo 500 > /proc/sys/vm/watermark_scale_factor

システムの空きメモリ領域が不足していない限りスワップを防ぐために (スワップはページをロックするので、レイテンシを増加させ、ディスク IO を使用します)、swappiness を減らしてください:

# echo 10 > /proc/sys/vm/swappiness

Multi-Gen Least Recently Used (MGLRU) を有効化してください (小さなパフォーマンスコストでロック競合の可能性を減らします [https://docs.kernel.org/admin-guide/mm/multigen_lru.html]):

# echo 5 > /sys/kernel/mm/lru_gen/enabled

Zone reclaim を無効化してください (zone reclaim はメモリページをロック・移動するので、レイテンシのスパイクを発生させます):

# echo 0 > /proc/sys/vm/zone_reclaim_mode

パフォーマンスコストの観点から Transparent HugePages (THP) を無効化してください。デフラグメンテーションが無効化されている場合でも、THP はレイテンシのスパイクを発生させるかもしれません。[https://docs.kernel.org/admin-guide/mm/transhuge.html][https://alexandrnikitin.github.io/blog/transparent-hugepages-measuring-the-performance-impact/] madvise と advise を使用することで、アプリケーションが明示的に要求した場合に限り有効化します:

{{bc|
# echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
# echo advise > /sys/kernel/mm/transparent_hugepage/shmem_enabled
# echo never > /sys/kernel/mm/transparent_hugepage/defrag
}}

あなたのゲームが TCMalloc を使用する場合 (例: Dota2、CS:GO)、パフォーマンスが大幅に低下してしまうので、THP を無効化することは推奨されません。[https://github.com/google/tcmalloc/blob/master/docs/tuning.md#system-level-optimizations]

適切なスループットを維持しつつ、ページロック取得のレイテンシの最大値を減らします [https://www.phoronix.com/review/linux-59-unfairness][https://openbenchmarking.org/result/2009154-FI-LINUX58CO57&sro][https://www.phoronix.com/review/linux-59-fairness]:

# echo 1 > /proc/sys/vm/page_lock_unfairness

スケジューラの設定を調整します。以下のスケジューラの設定は {{AUR|cfs-zen-tweaks}} と衝突するので、それぞれの設定に対してプロバイダを1つだけ選んでください。デフォルトでは、linux カーネルのスケジューラはレイテンシではなくスループットに対して最適化されています。以下のお手製の設定はそれを変更し、異なるゲームにおいてテストされ、顕著な改善が確認されています。これらの設定はあなたのユースケースに対しては最適ではないかもしれません。必要に応じてこれらの設定を変更することを検討してください [https://access.redhat.com/solutions/177953][https://doc.opensuse.org/documentation/leap/tuning/html/book-tuning/cha-tuning-taskscheduler.html][https://www.amd.com/system/files/documents/58016-epyc-9004-tg-java.pdf#page=29]:

{{bc|
# echo 0 > /proc/sys/kernel/sched_child_runs_first
# echo 1 > /proc/sys/kernel/sched_autogroup_enabled
# echo 3000 > /proc/sys/kernel/sched_cfs_bandwidth_slice_us
# echo 3000000 > /sys/kernel/debug/sched/base_slice_ns
# echo 500000 > /sys/kernel/debug/sched/migration_cost_ns
# echo 8 > /sys/kernel/debug/sched/nr_migrate
}}

==== 設定の変更を永続化させる ====

通常、[[カーネルパラメータ]]を永続的に変更するには、[[sysctl]] の設定ファイルを作成したり、[[ブートローダー]]の設定を変更したりすることが推奨されます。しかし、上記の設定の変更は procfs ({{ic|/proc}}、sysctl を含む) と sysfs ({{ic|/sys}}) の両方に渡っているので、最も便利な方法は [[systemd-tmpfiles]] を使用することです:

{{hc|/etc/tmpfiles.d/consistent-response-time-for-gaming.conf|
# Path Mode UID GID Age Argument # default value as of linux 6.6
w /proc/sys/vm/compaction_proactiveness - - - - 0 # 20
w /proc/sys/vm/watermark_boost_factor - - - - 1 # 15000
w /proc/sys/vm/min_free_kbytes - - - - 1048576 # 67584
w /proc/sys/vm/watermark_scale_factor - - - - 500 # 10
w /proc/sys/vm/swappiness - - - - 10 # 60
w /sys/kernel/mm/lru_gen/enabled - - - - 5 # 7
w /proc/sys/vm/zone_reclaim_mode - - - - 0 # 0
w /sys/kernel/mm/transparent_hugepage/enabled - - - - madvise # always
w /sys/kernel/mm/transparent_hugepage/shmem_enabled - - - - advise # never
w /sys/kernel/mm/transparent_hugepage/defrag - - - - never # madvise
w /proc/sys/vm/page_lock_unfairness - - - - 1 # 5
w /proc/sys/kernel/sched_child_runs_first - - - - 0 # 0
w /proc/sys/kernel/sched_autogroup_enabled - - - - 1 # 1
w /proc/sys/kernel/sched_cfs_bandwidth_slice_us - - - - 3000 # 5000
w /sys/kernel/debug/sched/base_slice_ns - - - - 3000000 # 3000000
w /sys/kernel/debug/sched/migration_cost_ns - - - - 500000 # 500000
w /sys/kernel/debug/sched/nr_migrate - - - - 8 # 32
}}

その後、再起動し、値が正しく反映されていることを確認してください。

=== 共有オブジェクトを即座に読み込んで初回の遅延を減らす ===

使用するゲームに対して以下の[[環境変数]]を設定してください:

LD_BIND_NOW=1

これにより、プログラムコードを実行時に読み込む必要性がなくなり ({{man|8|ld.so}} を参照)、関数が初めて呼ばれたときの遅延をなくします。システム上に実際には存在せず決して呼ばれないライブラリにリンクしている ''startplasma-x11'' などのプログラムに対してこの変数を設定しないでください。この場合、プログラムは起動時に存在しない共有オブジェクトにリンクしようとして失敗するので、問題の特定は簡単です。ほとんどのゲームはこの変数を有効化した状態で問題なく起動するはずです。

=== ユーティリティ ===

==== Gamemode ====

[[Gamemode]] は、ゲームがホスト OS に最適化のセットを一時的に適用するように要求できるようにする、Linux 用のデーモン/ライブラリの組です。これによりゲームのパフォーマンスを向上できます。

==== Gamescope ====

[[Gamescope]] は、Valve によって開発されているマイクロコンポジタです。Steam Deck で使用されています。このプロジェクトの目的は、ゲーミング向けに調整され、多くのゲーム中心の機能をサポートする独立したコンポジタを提供することです。

=== ACO コンパイラ ===

{{Note|以下の方法は、'''[[AMDGPU]]''' ドライバを動作させている AMD GPU で'''しか'''動作しません。}}

[[AMDGPU#ACO コンパイラ]] を参照。

=== DRI の遅延を軽減する ===

Direct Rendering Infrastructure (DRI) の設定ファイルは、Mesa と Nouveau を含むすべての DRI ドライバに適用されます。{{ic|/etc/drirc}} を編集することで DRI の設定をシステム全体に対して変更することができますし、{{ic|$HOME/.drirc}} を編集すればユーザ単位で変更できます。これらのファイルが存在しない場合、まず作成する必要があります。両方のファイルは同じ構文を使用します。オプションに関するドキュメントは https://dri.freedesktop.org/wiki/ConfigurationOptions/ で見られます。vblank との同期を無効化することで入力の遅延を減らすには、以下を追加してください:

<driconf>
<device>
<application name="Default">
<option name="vblank_mode" value="0" />
</application>
</device>
</driconf>

=== スケジューリングポリシーによってフレームレートやレスポンスを改善する ===

カーネルがタスクを優先順位付けできるように適切なスケジューリングポリシーを与えれば、ほとんどのゲームにおいて利益を得られます。これらのポリシーは、理想的にはアプリケーション自体によってスレッドごとに設定されるべきです。

アプリケーション自体がスケジューリングポリシーを実装していない場合、{{Pkg|schedtool}} というアプリケーションとそれに関連するデーモンの {{AUR|schedtoold}} を使えば、これらのタスクの多くを自動的に処理できます。

どのプログラムがどのポリシーを使用するかを編集するには、{{ic|/etc/schedtoold.conf}} を編集し、プログラム名の後に必要な ''schedtool'' 引数を追加してください。

==== ポリシー ====

{{ic|SCHED_ISO}} (-pf や -ck [[カーネル]]で使用されている BFS/MuQSSPDS スケジューラでのみ実装されています) は、プロセスが CPU の最大80%まで使用できるようになるだけでなく、できるかぎり遅延とスタッタリングを減らすことにつながります。全てではなくとも多くのゲームで効果が得られます:

bit.trip.runner -I

{{ic|SCHED_FIFO}} は、より良く機能する代替を提供します。あなたのアプリケーションが {{ic|SCHED_FIFO}} でよりスムーズに動作するかを確認してみるべきでしょう。スムーズに動作する場合は、{{ic|SCHED_FIFO}} を代わりに使用すべきです。とはいえ、{{ic|SCHED_FIFO}} はシステムのリソースを枯渇させるリスクがあるので、注意してください。以下のよな -I が使用されるケースでこれを使用します:

bit.trip.runner -F -p 15

==== Nice レベル ====

次に、先に処理させる必要があるタスクを昇順に nice レベルを設定します。ゲームなど、マルチメディアのタスクは基本的に nice レベルを -4 にすることが推奨されています:

bit.trip.runner -n -4

==== コアアフィニティ ====

ドライバーがマルチスレッドするべきか、あるいはプログラムがマルチスレッドするべきかは、開発において多少の混乱が存在します。ドライバとプログラムの両方に同時にマルチスレッドさせてしまうと、フレームレートの低下などの大幅なパフォーマンスの劣化が発生し、クラッシュのリスクを増加させてしまいます。最近のゲームや、[[Wikipedia:ja:GLSL|GLSL]] を無効にしないで実行される Wine プログラムなどがこの例に含まれます。単一のコアを選択して、ドライバーだけがプロセスを管理できるようにするには、{{ic|-a 0x''#''}} フラグを使います。''#'' はコアの番号に置き換えて下さい。例えば、1番目のコアを使うには:

bit.trip.runner -a 0x1

CPU にはハイパースレッディングによって 2 または 4 のコアしか存在しないのに 4 あるいは 8 もコアがあるように認識されることがあります。その場合、仮想コア 0101 (1 と 3) を使うには:

bit.trip.runner -a 0x5

==== 一般的なケース ====

高いフレームレートと低遅延を必要とするほとんどのゲームでは、上記のフラグを全て使うのが一番良い結果になります。ただし、アフィニティはプログラムごとに確認してください。ほとんどのネイティブゲームは正しい使い方を理解しています。一般的なケースのフラグ例:

bit.trip.runner -I -n -4
Amnesia.bin64 -I -n -4
hl2.exe -I -n -4 -a 0x1 #GLSL が有効化された状態の Wine

==== Optimus やその他の便利なプログラム ====

一般的に、ゲームが動作するのに必要なプロセスはゲーム自体のプロセスよりも上のレベルに renice されるべきです。奇妙なことに、Wine には ''reverse scheduling'' という既知の問題が存在し、重要なプロセスに nice レベルが高く設定されることがあります。そこで、スケジューリングポリシーを設定すると動作が改善します。Wineserver も CPU 全体を消費することはあまりなく、必要なときは優先度を高くする必要があるので、無条件で {{ic|SCHED_FIFO}} を設定したほうが良いでしょう。

optirun -I -n -5
wineserver -F -p 20 -n 19
steam.exe -I -n -5

== 周辺機器 ==

=== マウス ===

[[マウスのアクセラレーション]]を設定して、マウスをより正確にコントロールできるようにすると良いかもしれません。

マウスに4つ以上のボタンが付いている場合、[[マウスボタン]] を参照すると良いかもしれません。

ゲーミングマウス (特に Logitech と Steelseries) を使用している場合、{{Pkg|piper}} を使ってマウスの[[マウスのポーリングレート]]、DPI、LED などを設定すると良いかもしれません。piper によってサポートされているデバイスの完全なリストは[https://github.com/libratbag/libratbag/tree/master/data/devices このページ]を見てください。logitech デバイスだけの場合は {{Pkg|solaar}} も使えます。

=== LED ===

{{Pkg|openrgb}} を使ってマザーボードや RAM の点灯を変更できます。現在サポートされているデバイスのリストは、[https://openrgb.org/devices_0.9.html] を見てください。

== 参照 ==

* [https://www.reddit.com/r/linux_gaming/ linux_gaming] - reddit.com 上の Linux ゲーミングに関するフォーラム。サブページ: [https://www.reddit.com/r/linux_gaming/wiki/index Wiki]、[https://www.reddit.com/r/linux_gaming/wiki/faq FAQ]。
* [https://github.com/AdelKS/LinuxGamingGuide Linux Gaming Guide] - Linux ゲーミングのエクスペリエンスの最適化に関するテクニック集。
* [https://areweanticheatyet.com/ are we anti cheat yet] - アンチチートを使用するゲームとそのゲームの Gnu/Linux 及び Wine/Proton における互換性の、コミュニティによる包括的なリスト。
* [https://www.protondb.com/ proton db] - コミュニティによる Linux 互換性レポート集

{{TranslationStatus|Gaming|2024-03-11|802585}}

Arch ブートプロセス

2025-04-05T09:22:41Z

Oech3: Add warning/* initramfs無しで起動 */

[[Category:ブートプロセス]]
[[Category:Arch について]]
[[bs:Arch boot process]]
[[en:Arch boot process]]
[[es:Arch boot process]]
[[fr:Arch boot process]]
[[pt:Arch boot process]]
[[ru:Arch boot process]]
[[zh-hans:Arch boot process]]
{{Related articles start}}
{{Related|Master Boot Record}}
{{Related|GUID Partition Table}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|mkinitcpio}}
{{Related|init}}
{{Related|systemd}}
{{Related|fstab}}
{{Related|自動起動}}
{{Related articles end}}

Arch Linux を起動するためには、Linux 対応の[[#ブートローダー|ブートローダー]]をセットアップする必要があります。ブートローダは、ブートプロセスが始まる前にカーネルや[[#initramfs|初期 RAM ディスク]]をロードする仕事を行います。[[Wikipedia:ja:BIOS|BIOS]] と [[Unified Extensible Firmware Interface|UEFI]] で起動の流れはかなり異なっています。このページや関連するページに詳しい説明があります。

== ファームウェアの種類 ==

ファームウェアは、システムの電源を入れた時に一番最初に実行されるプログラムのことです。

{{Tip|BIOS や (U)EFI という語は、ファームウェアという語の代わりにしばしば用いられます。}}

=== BIOS ===

[[Wikipedia:ja:BIOS|BIOS]] (Basic Input-Outout System) は、ほとんどの場合マザーボード内のフラッシュメモリに保存され、システムストレージとは独立しています。元々は [[Wikipedia:IBM PC|IBM PC]] がハードウェアの初期化やブートプロセスを処理するために作成されました。2010 年より、BIOS にあるような技術的な制約が存在しない [[#UEFI|UEFI]] に徐々に置き換えられています。

=== UEFI ===

[[Unified Extensible Firmware Interface]] は、パーティションテーブルとファイルシステムの両方の読み取りをサポートしています。UEFI は [[パーティショニング#Master Boot Record (bootstrap code)|Master Boot Record (MBR) 内のブートコード]]を起動しません (たとえ、それが有ろうと無かろうと)。代わりに、起動は [[Wikipedia:Non-volatile random-access memory|NVRAM]] 内のブートエントリに頼っています。

UEFI 仕様では [[FAT|FAT12、FAT16、および FAT32]] ファイルシステム ([https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#file-system-format-1 UEFI 仕様バージョン2.8、セクション13.3.1.1] を参照) のサポートが義務付けられていますが、規格に準拠しているベンダーは任意でファイルシステムのサポートを追加できます。たとえば、Apple の一部のファームウェアでは [[Wikipedia:HFS+|HFS+]] か [[Wikipedia:APFS|APFS]] のサポートがあります。UEFI の実装では、光ディスク用の [[Wikipedia:ja:ISO 9660|ISO 9660]] もサポートされています。

UEFIは、[[#ブートローダー|ブートローダー]] 、ブートマネージャ、 [[Unified_Extensible_Firmware_Interface#UEFI シェル |UEFI シェル]] などの EFI アプリケーションを起動します。これらのアプリケーションは通常、 [[EFI システムパーティション]] にファイルとして保存されます。各ベンダーは、EFI システムパーティションの {{ic|/EFI/''vendor_name''}} フォルダにファイルを格納できます。アプリケーションを起動するには、NVRAM に、または UEFI シェルからブートエントリを追加します。

UEFI 仕様では、[[Wikipedia:ja:Unified_Extensible_Firmware_Interface|互換性サポートモジュール (CSM)]] によるレガシー [[#BIOS|BIOS]] ブートがサポートされています。UEFI で CSM が有効な場合、UEFI はすべてのドライブの CSM ブートエントリを生成します。CSM ブートエントリがブート元として選択された場合、UEFI の CSM はドライブの MBR ブートストラップコードからのブートを試みます。

{{Note|Intel は CSM のサポートを徐々に終了しつつあります。将来的に、この機能に頼ることは不可能になるかもしれません。[https://www.intel.com/content/dam/support/us/en/documents/intel-nuc/Legacy-BIOS-Boot-Support-Removal-for-Intel-Platforms.pdf]}}

== システムの初期化 ==

=== BIOS ===

# システムの電源が入れられ [[Wikipedia:ja:Power On Self Test|POST]] が実行される。
# BIOS が、ブートに必要なシステムハードウェア (ディスクやキーボードコントローラなど) を初期化する。
# BIOS のディスク順で最初のディスクの最初の440バイト ([[Master Boot Record|Master Boot Record]]) が BIOS によって実行される。
# MBR ブートコード内の、ブートローダの最初のステージが、2番めのステージコードを以下のどれかから実行する:
#* MBR の次のディスクセクタ。つまり、post-MBR gap と呼ばれる部分(MBR パーティションテーブルにしか存在しません)。
#* パーティション、あるいはパーティションレスディスクの [[Wikipedia:Volume boot record|ボリュームブートレコード (VBR)]]。
#* GPT でパーティショニングされたディスク上の [[GRUB]] の場合、GRUB 固有の [[BIOS ブートパーティション]] (GPT には存在しない MBR の後ろの隙間の代わりとして使用されます)。
# [[#ブートローダー|ブートローダー]]本体が起動される。
# ブートローダーがオペレーティングシステムのカーネルをチェインロード、または直接ロードして、オペレーティングシステムをロードする。

=== UEFI ===

# システムのスイッチが入り、[[Wikipedia:ja:Power On Self Test|power-on self-test (POST)]] が実行される。
# POST 後に、UEFI は起動に必要なハードウェア(ディスク、キーボード、コントローラなど)を初期化する。
# ファームウェアは NVRAM 内のブートエントリを読み込み、どの EFI アプリケーションを起動するかや、どこから(例えば、どのディスクやパーティションから)起動するかを判断する。
#* ブートエントリは単にディスクであることもあります。この場合、ファームウェアは [[EFI システムパーティション]]をそのディスク上から探し、フォールバックブートパス {{ic|\EFI\BOOT\BOOTx64.EFI}}([[Unified Extensible Firmware Interface#UEFI ファームウェアのビット数|IA32 (32-bit) UEFI のシステム]]では {{ic|BOOTIA32.EFI}})から EFI アプリケーションを見つけようとします。これは UEFI の起動可能リムーバブルメディアの動作です。
# ファームウェアが EFI アプリケーションを起動する。
#* そのアプリケーションは[[#ブートローダ|ブートローダ]]や、[[EFI ブートスタブ]]を使用する Arch [[カーネル]]自体であることもあります。
#* そのアプリケーションは他の EFI アプリケーション([[UEFI シェル]] や、[[systemd-boot]] や [[rEFInd]] などの [[#ブートローダ|ブートマネージャ]])であることもあります。

[[セキュアブート]] が有効化されている場合、ブートプロセスでは EFI バイナリの正統性を署名によって検証します。

{{Note|一部の UEFI システムはフォールバックブートパスからしか起動できません。}}

==== UEFI でのマルチブート ====

それぞれの OS やベンダーは互いに影響を与えずに [[EFI システムパーティション]] 内に固有のファイルを保持することができるので、UEFI を用いたマルチブートは単に、特定のオペレーティングシステムのブートローダに対応する異なる EFI アプリケーションを起動する問題になります。ゆえに、他の OS をロードするためにブートローダの[[Wikipedia:Chain loading|チェインロード]]メカニズムに頼る必要がありません。

[[Windows と Arch のデュアルブート]] も参照してください。

== ブートローダー ==

ブートローダーは、ファームウェア([[Wikipedia:BIOS|BIOS]] または [[UEFI]])によって起動されるソフトウェアの一部です。ブートローダーは、必要な[[カーネルパラメータ]]と任意の外部の初期 RAM ディスクイメージと共にカーネルをロードします。UEFI の場合、[[EFI ブートスタブ]]を使用して、UEFI からカーネル自体を直接起動できます。ブート前にカーネルパラメータを編集するために、別のブートローダやブートマネージャを使うこともできます。

{{Warning|Arch を正しくブートするには、ブートローダーが、たいてい {{ic|/boot}} ディレクトリ内にあるカーネル及び initramfs イメージへアクセスする必要があります。つまり、ブートローダーは、ブロックデバイスからスタックされたブロックデバイス (LVM、RAID、dm-crypt、LUKSなど) まで、カーネルや initramfs イメージが存在するファイルシステムまで、すべてをサポートしなければなりません。

しかし、そのようなスタックされたブロックデバイスをサポートするブートローダーは稀ですし、ブートローダーによってまだサポートされていない機能がファイルシステムに追加されることもある (例: [https://gitlab.archlinux.org/archlinux/packaging/packages/grub/-/issues/7 archlinux/packaging/packages/grub#7]、{{Bug|79857}}、{{Bug|59047}}、{{Bug|58137}}、{{Bug|51879}}、{{Bug|46856}}、{{Bug|38750}}、{{Bug|21733}}、[[fscrypt]] によって暗号化されたディレクトリ) ので、広くサポートされているファイルシステム ([[FAT32]] など) でフォーマットされた個別の [[パーティショニング#/boot|/boot パーティション]]を使うほうがほとんどの場合、現実的です。
}}

=== 機能比較 ===

{{Note|
* GPT は UEFI 仕様の一部であるため、すべての UEFI ブートローダーは GPT ディスクをサポートします。BIOS システム上の GPT は、[https://www.rodsbooks.com/gdisk/hybrid.html Hybrid MBR] で "hybrid booting" を使うか、新しい [https://repo.or.cz/syslinux.git/blob/HEAD:/doc/gpt.txt GPT-only] プロトコルを使うことで可能です。ただしこのプロトコルは特定の BIOS 実装で問題を引き起こす可能性があります。詳細については、[https://www.rodsbooks.com/gdisk/bios.html#bios rodsbooks] を参照してください。
* [[セキュアブート]]は UEFI 規格の一部なので、全ての UEFI ブートローダーはそれをサポートしています。ただし、いくつかの制限があります。
}}

{| class="wikitable sortable"
! rowspan="2" | 名前
! colspan="2" | ファームウェア
! colspan="2" | [[パーティショニング#パーティションテーブル|パーティションテーブル]]
! rowspan="2" | マルチブート
! rowspan="2" | [[ファイルシステム]]
! rowspan="2" | 備考
|-
! BIOS !! [[UEFI]]
! [[MBR]] !! [[GPT]]
|-
! [[EFI ブートスタブ]]
| {{-}}
| {{Yes}}1
| {{Yes}} || {{Yes}}
| {{-}}
| {{G|ファームウェアから継承2}}
| カーネルイメージは、UEFI または他の UEFI ブートローダーから直接起動することのできる有効な EFI 実行ファイルです。
|-
! [[Unified カーネルイメージ]]
| {{-}}
| {{Yes}}3
| {{Yes}} || {{Yes}}
| {{-}}
| {{G|ファームウェアから継承2}}
| {{man|7|systemd-stub}} やカーネル、initramfs、カーネルコマンドラインを EFI 実行ファイルにパックしたものです。UEFI ファームウェアや他のブートローダから直接読み込めます。
|-
! [[GRUB]]
| {{Yes}}
| {{Yes}}3
| {{Yes}} || {{Yes}}
| {{Yes}}
| {{G|[[GRUB#サポートされているファイルシステム|内蔵]]}}
| RAID、LUKS (ただし Argon2 PBKDF 以外)、LVM をサポートします (シンプロビジョニングボリュームはサポートしません)。環境固有の制限については [[GRUB]] を見てください。
|-
! [[Limine]]
| {{Yes}}
| {{Yes}}
| {{Yes}} || {{Yes}}
| {{Yes}}
| {{Y|[[Limine#サポートされているファイルシステム|制限有り]]}}
|
|-
! [[rEFInd]]
| {{No}}
| {{Yes}}
| {{Yes}} || {{Yes}}
| {{Yes}}4
| {{G|[[rEFInd#サポートされているファイルシステム|拡張可能]]2,5}}
| 明示的な構成なしでカーネルとパラメーターの自動検出をサポートします。そして、fastboot をサポートします[https://bbs.archlinux.org/viewtopic.php?id=258805]。
|-
! [[Syslinux]]
| {{Yes}}
| {{Y|[[Syslinux#UEFI Syslinux の制限|部分的]]1}}
| {{Yes}} || {{Yes}}
| {{Y|[[Syslinux#チェインロード|部分的]]}}
| {{Y|[[Syslinux#サポートされているファイルシステム|制限有り]]}}
| ファイルシステムの特定の機能はサポートされていません。 Syslinux が[[Syslinux#チェインロード|インストールされている]]ファイルシステムにしかアクセスできません。
|-
! [[systemd-boot]]
| {{No}}
| {{Yes}}3
| {{Y|[https://github.com/systemd/systemd/issues/1125 手動]}} || {{Yes}}
| {{Yes}}4
| {{G|[[systemd-boot#サポートされているファイルシステム|拡張可能]]2,5}}
| systemd-boot がインストールされている [[ESP]]、または、同じディスク上の Extended Boot Loader Partition (XBOOTLDR パーティション) 内のバイナリしか起動できません。 {{ic|''esp''/EFI/Linux/}} 内の [[unified カーネルイメージ]] を自動的に検出します。
|-
! {{Grey|[[GRUB Legacy]]}}
| {{Yes}}
| {{No}}
| {{Yes}} || {{No}}
| {{Yes}}
| {{Y|[[GRUB Legacy#サポートされているファイルシステム|制限有り]]}}
| [https://www.gnu.org/software/grub/grub-legacy.html 開発停止]。[[GRUB]] に移行。
|-
! {{Grey|[[LILO]]}}
| {{Yes}}
| {{No}}
| {{Yes}} || {{Y|[https://salsa.debian.org/joowie-guest/upstream_lilo/-/commit/29a64e6b92cac22d472f4b352de5b1535e4afc5f 部分的]}}
| {{Yes}}
| {{Y|[[LILO#サポートされているファイルシステム|制限有り]]}}
| (Btrfs、GPT、RAID、暗号化などの) 制限により[https://web.archive.org/web/20180323163248/http://lilo.alioth.debian.org/ 開発停止]。
|}

# バイナリは[[セキュアブート]]のために署名することはできますが、検証はされません。なので、信用の鎖はここで切れてしまいます。
# ファイルシステムのサポートはファームウェアから継承されます。UEFI 仕様では、FAT12、FAT16、および FAT32 ファイルシステムのサポートが義務付けられていますが [https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#file-system-format-1]、ベンダーはオプションで追加のファイルシステムのサポートを追加できます。たとえば、Apple [[Mac]] のファームウェアは HFS+ ファイルシステムをサポートしています。ファームウェアが起動時に [[Unified Extensible Firmware Interface#UEFI ドライバ|UEFIドライバー]] をロードするためのインターフェースを提供する場合、ファイルシステムドライバーを(個別に取得して)ロードすることにより、追加のファイルシステムのサポートを追加できます。
# Mixed mode ブートをサポートしています。つまり、[[Unified Extensible Firmware Interface#UEFI ファームウェアのビット数|32 ビット IA32 UEFI]] 上で 64 ビット x86_64 Linux カーネルをブートできます。
# [https://www.rodsbooks.com/efi-bootloaders/principles.html ブートマネージャー]。他の EFI アプリケーション、たとえば {{ic | 1 = CONFIG_EFI_STUB = y}} フラグありでビルドされた Linux カーネルイメージおよび [https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/boot-and-uefi#understanding-the-windows-boot-manager Windows Boot Manager] ({{ic|bootmgfw.efi}}) のみを起動できます。
# [[Unified Extensible Firmware Interface#UEFI ドライバ|UEFI ファイルシステムドライバ]]の読み込みをサポートしています。

[[Wikipedia:Comparison of boot loaders]] も参照してください。

== カーネル ==

[[#ブートローダー|ブートローダー]] は、[[カーネル]]を含んでいる [[Wikipedia:ja:vmlinux|vmlinux イメージ]]を起動します。

カーネルは、マシンのハードウェアとプログラムとの間を仲介する低いレベル(''カーネル空間'')で機能します。カーネルは、ユーザスペースに移行する前にまずハードウェアの列挙と初期化を行います。より詳細な説明は [[Wikipedia:ja:カーネル]] と [[Wikipedia:ja:Linuxカーネル]] を見てください。

== initramfs ==

{{ic|/}} のルートファイルシステムは空の [https://www.kernel.org/doc/html/latest/filesystems/ramfs-rootfs-initramfs.html rootfs] として始まります。これは ramfs や tmpfs の特殊なインスタンスです。これは一時的なルートファイルシステムで、initramfs (''init''ial ''RAM'' ''f''ile ''s''ystem) イメージがここへ解凍されます。

Initramfs の主な目的は root ファイルシステムにアクセスできる位置にシステムをブートストラップすることです (詳しくは [[FHS]] を見て下さい)。これには、[[dm-crypt]]、[[dm-verity]]、{{man|8|systemd-repart}} などを通してルートファイルシステムが存在しているであろうストレージスタックのセットアップなどが含まれます。また、[[udev]] を介して[[永続的なブロックデバイスの命名]]を実際のデバイスに解決することも行われます。これは NVMe、SATA、SAS、eMMC、USB (外部ハードウェアから起動する場合) などのデバイスのために必要なモジュールがカーネルに入っていない場合 initramfs からモジュールをロードできなくてはならないということを意味しています; (プログラムやスクリプトから明示的に指定されるか [[udev]] を通すかして) 正しいモジュールがロードされると、ブートプロセスが再開されます。従って、initramfs に含めなくてはならないのは root ファイルシステムにアクセスするために必要なモジュールだけで、使用する全てのモジュールを入れる必要はありません。ほとんどのモジュールは後の init プロセス中に、ルート ({{ic|/}}) を実際のルートファイルシステムに切り替えた後で [[udev]] によってロードされます。

まず、カーネルは組み込みの initramfs を一時的なルートファイルシステムに解凍します。Arch Linux の[[カーネル#公式サポートカーネル|公式カーネル]]では組み込みの initramfs として空のアーカイブが用いられます(Linux のビルドの際のデフォルトです)。そして、カーネルは、[[#ブートローダー|ブートローダー]]から渡されたコマンドラインにより指定された外部の initramfs ファイルを解凍します。この際、組み込みの initramfs にあったファイルは上書きされます。このような外部の initramfs イメージは [[mkinitcpio]] や [[dracut]]、[[booster]] によって生成でき、Arch の''初期ユーザ空間''のセットアップの方法として推奨されています。

Initramfs には、ルートファイルシステムをセットアップする以外の役割もあります。ルートファイルシステムがマウントされる前にしか行うことができないタスク ([[fsck]] や[[ハイバネート]]からの復帰など) が存在するのです。

また、Linux [[カーネル]]は、カーネルが開始された最初のルートファイルシステムを[https://github.com/torvalds/linux/blob/1b907d0507354b74a4f2c286380cd6059af79248/fs/namespace.c#L4222 留めておきます]。Initramfs が使用されなかった場合、シャットダウン時に実際のルートファイルシステムが正しくアンマウントされない可能性があります。

=== initramfs無しで起動 ===

{{Warning|The pacman hook to copy kernel image to [[EFI system partition]] is provided by each initramfs generator packages instead of kernel packages. Keep one of them even if this setup is possible.}}

6.13.8から公式にサポートされたカーネルの[[Btrfs]]と[[Ext4]]のドライバはbuilt-inです。 [https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/commit/a7e2a17f9c0e55937ea3e18c4d5b905a8e4f8047].

これは、カーネルがそれらのファイルシステムのrootパーティションを、他のモジュールなしに直接使用できる事を意味しています。
それでも、いくつか癖があります:

* [[Systemd#GPT パーティションの自動マウント]]は使えず、{{ic|root}} [[カーネルパラメータ]]が必要です。
* {{ic|root}}の続的なブロックデバイスの命名は{{ic|PARTUUID}}と{{ic|PARTLABEL}}だけ使えます [https://github.com/torvalds/linux/blob/v6.14/block/early-lookup.c#L216-L243].
* マウントオプションの{{ic|rootflags}}には制限があります,例えば{{ic|noatime}}は動きません。 [https://bugzilla.kernel.org/show_bug.cgi?id=61601]. 後で[[fstab]]等で再マントしてください。
* {{man|8|systemd-gpt-auto-generator}}はBtrfsを使っているとinitramfs無しでは使えません。 [https://github.com/systemd/systemd/issues/16953] {{ic|1=systemd.gpt_auto=no}}で無効化してください。

現時点でSCSI/SATA/AHCIドライバがbuilt-inです。他のストレージデバイス(NVMe,USB,Device mapper等)は動きません。LVMや暗号化も使えません。

[[マイクロコード#早期ロード]]もinitramfsが必要ですが、イメージ全体をビルドする必要はなく、[[マイクロコード#別個のマイクロコード initramfs ファイルを使う]]を使えます.

If no initramfs image is provided, the kernel always contains still an empty image to start from [https://docs.kernel.org/filesystems/ramfs-rootfs-initramfs.html#populating-initramfs]. So there should be no issues with root partition [https://github.com/torvalds/linux/blob/1b907d0507354b74a4f2c286380cd6059af79248/fs/namespace.c#L4222 pinning].

== 初期ユーザ空間 ==

''初期ユーザ空間''の段階は一時的なルートファイルシステムがマウントされている状態で行われ、[[#initramfs|initramfs]] により提供されたファイルで動作します。

初期ユーザ空間の機能は[[Mkinitcpio#HOOKS|設定可能]]ですが、一般的に以下のようなことを行います:

* {{man|8|systemd-modules-load}} がカーネルモジュールを読み込みます。例えば、本物のルートファイルシステムをマウントするために必要なブロックデバイスモジュールなどです。
* 必要ならば、本物のルートファイルシステムの復号処理を行います。
* DRM モジュールをロードします。[[カーネルモード設定#KMS の早期開始|KMS の早期開始]]は、ツリー内のモジュールに対してはデフォルトで有効化されています。

初期ユーザー空間の最終段階として、本物のルートファイルシステムが {{ic|/sysroot/}} ([[systemd]] ベースの initramfs の場合) または {{ic|/new_root/}} (busybox ベースの場合) にマウントされ、それに切り替わります。本物のルートファイルシステムから [[init]] プログラムを実行することにより、後期ユーザ空間が始まります。

== 後期ユーザ空間 ==

[[init]] プロセスにより後期ユーザ空間のスタートアップが実行されます。Arch では公式には、ユニットとサービスの概念の上に構築された [[systemd]] が用いられます。しかし、ここで言及している機能は他の init システムと重なります。

=== getty ===

init プロセスは [[Wikipedia:Virtual console|仮想コンソール]](典型的には6つ)ごとに [[getty]] を1回呼び出します。''getty'' はそれぞれのターミナルを初期化して、認証されていないユーザからターミナルを保護します。ユーザ名とパスワードが与えられると、''getty'' はそれらを {{ic|/etc/passwd}} と {{ic|/etc/shadow}} と照合し、{{man|1|login}} を呼び出します。

==== ログイン ====

''ログイン'' プログラムは、環境変数を設定し、{{ic|/etc/passwd}} に基づいてユーザーのシェルを起動することによって、ユーザーのセッションを開始します。''ログイン'' プログラムは、ログインに成功するとログインシェルを実行する直前に [[Wikipedia:motd (Unix) |/etc/motd]] (''m''essage ''o''f ''t''he ''d''ay) の内容を表示します。利用規約を表示してユーザーに地域のポリシーや伝えたいことを思い出させるのに適した場所です。

==== シェル ====

ユーザーの[[シェル]]が起動されると、通常はユーザーにプロンプトを表示する前に [[bashrc]] などの実行時設定ファイルが実行されます。アカウントが[[ログイン時に X を起動]]するように設定されている場合、実行時設定ファイルは [[startx]] または [[xinit]] を呼び出します。最後については [[#グラフィカルセッション (Xorg)]] を見てください。

=== ディスプレイマネージャ ===

さらに、[[init]] は、指定した仮想コンソールで ''getty'' の代わりに[[ディスプレイマネージャ]]を起動するように設定できます。そうするには、該当する [[systemd#ユニットを使う|systemd service ファイル]]を手動で[[有効化]]する必要があります。そうしたら、ディスプレイマネージャーがグラフィカルセッションを起動します。

==== グラフィカルセッション (Xorg) ====

[[xinit]] はユーザの [[xinitrc]] ランタイム設定ファイルを実行し、通常、[[ウィンドウマネージャ]]や[[デスクトップ環境]]を開始します。ユーザが終了すると、''xinit''、 ''startx''、シェル、ログインの順序で終了して [[#getty|getty]]、またはディスプレイマネージャに戻ります。

== 参照 ==

* [[Wikipedia:Booting process of Linux]]
* [https://web.archive.org/web/20230313210814/https://developer.ibm.com/articles/l-linuxboot/ Inside the Linux boot process]
* [https://www.rodsbooks.com/efi-bootloaders/ Rod Smith - Managing EFI Boot Loaders for Linux]
* [https://neosmart.net/wiki/mbr-boot-process/ NeoSmart: The BIOS/MBR Boot Process]
* [https://0pointer.net/blog/linux-boot-partitions.html Lennart Poettering - Linux Boot Partitions and How to Set Them Up]
* [[Wikipedia:initrd]]
* [https://web.archive.org/web/20150430223035/http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ Early Userspace in Arch Linux]
* [https://www.linux.com/learn/kernel-newbie-corner-initrd-and-initramfs-whats Kernel Newbie Corner: initrd and initramfs]
* {{man|7|bootup}} (Systemd initrd とユーザー空間に関する部分についてがほとんど)

{{TranslationStatus|Arch boot process|2024-12-27|824035}}

アクセス制御リスト

2025-04-05T05:00:54Z

Oech3: 誤訳?を修正/* ACL の有効化 */

[[Category:アクセス制御]]
[[en:Access Control Lists]]
[[es:Access Control Lists]]
[[pt:Access Control Lists]]
[[ru:Access Control Lists]]
[[zh-hans:Access Control Lists]]
[[Wikipedia:ja:アクセス制御リスト|アクセス制御リスト]] (Access control list; ACL) は[[ファイルシステム]]により柔軟性のあるパーミッション機構を追加します。ACL は UNIX のファイルパーティションを補助するように設計されています。ACL を使うことで、任意のユーザやグループに任意のディスクリソースへのパーミッションを与えることができます。

== インストール ==

{{Pkg|acl}} パッケージは [[systemd]] の依存パッケージであるため、すでにインストールされているはずです。

== ACL の有効化 ==

ACL を有効化するには、ファイルシステムを {{ic|acl}} オプションでマウントする必要があります。[[fstab]] を使えばオプションを永続化させることができます。

ファイルシステムのデフォルトマウントオプションによっては {{ic|acl}} オプションが既に有効になっているかもしれません。[[Btrfs]] と Ext2/[[Ext3|3]]/[[Ext4|4]] は影響を受けます。以下のコマンドを使うことで、ext2/3/4 でフォーマットされたパーティションのオプションを確認できます:

{{hc|# tune2fs -l /dev/sd''XY'' {{!}} grep "Default mount options:"|
Default mount options: user_xattr '''acl'''
}}

また、デフォルトのマウントオプションがオーバーライドされていないことも確認してください。{{ic|/proc/mounts}} の関連する行に {{ic|noacl}} とある場合、ACL が無効化されています。

ファイルシステムのデフォルトマウントオプションは、コマンド {{ic|tune2fs -o ''オプション'' ''パーティション''}} で設定できます。例えば:

# tune2fs -o acl /dev/sd''XY''

外部ドライブの場合、{{ic|/etc/fstab}} のエントリではなくデフォルトのマウントオプションを使うと非常に便利です。なぜなら、そのようなパーティションは他の Linux マヒンでも {{ic|acl}} オプションでマウントされるからです。すべてのマシンで {{ic|/etc/fstab}} を編集する必要は無くなります。

{{Note|
* ext2/3/4 ファイルシステムの作成時に {{ic|acl}} はデフォルトのマウントオプションとして指定されます。この設定は {{ic|/etc/mke2fs.conf}} から変えられます。
* デフォルトのマウントオプションは {{ic|/proc/mounts}} には記載されません。
}}

== 使用法 ==

=== ACL の設定 ===

''setfacl'' コマンドで ACL を変更できます。

{{Tip|
* {{ic|--test}} フラグを追加すれば、パーミッションを変更せずに (つまり、ドライラン) ファイル/ディレクトリのパーミッションの変更を一覧表示できます。
* すべてのファイルやディレクトリに再帰的に操作を適用するには、{{ic|-R}}/{{ic|--recursive}} を引数に追加してください。
}}

ユーザに対するパーミッションを設定する ({{ic|''user''}} はユーザ名あるいはユーザ ID):

# setfacl -m "u:''user:permissions''" <file/dir>

グループに対するパーミッションを設定する ({{ic|''group''}} はグループ名あるいはグループ ID):

# setfacl -m "g:''group:permissions''" <file/dir>

その他に対するパーミッションを設定する:

# setfacl -m "other:''permissions''" <file/dir>

すべての''新しく作成される''ファイルやディレクトリが親ディレクトリのエントリを継承するようにする (これは、そのディレクトリに''コピーされる''ファイルには影響しません):

# setfacl -dm "''entry''" <dir>

特定のエントリを削除する:

# setfacl -x "''entry''" <file/dir>

デフォルトのエントリを削除する:

# setfacl -k <file/dir>

すべてのエントリを削除する (所有者、グループ、そしてその他のユーザのエントリは保持されます):

# setfacl -b <file/dir>

{{Accuracy|{{ic|--mask}} オプションに関する以前のノート ({{man|1|setfacl}} から引用されたもの) は不正確であると判断されました。しかし、以下の新しいノートも正しくないようです。詳細は、この問題に関する [[:en:Talk:Access Control Lists#ACL mask entry|英語版の議論ページ]] を参照してください。}}

{{Note|''setfacl'' のデフォルトの挙動では、{{ic|--mask}} エントリが明示的に与えられない限り、ACL マスクエントリが再計算されます。マスクエントリは、ユーザ (所有者以外) とグループに対して許可される最大のパーミッションを示します。明示的に設定されていない限り、これはデフォルトグループのパーミッションと一致します。これが何を意味するかを明確にするために、あるディレクトリを所有するグループが {{ic|r-x}} パーミッションを持つと仮定しましょう。{{ic|rwx}} パーミッションを持つ ACL ユーザやグループを追加すると、このユーザあるいはグループの''実効'' (''effective'') パーミッションは {{ic|r-x}} となります。その理由は、ACL をサポートしないシステムから来たファイルが、ACL をサポートするシステム上で利用可能になったとしても、問題が生じないようにするためです。}}

=== ACL の表示 ===

パーミッションを表示するには、以下を実行してください:

# getfacl <file/dir>

== サンプル ==

{{ic|abc}} という名前のファイルに対するユーザ {{ic|johnny}} のパーミッションを設定:

# setfacl -m "u:johnny:rwx" abc

パーミッションを確認:

{{hc|# getfacl abc|
# file: abc
# owner: someone
# group: someone
user::rw-
user:johnny:rwx
group::r--
mask::rwx
other::r--
}}

ユーザ {{ic|johnny}} のパーミッションを変更:

# setfacl -m "u:johnny:r-x" abc

パーミッションを確認:

{{hc|# getfacl abc|
# file: abc
# owner: someone
# group: someone
user::rw-
user:johnny:r-x
group::r--
mask::r-x
other::r--
}}

すべての ACL エントリを削除:

# setfacl -b abc

パーミッションを確認:

{{hc|# getfacl abc|
# file: abc
# owner: someone
# group: someone
user::rw-
group::r--
other::r--
}}

=== ls コマンドの出力 ===

特定のファイルに ACL が存在するかどうかは {{ic|ls -l}} の出力で Unix のパーミッションの後に {{ic|'''+'''}} (プラス記号) があるかどうかで見分けられます。

{{hc|$ ls -l /dev/audio|
crw-rw----+ 1 root audio 14, 4 nov. 9 12:49 /dev/audio
}}

{{hc|$ getfacl /dev/audio|
getfacl: Removing leading '/' from absolute path names
# file: dev/audio
# owner: root
# group: audio
user::rw-
user:solstice:rw-
group::rw-
mask::rw-
other::---
}}

=== プライベートなファイルに実行権限を付与する ===

[[ウェブサーバー]]などのプロセスに、ユーザのホームディレクトリにあるファイルへのアクセス権を与える方法を以下で説明します (システム全体に対してアクセス権を与えてセキュリティを犠牲にしたりはしません)。

このセクションでは、ウェブサーバは {{ic|http}} ユーザとして実行していて、{{ic|geoffrey}} のホームディレクトリ {{ic|/home/geoffrey}} へのアクセスを与えたいと仮定します。

まず、{{ic|http}} ユーザに実行権限を与えます:

# setfacl -m "u:http:--x" /home/geoffrey

{{Note|ディレクトリに対する実行権限は、プロセスがディレクトリのコンテンツを確認できるようにするために必要です。}}

これで {{ic|http}} ユーザが {{ic|/home/geoffrey}} 内のファイルにアクセスできるようになったので、{{ic|other}} にアクセス権は必要ありません:

# chmod o-rx /home/geoffrey

{{ic|getfacl}} を使って変更を確認してください:

{{hc|$ getfacl /home/geoffrey|
getfacl: Removing leading '/' from absolute path names
# file: home/geoffrey
# owner: geoffrey
# group: geoffrey
user::rwx
user:http:--x
group::r-x
mask::r-x
other::---
}}

上記の出力で、{{ic|other}} は如何なるパーミッションも持っていませんが、{{ic|http}} ユーザは依然として (ホームディレクトリ下の) ファイルにアクセスできることが分かります。ゆえに、セキュリティが向上したはずです。

特定のディレクトリやファイルへの書き込みアクセス権を {{ic|http}} ユーザに与えたい場合は、以下を実行してください:

# setfacl -dm "u:http:rwx" /home/geoffrey/project1/cache

== 参照 ==

* {{man|1|getfacl}}
* {{man|1|setfacl}}
* [https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html POSIX Access Control Lists on Linux]
* [https://unix.stackexchange.com/questions/1314/how-to-set-default-file-permissions-for-all-folders-files-in-a-directory How to set default file permissions for all folders/files in a directory?]

{{TranslationStatus|Access Control Lists|2023-05-10|704836}}

カーネルモジュール

2025-04-04T18:51:36Z

Oech3: インストールしない/* ブラックリスト */

[[Category:カーネル]]
[[Category:ハードウェア検出とトラブルシューティング]]
[[Category:ブートプロセス]]
[[bs:Kernel module]]
[[de:Kernelmodule]]
[[en:Kernel module]]
[[es:Kernel module]]
[[fr:Kernel modules]]
[[it:Kernel module]]
[[pt:Kernel module]]
[[ru:Kernel module]]
[[zh-hans:Kernel module]]
{{Related articles start}}
{{Related|ブートデバッグ}}
{{Related|カーネル}}
{{Related|カーネルパラメータ}}
{{Related|カーネルモジュールのコンパイル}}
{{Related articles end}}

[[Wikipedia:Loadable_kernel_module|カーネルモジュール]] は、要求に応じてカーネルにロードおよびアンロードできるコードの一部です。これにより、システムを再起動する必要なく、カーネルの機能を拡張することができます。

カーネルモジュールを作成するには、[https://sysprog21.github.io/lkmpg/ The Linux Kernel Module Programming Guide] を参照してください。モジュールは、ビルトインまたはロード可能として設定できます。モジュールを動的にロードまたは削除するには、カーネルの設定でそのモジュールをロード可能なモジュールとして設定する必要があります（そのモジュールに関連する行には {{ic|M}} という文字が表示されます）。

新しいカーネルがインストールされるときにカーネルモジュールを自動的に再構築するには、[[Dynamic Kernel Module Support]] (DKMS) を参照してください。

== 情報を取得 ==

モジュールは {{ic|/usr/lib/modules/''kernel_release''}} に保存されます。{{ic|uname -r}} コマンドを使うことで現在のカーネルのリリースバージョンを表示できます。

{{Note|モジュール名にはよくアンダーバー ({{ic|_}}) やダッシュ ({{ic|-}}) が使われますが、{{ic|modprobe}} コマンドと {{ic|/etc/modprobe.d/}} の設定ファイルではこの２つの記号は相互に置き換え可能です。}}

現在ロードされているカーネルモジュールを表示する:

$ lsmod

モジュールについての情報を表示する:

$ modinfo ''module_name''

ロードされたモジュールに設定されたオプションを一覧する:

$ systool -v -m ''module_name''

全てのモジュールの全ての設定を表示する:

$ modprobe -c | less

特定のモジュールの設定を表示する:

$ modprobe -c | grep ''module_name''

モジュール自身を含む、モジュール（やエイリアス）の依存関係を一覧する:

$ modprobe --show-depends ''module_name''

== モジュールの自動ロード ==

今日、必要なモジュールのロードはすべて [[udev]] によって自動的に処理されます。したがって、ツリー外のカーネルモジュールを使用する必要がない場合は、ブート時にロードする必要のあるモジュールを設定ファイルに記述する必要はありません。ただし、ブートプロセスで追加のモジュールをロードしたり、コンピューターを正しく機能させるために他のモジュールをブラックリストに入れるなどのケースが考えられます。

=== モジュールの早期ロード ===

[[initramfs]] イメージには、 {{ic|/etc/modules-load.d/}} で要求されたカーネルモジュールが含まれていない場合があります。また、そのフォルダに設定されているファイルが不足している場合もあります。モジュールの早期ロードは使用する initramfs ジェネレータに依存します。
*{{pkg|mkinitcpio}}: [[Mkinitcpio#MODULES]] を参照してください。
*{{pkg|dracut}}: [[Dracut#カーネルモジュールの早期ロード]] を参照してください。
*{{pkg|booster}}: [[Booster#モジュールの早期ロード]] を参照してください。

=== systemd ===

カーネルモジュールを {{ic|/etc/modules-load.d/}} 配下のファイルに明示的にリストアップして、systemd が起動時にロードできるようにすることができます。各設定ファイルの名前の形式は {{ic|/etc/modules-load.d/''program''.conf}} です。設定ファイルにはロードするカーネルモジュール名のリストが改行で区切られて含まれています。空行と最初の非空白文字が {{ic|#}} または {{ic|;}} である行は無視されます。

{{hc|/etc/modules-load.d/virtio-net.conf|
# 起動時に virtio_net.ko をロード
virtio_net}}

詳しくは {{man|5|modules-load.d}} を参照してください。

== 手動でモジュールを扱う ==

カーネルモジュールは {{Pkg|kmod}} パッケージによって提供されるツールを使って管理します。これらのツールは手動で使用できます。

{{Note|カーネルをアップグレードしたがまだ再起動していない場合、''modprobe'' はエラーメッセージなしで失敗し、コード 1 で終了します、これはパス {{ic|/usr/lib/modules/$(uname -r)/}} がもう存在しないためです。''modprobe'' が失敗したときにこのパスが存在するかどうか手動で確認してください。}}

モジュールをロードするには:

# modprobe ''module_name''

ファイル名でモジュールをロードするには（つまり、{{ic|/usr/lib/modules/$(uname -r)/}} にインストールされていないモジュール）:

# insmod filename [args]

モジュールをアンロードするには:

# modprobe -r ''module_name''

もしくは:

# rmmod ''module_name''

== モジュールオプションを設定する ==

カーネルモジュールにパラメータを渡すには、modprobe を使用してパラメータを手動で渡すか、modprobe 設定ファイルまたはカーネルコマンドラインを使用して特定のパラメータが常に適用されるようにすることができます。モジュールがカーネルに組み込まれている場合は、カーネルコマンドラインを使用する必要があり、他の方法は機能しません。

=== ロード時に modprobe を使って手動で行う ===

モジュールにパラメータを渡す基本的な方法は、''modprobe'' コマンドを使用することです。パラメータはコマンドラインで単純な {{ic|1=''key=value''}} の代入で指定します。

# modprobe ''module_name parameter_name=parameter_value''

=== /etc/modprobe.d/ 内のファイルを使用する ===

{{ic|/etc/modprobe.d/}} ディレクトリ内のファイルは、[[udev]] にモジュール設定を渡すために使用できます。これにより、システムの起動時に {{ic|modprobe}} を使用してモジュールのロードを管理します。このディレクトリ内の設定ファイルは、''.conf'' 拡張子で終わる任意の名前を持つことができます。構文は次のとおりです:

{{hc|/etc/modprobe.d/myfilename.conf|2=
options ''module_name parameter_name=parameter_value''
}}

複数のモジュールパラメータはスペースで区切られ、パラメータにはカンマで区切られた値のリストを指定できます:

{{hc|/etc/modprobe.d/myfilename.conf|2=
options ''module_name param1=value1 param2=value2a,value2b …''
}}

例:

{{hc|/etc/modprobe.d/thinkfan.conf|2=
# ThinkPad では、'thinkfan' デーモンがファンの速度を制御できるようにします
options thinkpad_acpi fan_control=1
}}

{{Note|影響を受けるモジュールが initramfs からロードされている場合、適切な ''.conf'' ファイルを [[mkinitcpio.conf]] の {{ic|FILES}} に追加するか、{{ic|modconf}} [[Mkinitcpio.conf#HOOKS|フック]] を使用してから、''.conf'' ファイルを含めるために [[initramfs の再生成]] を行う必要があります。デフォルトの initramfs の内容を確認するには、[[mkinitcpio#イメージの抽出|lsinitcpio]] を使用してください。}}

=== カーネルコマンドラインを使う ===

モジュールがカーネルに組み込まれている場合、モジュールにオプションを設定するのにカーネルコマンドラインを使うこともできます。一般的なブートローダでは次の構文を使って下さい:

modname.parametername=parametercontents

例:

thinkpad_acpi.fan_control=1

[[カーネルパラメータ]]のページで説明されているようにして、あなたのブートローダのカーネルラインにこれを追加するだけです。

== エイリアス ==

エイリアスによってモジュールに代わりの名前を付けることができます。例: {{ic|alias my-mod really_long_modulename}} で {{ic|modprobe really_long_modulename}} の代わりに {{ic|modprobe my-mod}} を使うことができるようになります。シェルのようにワイルドカードを使うこともできます。{{ic|alias my-mod* really_long_modulename}} で {{ic|modprobe my-mod-something}} が {{ic|modprobe really_long_modulename}} と同じ意味になります。エイリアスを作るには:

{{hc|/etc/modprobe.d/myalias.conf|
alias mymod really_long_module_name}}

モジュールによっては、アプリケーションがモジュールを必要としたときに自動でロードするためにエイリアスが設定されているものもあります。こういったエイリアスを無効化すると自動ロードも止まります。ただし手動でモジュールをロードすることはできます。

{{hc|/etc/modprobe.d/modprobe.conf|
# Prevent Bluetooth autoload

alias net-pf-31 off}}

== ブラックリスト ==

カーネルモジュールで、ブラックリストとはカーネルモジュールをロードしないようにすることを指します。ブラックリストが役にたつのは、例えば、関連するハードウェアが必要ない場合や、モジュールをロードすると問題が発生する場合: 2つのカーネルモジュールが同じハードウェアをコントロールしようとして、互いにコンフリクトを生じる場合などです。

いくつかのモジュールは [[mkinitcpio|initramfs]] の一部としてロードされます。{{ic|mkinitcpio -M}} ですべての自動検出したモジュールを表示します: initramfs のモジュールのロードを止めるには、{{ic|/etc/modprobe.d/}} 中に {{ic|.conf}} ファイルを作成してモジュールをブラックリストに登録します。{{ic|mkinitcpio -v}} を実行することで様々なフック（例: ファイルシステムフック、SCSI フックなど）によって使われている全てのモジュールを一覧できます。モジュールをブラックリスト入りさせたら、[[mkinitcpio#イメージ作成とアクティベーション|イメージを生成]]し、それから再起動してください。

{{Note|{{ic|modconf}} [[mkinitcpio#HOOKS|フック]] が有効になっていない場合は、{{ic|/etc/mkinitcpio.conf}} の FILES セクションに使った {{ic|.conf}} ファイルを追加する必要があります。}}

=== /etc/modprobe.d/ 内のファイルを使う ===

{{ic|/etc/modprobe.d/}} 内に {{ic|.conf}} ファイルを作成し、{{ic|blacklist}} キーワードを使って一行ずつブラックリスト入りさせたいモジュールを追加します。例えば {{ic|pcspkr}} モジュールをロードさせたくない場合:

{{hc|/etc/modprobe.d/nobeep.conf|
# Do not load the 'pcspkr' module on boot
blacklist pcspkr}}

{{Note|{{ic|blacklist}} コマンドはモジュールをブラックリスト入りさせて自動でロードしないようにしますが、他のブラックリスト入りしてないモジュールによって必要になった場合、モジュールがロードされることがあります。また、手動でモジュールをロードすることも可能です。

しかしながら、この挙動を変えることが可能です; {{ic|install}} コマンドを使って、modprobe に通常通りカーネルでモジュールを挿入する代わりにカスタムコマンドを実行させることで、いつでもモジュールのロードが失敗するように強制することができます:

{{hc|/etc/modprobe.d/blacklist.conf|
...
install ''module_name'' /bin/true
...}}

事実上の、モジュールとそれが必要な他のモジュールのブラックリスト化になります。}}

{{Note|複数のモジュールをブラックリスト入りさせるときは、カンマで分割することを覚えておいて下さい。スペースなどを使うとシンタックスを破壊してしまうおそれがあります。}}

=== カーネルコマンドラインを使う ===

{{Tip|問題のあるモジュールによってシステムが起動できない場合、この方法が役に立つでしょう。}}

ブートローダでモジュールをブラックリスト入りさせることもできます。

[[カーネルパラメータ]]のページで説明されているようにして、あなたのブートローダのカーネルラインに {{ic|1=module_blacklist=modname1,modname2,modname3}} を追加するだけです。

{{Note|
* 複数のモジュールをブラックリスト入りさせるときは、カンマで分割することを覚えておいて下さい。スペースなどを使うとシンタックスを破壊してしまうおそれがあります。
* {{ic|module_blacklist}} を使用すると、カーネルはそのモジュールのロードを完全に拒否します。暗黙のロードを防ぎたいだけで、後で手動でモジュールをロードする可能性がある場合は、正しいパラメータは {{ic|1=modprobe.blacklist=modname1,modname2,modname3}} です。ただし、これでは、たとえば[[#systemd|systemd]] や他のモジュールによる起動中の明示的なロードを防ぐことはできません。
}}

=== インストールしない ===

[[pacman#インストールさせないファイルを設定]]を使えます。
{{hc|/etc/pacman.conf|2=NoExtract=usr/lib/modules/*/kernel/drivers/md/*
}}
これが最も確実な方法です。

== トラブルシューティング ==

=== モジュールがロードされない ===

特定のモジュールがロードされない場合、起動ログ ({{ic|journalctl -b}} で見れます) にモジュールがブラックリストに入っていると書かれているのに {{ic|/etc/modprobe.d/}} ディレクトリには該当するエントリが存在しないとき、{{ic|/usr/lib/modprobe.d/}} にある他の modprobe ソースファイルにブラックリストのエントリがないか確認してください。

カーネルモジュールに含まれている "vermagic" 文字列が、現在実行中のカーネルの値と一致しない場合もモジュールはロードされません。カーネルとモジュールの互換性に問題がないという確証があるときは {{ic|modprobe --force-vermagic}} で "vermagic" のチェックを無視させることができます。

{{warning|カーネルモジュールのバージョンチェックを無視するとカーネルがクラッシュしたり、システムが予期しない挙動を見せる可能性があります。{{ic|--force-vermagic}} を使うときは細心の注意を払ってください。}}

== 参照 ==

* [[PC スピーカーのビープ音の無効化]]
* [https://lwn.net/Articles/391230/ Writing a WMI driver] - an LWM introduction

{{TranslationStatus|Kernel module|2024-08-23|803682}}

Pacman

2025-04-04T17:37:24Z

Oech3: CacheDirを/tmp以下にする場合の注意/* パッケージのキャッシュディレクトリ */

{{Lowercase title}}
[[Category:Arch プロジェクト]]
[[Category:パッケージマネージャー]]
[[de:Pacman]]
[[en:Pacman]]
[[es:Pacman]]
[[fi:Pacman]]
[[fr:Pacman]]
[[it:Pacman]]
[[pl:Pacman]]
[[pt:Pacman]]
[[ru:Pacman]]
[[sv:Pacman]]
[[zh-hans:Pacman]]
{{Related articles start}}
{{Related|pacman/パッケージの署名}}
{{Related|pacman/Pacnew と Pacsave}}
{{Related|pacman/ローカルデータベースの復元}}
{{Related|pacman/比較表}}
{{Related|pacman/ヒントとテクニック}}
{{Related|Arch User Repository}}
{{Related|パッケージの作成}}
{{Related|パッケージのダウングレード}}
{{Related|namcap}}
{{Related|FAQ#パッケージ管理}}
{{Related|システムメンテナンス}}
{{Related articles end}}

[https://pacman.archlinux.page/ pacman] [[Wikipedia:ja:パッケージ管理システム|パッケージマネージャ]]は [[Arch Linux]] の主要な機能のひとつです。pacman はシンプルなバイナリのパッケージ形式と簡単に利用できる [[Arch build system]] から成っています。pacman のゴールはパッケージ管理を楽にすることであり、[[公式リポジトリ]]にあるパッケージや、ユーザー自身が作成したパッケージを容易に管理することができます。

''Pacman'' はマスターサーバーと同期してシステムを最新に保ちます。このサーバー・クライアントモデルによって、シンプルなコマンドだけで必要な依存性を解決してパッケージのダウンロード・インストールをすることができます。

''Pacman'' は [[C]] 言語で書かれており、パッケージングに {{man|1|bsdtar}} [[Wikipedia:ja:tar|tar]] フォーマットを使用します。

{{Tip|1={{Pkg|pacman}} パッケージには [[makepkg]] や {{man|8|vercmp}} などのツールが含まれています。[[#Pactree|pactree]] や [[checkupdates]] など、他の有用なツールは {{Pkg|pacman-contrib}} パッケージに含まれています ([https://gitlab.archlinux.org/pacman/pacman/commit/0c99eabd50752310f42ec808c8734a338122ec86 以前]は ''pacman'' パッケージに含まれていました)。ツールの一覧を見るには {{ic|pacman -Ql pacman pacman-contrib {{!}} grep -E 'bin/.+'}} を実行してください。}}

== 使い方 ==

pacman で何ができるかをちゃんと学びたい場合、{{man|8|pacman}} を参照してください。以下にあるのは pacman でできることのほんの一例です。

{{Tip|他の Linux ディストリビューションを使ったことがある場合、[[Pacman/比較表]]の記事が役に立つでしょう。}}

=== パッケージのインストール ===

パッケージとは、以下を含むアーカイブです:

* アプリケーションの (コンパイルされた) 全ファイル
* アプリケーションのメタデータ (アプリケーション名、バージョン、依存関係など)
* ''pacman'' によって使用されるインストールファイル及びディレクティブ

Arch のパッケージマネージャである ''pacman'' は、このようなパッケージをインストール、アップデート、そして削除することができます。プログラムを自分でコンパイルしてインストールする代わりにパッケージを使用することには、様々な利点があります:

* 簡単なアップデート: ''pacman'' は、アップデートが利用可能になるとすぐに既存のパッケージを更新します。
* 依存関係のチェック: ''pacman'' は依存関係を処理してくれます。あなたがすべきことは、インストールしたいプログラムを指定することだけです。''pacman'' はそのプログラムと一緒に他の必要なプログラムもインストールします。
* 綺麗にアンインストール: ''pacman'' は、パッケージに含まれる全ファイルのリストを保持します。これにより、パッケージを削除する際に意図せずファイルが残留することはありません。

{{Note|
* パッケージには、[[PKGBUILD#optdepends|任意の依存パッケージ]]が設定されていることがあります。必ずインストールする必要はありませんが、インストールすることで機能が追加されます。''pacman'' は、パッケージのインストール時に任意の依存パッケージのリストを表示しますが、そのリストは {{ic|pacman.log}} に残りません。[[#パッケージ・データベースに問い合わせる]] コマンドを使うことで、パッケージの任意の依存パッケージを見ることができます。
* 他のパッケージの (任意の) 依存パッケージとしてパッケージをインストールする場合 (つまり、そのパッケージ自体は必要としていない場合)、{{ic|--asdeps}} オプションを使用することを推奨します。詳しくは [[#インストール理由]] セクションを参照。}}

{{Warning|1=Arch でパッケージのインストールをする際に、[[#パッケージのアップグレード|システムのアップグレード]]をせずにパッケージリストを更新することは避けてください (例えば、公式リポジトリで[[#インストール時にパッケージを取得できない|パッケージが見つからなくなった]]時など)。実際の場面でいうと、{{ic|pacman -Sy'''u''' ''パッケージ名''}} の代わりに {{ic|pacman -Sy ''パッケージ名''}} を実行しては'''いけない'''ということです。これを実行すると依存関係に問題が発生する可能性があります。[[システムメンテナンス#部分的なアップグレードはサポートされていません]] や [https://bbs.archlinux.org/viewtopic.php?id=89328 BBS#89328] を参照。}}

==== 特定のパッケージのインストール ====

ひとつ、あるいは複数のパッケージを、依存パッケージも含めてインストールするには、以下のコマンドを実行してください:

# pacman -S ''パッケージ名1'' ''パッケージ名2'' ...

正規表現を使ってパッケージをインストールするには ([https://bbs.archlinux.org/viewtopic.php?id=7179 このフォーラムスレッド] を参照):

# pacman -S $(pacman -Ssq ''パッケージのパターン'')

別々のリポジトリ (例: ''extra'' と ''testing'') 内に同一のパッケージの複数のバージョンが存在していることがあります。この場合、パッケージ名の前にリポジトリ名を明示する必要があります。例えば ''extra'' リポジトリ内のバージョンをインストールするには:

# pacman -S extra/''パッケージ名''

名前に類似パターンが存在するパッケージをインストールしたい場合、波括弧を使ってパッケージ名を展開することができます。例えば:

# pacman -S plasma-{desktop,mediacenter,nm}

必要に応じて更に複雑なパターンを指定することもできます:

# pacman -S plasma-{workspace{,-wallpapers},pa}

===== 仮想パッケージ =====

仮想パッケージとは、それ自体は存在していないが、1つ以上のパッケージによって [[PKGBUILD#provides|provides (提供)]] 指定されている特殊なパッケージです。仮想パッケージが存在していることにより、あるパッケージの依存関係として複数の候補が存在している場合に、パッケージは特定のパッケージを依存関係として指定する必要がなくなります。仮想パッケージはその名前を使ってインストールすることはできません。仮想パッケージを ''provide (提供)'' するパッケージをインストールすると、その仮想パッケージがシステムにインストールされたことになります。例としては [[D-Bus#実装|dbus-units]] パッケージがあります。

{{Tip|複数の候補が存在する場合、候補のリストは、{{ic|pacman.conf}} 内に現れる[[リポジトリ]]の順番でソートされ、そして同一のリポジトリ内にも複数の候補が存在する場合はさらにアルファベット順にソートされます。}}

==== パッケージグループのインストール ====

[[パッケージグループ]]に属しているパッケージをすべて同時にインストールすることができます。例えば:

# pacman -S gnome

を実行すると {{Grp|gnome}} グループからインストールしたいパッケージを選択するように表示されます。

パッケージグループには大量のパッケージが含まれており、しばしばインストールしたいパッケージはそのうちの少しだけということがあるかもしれません。インストールするパッケージの番号を全て入力するという方法でもよいですが、以下のような構文を使うことで簡単にパッケージを選択することが可能です:

Enter a selection (default=all): 1-10 15

以上で1番から10番までと15番のパッケージがインストールされます。

Enter a selection (default=all): ^5-8 ^2

以上で5番から8番までと2番のパッケージ以外の全てのパッケージをインストールします。

どのパッケージが gnome グループに属しているか見るには:

$ pacman -Sg gnome

どのようなパッケージグループがあるかは https://www.archlinux.jp/groups/ を見て下さい。

{{Note|グループの中にインストール済みのパッケージがある場合でも、グループにあわせて再インストールされます。{{ic|--needed}} オプションを使うことで無視できます。}}

=== パッケージの削除 ===

依存パッケージをすべて残したままパッケージを削除するには:

# pacman -R ''パッケージ名''

削除したいパッケージと、そのパッケージだけが必要としている依存パッケージを一緒に削除するには:

# pacman -Rs ''パッケージ名''

{{Warning|グループ (例えば ''gnome'') を削除する場合、このコマンドはそのグループ内のパッケージのインストール理由を無視します。グループを指定した場合、そのグループ内のパッケージを分けて指定したかのように振る舞うからです。依存関係のインストール理由は依然として考慮されます。}}

上記のコマンドは、必要とされているパッケージを含んでいるグループを削除する際に、実行を拒否する場合があります。そのような場合は、以下を試してください:

# pacman -Rsu ''パッケージ名''

削除したいパッケージと、そのパッケージの依存パッケージ、さらに削除したいパッケージに依存しているパッケージを削除するには:

{{Warning|この操作は再帰的です。潜在的に必要とされているパッケージも削除してしまう可能性があるので、注意して使用しなければなりません。}}

# pacman -Rsc ''パッケージ名''

他のパッケージによって必要とされているパッケージを、必要としているパッケージを削除せずに削除するには:

{{Warning|以下の操作はシステムを破壊する可能性があり、使用は避けるべきです。[[システムメンテナンス#特定の pacman コマンドを避けてください]] を参照してください。}}

# pacman -Rdd ''パッケージ名''

''Pacman'' は、特定のアプリケーションを削除する際に、重要な設定ファイルを削除せずに ''.pacsave'' 拡張子を付けてバックアップします。これらのバックアップファイルの作成を行わないようにするには、{{ic|-n}} オプションを付けてください:

# pacman -Rn ''パッケージ名''

{{Note|''Pacman'' は、アプリケーション自身が作成した設定ファイルを削除しません (例えば、ホームディレクトリ内の "ドットファイル")。}}

=== パッケージのアップグレード ===

{{Warning|
* Arch ユーザーは、[[システムメンテナンス#システムのアップグレード]] セクションのガイダンスに従ってシステムを定期的にアップグレードすることが期待されます。以下のコマンドを闇雲に実行するべきではありません。
* Arch Linux は完全なシステムアップグレードのみをサポートしています。詳細は [[システムメンテナンス#部分的なアップグレードはサポートされていません]] と [[#パッケージのインストール]] を参照してください。
}}

''Pacman'' はコマンド一つでシステム上の全パッケージをアップデートできます。この処理に掛かる時間は、システムがどれだけ新しいかによります。以下のコマンドは、リポジトリデータベースを同期し、''かつ''、システム内のパッケージをアップデートします (ただし、リポジトリに無い"ローカル"のパッケージを除く):

# pacman -Syu

=== パッケージ・データベースに問い合わせる ===

''Pacman'' からローカルデータベースに問い合わせるときは {{ic|-Q}} フラグを、同期データベースに問い合わせるときは {{ic|-S}} フラグを、ファイルデータベースに問い合わせるときは {{ic|-F}} フラグを使います。それぞれのフラグのサブオプションについては {{ic|pacman -Q --help}}、{{ic|pacman -S --help}}、{{ic|pacman -F --help}} を見てください。

''Pacman'' はデータベースからパッケージを検索することができます。パッケージ名と説明の両方を検索するには:

$ pacman -Ss ''検索ワード1'' ''検索ワード2'' ...

場合によっては、{{Ic|-s}} の組み込みの ERE (拡張正規表現) によって、余計な検索結果が大量に出てきてしまうことがあるでしょう。そのようなときは検索対象をパッケージ名だけに絞ってみてください:

$ pacman -Ss '^vim-'

既にインストール済みのパッケージから検索するには:

$ pacman -Qs ''検索ワード1'' ''検索ワード2'' ...

リモートパッケージからパッケージファイルの名前で検索するには:

$ pacman -F ''検索ワード1'' ''検索ワード2'' ...

パッケージ名を指定して詳細な情報を得るには:

$ pacman -Si ''パッケージ名''

ローカルにインストールされているパッケージの詳細な情報を得るには:

$ pacman -Qi ''パッケージ名''

{{ic|-i}} フラグを2つ付けることで、バックファイルのリストとバックアップファイルの変更状態も同時に表示できます:

$ pacman -Qii ''パッケージ名''

あるパッケージによってインストールされたファイルの一覧を得るには:

$ pacman -Ql ''パッケージ名''

リモートパッケージによってインストールされるファイルのリストを得るには:

$ pacman -Fl ''パッケージ名''

あるパッケージによってインストールされたファイルが存在しているか確認するには:

$ pacman -Qk ''パッケージ名''

{{ic|k}} フラグを2つ付けると、より徹底したチェックが行われます。

データベースを検索して、あるファイルがどのパッケージに属しているかを調べるには:

$ pacman -Qo ''/パス/ファイル名''

あるファイルがどのリモートパッケージに属しているかデータベースに問い合わせるには:

$ pacman -F ''/パス/ファイル名''

他のパッケージに必要とされていないパッケージ (孤児) の一覧を得るには:

$ pacman -Qdt

明示的にインストールしたパッケージで、依存関係として必要とされていないパッケージを全て表示するには:

$ pacman -Qet

その他の例については [[pacman/ヒントとテクニック]] を参照してください。

==== Pactree ====

{{Note|{{man|8|pactree}} は {{Pkg|pacman}} パッケージの一部ではなくなりました。代わりに、{{Pkg|pacman-contrib}} でインストールできます。}}

あるパッケージの依存関係ツリー (dependency tree、つまり、そのパッケージ'''が'''必要としているパッケージの木) を表示するには:

$ pactree ''パッケージ名''

あるパッケージの被依存ツリー (dependant tree、つまり、そのパッケージ'''を'''必要としているパッケージの木) を表示するには、逆フラグ {{ic|-r}} を ''pactree'' に渡てください。

==== データベースの構造 ====

''pacman'' データベースは通常、{{ic|/var/lib/pacman/sync}} にあります。{{ic|/etc/pacman.conf}} で指定された各リポジトリに対して、対応するデータベースファイルがこのディレクトリ内に存在します。データベースファイルは、パッケージごとに 1 つのディレクトリを含む gzip 圧縮された tar アーカイブです。たとえば、{{Pkg|which}} パッケージの場合は次のようになります:

{{hc|$ tree which-2.21-5|
which-2.21-5
{{!}}-- desc
}}

{{ic|desc}} ファイルには、パッケージの説明、依存関係、ファイルサイズ、MD5 ハッシュなどのメタデータが含まれています。

=== パッケージキャッシュの削除 ===

''Pacman'' は、ダウンロードしたファイルを {{ic|/var/cache/pacman/pkg/}} に保存しますが、これらは古くなってもアンインストールされても自動的に削除されません。これにはいくつかの利点があります:

# パッケージを[[ダウングレード]]する際に、他の方法 ([[Arch Linux Archive]] など) によって以前のバージョンを入手する必要がない。
# アンインストールされたパッケージをキャッシュディレクトリから簡単に直接再インストールでき、リポジトリから新しくダウンロードする必要がない。

しかし、ディレクトリのサイズが大きくなりすぎないようにするために、定期的にキャッシュを手動でクリーンアップする必要があります。

{{Pkg|pacman-contrib}} パッケージで提供されている {{man|8|paccache}} スクリプトは、インストール済みパッケージとアンインストール済みパッケージのキャッシュ済みバージョンを、最も新しい3つを残して全て削除します (オプションを何も指定しなかった場合):

# paccache -r

{{ic|paccache.timer}} を[[有効化]]し[[起動]]すれば、週に1度、未使用のパッケージキャッシュを削除してくれます。

{{Tip|1=''pacman'' のトランザクションの度にこの操作を自動で実行する[[#フック|フック]]を作成することもできます。フックを導入する {{AUR|paccache-hook}} を[[インストール]]することもできます。[https://bbs.archlinux.org/viewtopic.php?pid=1694743#p1694743 フックの例]もあります。}}

何個の新しいバージョンのキャッシュを保持するかを指定することも可能です。最も新しいバージョン1つだけを保持するには:

# paccache -rk1

{{ic|-u}}/{{ic|--uninstalled}} スイッチを加えれば、アンインストールされたパッケージに対象を絞ることもできます。例えば、アンインストールされたパッケージのキャッシュを全て削除するには:

# paccache -ruk0

その他のオプションは {{ic|paccache -h}} を見てください。

また、''Pacman'' にも、パッケージキャッシュと、{{ic|/etc/pacman.conf}} 設定ファイルにもはや存在しないリポジトリの残留データベースファイルをクリーンアップする組み込みコマンドが存在します。しかし、''pacman'' では、パッケージキャッシュのバージョンをいくつ残すか指定することができないため、''paccache'' のデフォルトオプションよりも強引です。

現在インストールされていないパッケージのキャッシュと、未使用の同期データベースをを全て削除するには:

# pacman -Sc

全てのキャッシュファイルを削除するには、{{ic|c}} スイッチを2度使用してください。これは最も強引なアプローチであり、キャッシュディレクトリには何も残りません:

# pacman -Scc

{{Warning|ディスクの空き容量がどうしても必要でない限り、インストール済みパッケージとアンインストール済みパッケージのキャッシュを全て削除することは避けるべきです。さもないと、パッケージをダウングレードしたり再インストールしたりするためにファイルを再ダウンロードしなければならなくなってしまいます。}}

さらに、キャッシュをクリーンアップするツールとして {{AUR|pkgcacheclean}} と {{AUR|pacleaner}} もあります。

=== その他のコマンド ===

パッケージをダウンロードするが、インストールはしない:

# pacman -Sw ''パッケージ名''

リモートリポジトリ以外の'ローカル'のパッケージをインストールする (例えば、[[AUR]] のパッケージ):

# pacman -U ''/path/to/package/package_name-version.pkg.tar.zst''

ローカルパッケージのコピーを ''pacman'' のキャッシュに保持するには:

# pacman -U file:///''path/to/package/package_name-version.pkg.tar.zst''

(''pacman'' の設定ファイルに記述されているリポジトリ以外の) 'リモート'パッケージをインストールする:

# pacman -U ''<nowiki>http://www.example.com/repo/example.pkg.tar.zst</nowiki>''

==== ドライラン ====

''Pacman'' は'''常に'''、インストールされるパッケージと削除されるパッケージを一覧表示して、操作を行う前にユーザに許可を求めます。

{{ic|--print}} (短いバージョンは {{ic|-p}}) を使用することで、{{ic|-S}}、{{ic|-U}}、{{ic|-R}} のアクションを行わずに、パッケージの一覧を処理可能な形式で表示できます。

{{ic|--print-format}} を追加すれば、このリストを様々な形にフォーマットできます。例えば、{{ic|--print-format %n}} は、パッケージのバージョン無しでパッケージの一覧を表示します。

=== インストール理由 ===

''pacman'' データベースでは、インストールしたパッケージはインストール理由によって2つのグループに分別されます:

*'''明示的にインストール''': ''pacman'' の {{ic|-S}} や {{ic|-U}} コマンドによって文字通り指定されたパッケージ。
*'''依存パッケージ''': ''pacman'' のインストールコマンドにパッケージの名前は指定されず、明示的にインストールした他のパッケージから[[PKGBUILD#依存関係|必要]]とされたためにインストールされたパッケージ。

パッケージのインストール時、以下のようにすることでインストール理由を''依存パッケージ''に強制的に変えることができます:

# pacman -S --asdeps ''パッケージ名''

明示的にインストールしたパッケージが、必須でない機能のための[[optdepends|任意の依存パッケージ]]を提供している場合があります。大抵、このコマンドはそのようなパッケージをインストールするために使用されます。

{{Tip|任意の依存パッケージを {{ic|--asdeps}} でインストールすると、[[pacman/ヒントとテクニック#使用していないパッケージ (孤立したパッケージ) の削除|孤立したパッケージを削除]]するときに ''pacman'' によって任意の依存パッケージも削除されるようになります。}}

パッケージの'''再'''インストールを行っても、デフォルトではインストール理由は変更されません。

明示的にインストールしたパッケージのリストは {{ic|pacman -Qe}} で表示でき、依存パッケージのリストは {{ic|pacman -Qd}} で表示できます。

既にインストールしたパッケージのインストール理由を変更したい場合、以下のコマンドを実行してください:

# pacman -D --asdeps ''パッケージ名''

Use {{ic|--asexplicit}} to do the opposite operation.

{{Note|{{ic|pacman -Syu ''パッケージ名'' --asdeps}} のように、アップグレードをするときに {{ic|--asdeps}} や {{ic|--asexplicit}} オプションを使用するのは推奨されません。インストールされるパッケージだけでなく、アップグレードされるパッケージのインストール理由まで変更されてしまうためです。}}

=== 特定のファイルが含まれているパッケージを検索 ===

ファイルデータベースを同期してください:

# pacman -Fy

ファイルが含まれているパッケージを検索するには:

{{hc|$ pacman -F pacman|
core/pacman 5.2.1-1 (base base-devel) [installed]
usr/bin/pacman
usr/share/bash-completion/completions/pacman
extra/xscreensaver 5.43-1
usr/lib/xscreensaver/pacman
}}

{{Tip|{{ic|pacman-filesdb-refresh.timer}} ({{Pkg|pacman-contrib}} パッケージに同梱されています) を[[起動/有効化]]すれば、''pacman'' ファイルデータベースを週ごとにリフレッシュできます。}}

高度な使い方をしたい場合、全てのファイルと関連するパッケージのデータベースを使用する [[pkgfile]] をインストールしてください。

=== パッケージのインストール/アップグレード/アンインストール時に起こること ===

成功時のトランザクションは、5つのステップと、トランザクション前と後のフックで構成されます:

# データベースがロックされていない場合、トランザクションを初期化する。
# トランザクション中に追加/削除すべきパッケージを選択する。
# 同期データベース、パッケージ、及びパッケージ間の依存関係のサニティチェックを行い、コマンドラインフラグに基づいてトランザクションの準備をする。
# トランザクションを実行する:
## 必要に応じてパッケージをダウンロードする ({{ic|_alpm_sync_load}})。
## ''pacman'' の既存の {{ic|PreTransaction}} フックが適用される場合、それらのフックを実行する。
## 最終的に置き換えられるパッケージ、衝突するパッケージ、明示的に削除するように指定されたパッケージを削除する。
## 追加するべきパッケージが存在する場合、各パッケージに対して以下を実行する:
### パッケージにインストールスクリプトが存在する場合、そのスクリプトの {{ic|pre_install}} 関数を実行する (アップグレードする場合は {{ic|pre_upgrade}} が、削除される場合は {{ic|pre_remove}} が代わりに実行されます)。
### 以前のバージョンのパッケージのファイルを全て削除する (パッケージをアップグレードまたは削除する場合)。ただし、パッケージによって設定ファイルであると指定されたファイルに関しては、削除しない ([[pacman/Pacnew と Pacsave]] を参照)。
### パッケージを解凍し、含まれているファイルをファイルシステムに保存する (パッケージをインストールまたはアップグレードする場合)。新しいパッケージのファイルが、ファイルシステム上の手動で変更された設定ファイル (前のステップを参照) を上書きしてしまう場合、パッケージ側のファイルに別の名前 (''.pacnew'') を付けて保存する。
### パッケージにインストールスクリプトが存在する場合、{{ic|post_install}} 関数を実行する (アップグレードする場合は {{ic|post_upgrade}} が、削除される場合は {{ic|post_remove}} が代わりに実行されます)。
## トランザクションの終わりの時点で存在している {{ic|PostTransaction}} フックが適用される場合、それらのフックを実行する。
# トランザクション及びトランザクションリソース (つまり、データベースロック) を解放する。

== 設定 ==

''Pacman'' の設定は {{ic|/etc/pacman.conf}} に記述します。ここで、pacman がどのように動作するかを設定することができます。この設定ファイルに関するより詳しい情報は {{man|5|pacman.conf}} にあります。

=== 全般設定 ===

全般的な設定は {{ic|[options]}} セクションにあります。ここで設定できる項目については {{man|5|pacman.conf}} を読むか、デフォルトの {{ic|pacman.conf}} ファイルを見てください。

==== アップデートする前にバージョンを比較 ====

利用可能なパッケージの新旧のバージョンを確認したい場合、{{ic|/etc/pacman.conf}} の "VerbosePkgLists" という行をアンコメントしてください。{{ic|pacman -Syu}} の出力が以下のようになります:

パッケージ (6) 古いバージョン新しいバージョン最終的な変化ダウンロード容量

extra/libmariadbclient 10.1.9-4 10.1.10-1 0.03 MiB 4.35 MiB
extra/libpng 1.6.19-1 1.6.20-1 0.00 MiB 0.23 MiB
extra/mariadb 10.1.9-4 10.1.10-1 0.26 MiB 13.80 MiB

==== 並列ダウンロードを有効にする ====

並列にダウンロードするパッケージの数は、{{ic|/etc/pacman.conf}} の {{ic|[options]}} セクション内の {{ic|ParallelDownloads}} オプションで設定できます。このオプションが設定されていない場合、パッケージは1つずつダウンロードされます。

==== アップグレードさせないパッケージを設定 ====

{{Warning|[[部分的なアップグレード]]はサポートされていないので、パッケージのアップグレードをスキップする際は気をつけてください。。}}

システムを[[#パッケージのアップグレード|アップグレード]]する際に特定のパッケージをアップグレードシないようにするには、{{ic|[options]}} セクションに以下の行を追加してください:

IgnorePkg=linux

複数のパッケージを指定する場合は、スペースで区切るか、{{ic|IgnorePkg}} 行を追加してください。また、[[Wikipedia:ja:グロブ|グロブ]]パターンも使用できます。一度に限ってパッケージをアップグレードしないようにするには、コマンドラインで {{ic|--ignore}} オプションを使用してください (複数のパッケージを指定する場合は、コンマで区切ってください)。

{{ic|pacman -S}} を使えば、依然として対象のパッケージをアップグレードすることが可能です。この場合、''pacman'' はパッケージが {{ic|IgnorePkg}} 文に含まれていることを知らせてくれます。

==== アップグレードさせないパッケージグループを設定 ====

{{Warning|[[部分的なアップグレード]]はサポートされていないので、パッケージグループのアップグレードをスキップする際は気をつけてください。。}}

パッケージの場合と同様に、アップグレードさせないパッケージグループを指定することもできます:

IgnoreGroup=gnome

==== アップグレードさせないファイルを設定 ====

{{Ic|NoUpgrade}} ディレクティブで指定されたファイルは、パッケージのインストール/アップグレードの際に変更を加えられなくなり、代わりに新しいファイルは ''.pacnew'' 拡張子が付けられてインストールされます。

NoUpgrade=''path/to/file''

以下のようにして複数のファイルを指定することができます:

NoUpgrade=''path/to/file1 path/to/file2''

{{Note|パスはパッケージアーカイブ内のファイルを示します。なので、一番最初にスラッシュを置かないでください。}}

==== インストールさせないファイルを設定 ====

特定のディレクトリまたはファイルをインストールさせないようにするには、{{Ic|NoExtract}} リストにそのディレクトリを加えてください。例えば、[[systemd]] ユニットをインストールさせないようにするには:

NoExtract=usr/lib/systemd/system/*

後ろのルールは前のルールを上書きします。また、{{ic|!}} を前に付けることでルールを無効化できます。

{{Tip|Pacman は、''localepurge'' や ''bleachbit'' によってロケールが削除されたパッケージをアップデートする際に、ロケールが存在しないという警告メッセージを表示します。警告を表示しないようにするには、{{ic|pacman.conf}} の {{ic|CheckSpace}} オプションをコメントアウトしてください。ただし、容量チェックの機能が全てのパッケージで無効化されることに注意してください。}}

==== 複数の設定ファイルを使用 ====

設定ファイルが複数あって (メインの設定と [[testing]] リポジトリを有効にした設定がある場合など)、設定ファイルのオプションを共有したい場合、設定ファイルで {{ic|Include}} オプションを宣言することができます。例:

Include = ''/path/to/common/settings''

{{ic|''/path/to/common/settings''}} は共有したいオプションが存在するファイルに置き換えてください。

==== フック ====

Pacman は {{ic|/usr/share/libalpm/hooks/}} ディレクトリ内に存在するフックをトランザクションの前後に実行することができます。その他のフックディレクトリを指定したい場合は、{{ic|pacman.conf}} 内で {{ic|HookDir}} オプションを使ってください (デフォルトは {{ic|/etc/pacman.d/hooks}} です)。フックファイルの名前には必ず ''.hook'' を後ろに付ける必要があります。Pacman フックはインタラクティブではありません。

Pacman フックは様々なことに使われています。例えば、{{ic|systemd-sysusers}} と {{ic|systemd-tmpfiles}} を組み合わせてパッケージのインストール時に自動的にシステムユーザーを作成します。例として {{pkg|tomcat8}} パッケージでは {{ic|tomcat8}} という名前のシステムユーザーが必要だと指定されており、特定のディレクトリの所有者がこのユーザーになるように設定されています。''pacman'' フックの {{ic|systemd-sysusers.hook}} と {{ic|systemd-tmpfiles.hook}} は、{{ic|tomcat8}} にユーザが指定されているファイルと一時ファイルが存在していることを認識し、{{ic|systemd-sysusers}} と {{ic|systemd-tmpfiles}} を実行します。

alpm のフックに関する詳細は {{man|5|alpm-hooks}} を参照してください。

=== リポジトリとミラー ===

特殊な [[#全般設定|[options]]] セクションを除いて、{{ic|pacman.conf}} 内の他の {{ic|[セクション]}} には、使用するパッケージリポジトリを定義します。''リポジトリ''とはパッケージの''論理的な''集合であり、それらのパッケージは1つ以上のサーバに''物理的に''保存されています。このような理由から、各サーバはリポジトリの''ミラー''と呼ばれます。

リポジトリは[[公式リポジトリ|公式]]と[[非公式ユーザーリポジトリ|非公式]]に分けられています。設定ファイル内でのリポジトリの順番は重要です。2つのリポジトリに同じ名前のパッケージが存在する場合、それらのバージョン番号に関わらず、設定ファイル内で最初に来るリポジトリが、その後に来るリポジトリよりも優先されます。リポジトリを使用するには、そのリポジトリを追加した後に、まずシステム全体を[[#パッケージのアップグレード|アップグレード]]する必要があります。

各リポジトリセクションではミラーのリストを定義します: ミラーのリストを直接記述することもできますし、{{ic|Include}} ディレクティブを使って外部の専用のファイルを使うこともできます。例えば、公式リポジトリのミラーは {{ic|/etc/pacman.d/mirrorlist}} からインクルードされます。ミラーの設定については記事 [[ミラー]] を参照してください。

==== パッケージのキャッシュディレクトリ ====

Pacman は、ダウンロードしたパッケージファイルをキャッシュに保存します。キャッシュは、{{ic|pacman.conf}} の [[#全般設定|[options]]] セクション内の {{ic|CacheDir}} で示されるディレクトリ内です (設定されていない場合、{{ic|/var/cache/pacman/pkg/}} がデフォルトで使用されます)。

キャッシュディレクトリは、(たとえ、インストールされているパッケージの最新のバージョンのみを保持しているとしても) 時間とともに肥大化する場合があります。

キャッシュディレクトリを他のより好都合な場所に移動したい場合は、以下のどれかを行ってください:

* {{ic|pacman.conf}} 内の {{ic|CacheDir}} オプションで新しいディレクトリを設定する。末尾のスラッシュを残しておくことを忘れないでください。'''これが推奨される方法です'''。
* {{ic|/var/cache/pacman/pkg/}} に専用のパーティションや [[Btrfs#サブボリューム|Btrfs サブボリューム]]をマウントする。
* 選択したディレクトリを {{ic|/var/cache/pacman/pkg/}} でバインドマウントする。

{{Warning|{{ic|/var/cache/pacman/pkg/}} ディレクトリを他の場所への'''シンボリックリンクにしないでください'''。Pacman の誤動作の'''原因になります'''。特に、pacman が自分自身をアップデートしようとしている場合です。}}
{{Warning|{{ic|CacheDir}}を/tmp以下に設定する事は、あなたが早さやディスクスペース,ストレージの寿命に敏感な場合にのみ推奨されます。}}

==== パッケージのセキュリティ ====

Pacman はパッケージの署名をサポートしていて、パッケージにセキュリティレイヤーを加えています。デフォルトの設定では {{ic|1=SigLevel = Required DatabaseOptional}} によって全てのリポジトリで全てのパッケージの署名検証が有効にされています。リポジトリ毎に {{ic|SigLevel}} を使うことでこの設定を上書きすることができます。パッケージに署名する方法や署名の検証について詳しくは、[[pacman-key]] を見てください。

==トラブルシューティング==

=== "Failed to commit transaction (conflicting files)" エラー ===

次のエラーが表示される場合: [https://bbs.archlinux.org/viewtopic.php?id=56373]

エラー: 処理を完了できませんでした (衝突しているファイル)
''package'': ''/path/to/file'' がファイルシステムに存在しています
エラーが発生したため、パッケージは更新されませんでした。

これは、''pacman'' がファイルの衝突を検出し、仕様によりファイルを上書きしないために発生します。これは仕様によるものであり、欠陥ではありません。

通常、この問題の解決法は自明です (とはいえ、なぜこれらのファイルがそこに存在しているのかを念の為に調べてみるべきでしょう)。まず、他のパッケージがそのファイルを所有していないか調べるのが安全です ({{ic|pacman -Qo ''/path/to/file''}})。そのファイルが他のパッケージによって所有されている場合、[[バグ報告ガイドライン|バグレポートを提出]]してください。そのファイルが他のパッケージのよって所有されていない場合、"ファイルシステムに存在している"方のファイルの名称を変更し、アップデートのコマンドを再度実行してください。問題がなければ、そのファイルは削除しても良いです。

何らかのプログラムを ''pacman'' を使用せずに (例えば {{ic|make install}} などで) 手動でインストールしている場合、プログラム自体とそのプログラムに属するファイルを全て削除しなければなりません。[[pacman/ヒントとテクニック#どのパッケージにも所有されていないファイルを特定する]] も参照してください。

インストールされたパッケージは、そのパッケージに関するメタデータを含む {{ic|/var/lib/pacman/local/''package-version''/files}} ファイルを提供します。このファイルが破損している、空である、または存在しない場合、パッケージの更新時に {{ic|file exists in filesystem}} エラーが発生します。そのようなエラーは通常、1つのパッケージだけが原因です。原因のパッケージに属するファイルの名前を変えて後で削除する代わりに、{{ic|pacman -S --overwrite ''glob'' ''package''}} を実行して {{ic|''glob''}} にマッチするファイルを上書きすることもできます。

{{Warning|通常、{{ic|--overwrite}} スイッチの使用は避けてください。[[システムメンテナンス#特定の pacman コマンドを避けてください]] を参照してください。}}

=== "Failed to commit transaction (invalid or corrupted package)" エラー ===

{{ic|/var/cache/pacman/pkg/}} から ''.part'' ファイル (部分的にダウンロードされたパッケージ) を探し、そのファイルを削除してください (これは、{{ic|pacman.conf}} でカスタムの {{ic|XferCommand}} を使用した場合に起こりやすいです):

# find /var/cache/pacman/pkg/ -iname "*.part" -delete

また、''archlinux-keyring'' が古く、''pacman'' が署名を検証できない場合にも、このエラーが発生することがあります。この問題を解決方法と防止方法は [[pacman/パッケージの署名#システムの定期的な更新]] を参照してください。

=== "Failed to init transaction (unable to lock database)" エラー ===

''pacman'' がパッケージデータベースを変更する際に (パッケージのインストール時など)、''pacman'' はロックファイル {{ic|/var/lib/pacman/db.lck}} を作成します。これにより、複数の ''pacman'' インスタンスが同時にパッケージデータベースを変更してしまうことを防ぎます。

''pacman'' がデータベースの変更中に中断されてしまった場合、古いロックファイルが残ってしまう可能性があります。''pacman'' インスタンスが実行中でないことが確実である場合は、ロックファイルを削除してください:

# rm /var/lib/pacman/db.lck

{{Tip|{{ic|fuser /var/lib/pacman/db.lck}} を root として実行すれば、ロックファイルを使用しているプロセスが存在するか調べることができます。}}

=== インストール時にパッケージを取得できない ===

具体的には次のようなエラーです: {{ic|Not found in sync db}}、{{ic|対象が見つかりませんでした}}、{{ic|ファイルの取得に失敗しました}}。

まず、パッケージが実際に存在することを確認してください。パッケージが存在することが確実であるならば、パッケージデータベースが古いのかもしれません。{{ic|pacman -Syu}} を実行して、パッケージデータベースを更新してシステムをアップグレードしてみてください。また、[[ミラー]]が最新であり、[[#リポジトリとミラー|リポジトリ]]が正しく設定されていることも確認してください。

また、インストールしたいパッケージが含まれているリポジトリがシステムで有効化されていない可能性もあります。例えば、パッケージが [[multilib]] リポジトリにあるが、{{ic|pacman.conf}} で ''multilib'' が有効化されていない場合、このエラーが発生します。

[[FAQ#公式リポジトリにある共用ライブラリはそれぞれどうして一つのバージョンしか用意されてないんですか？]] も参照してください。

=== アップグレードの中断によって起動できなくなったシステムを修復する ===

{{Accuracy|これには複数の潜在的な問題があります。[[:en:Talk:pacman#More details in pacman crashes during an update]] を参照。}}

電源断やカーネルパニック、ハードウェア障害によって、アップデートが中断されてしまうことがあります。ほとんどの場合、システムが大きなダメージを負うことはありませんが、起動できなくなってしまうことはあります。

# [[USB インストールメディア]] を用意して、それを起動してください。
# ルートファイルシステムを[[マウント]]してください。
# マウントしたルートファイルシステムに {{ic|arch-chroot}} してください。
# 次に、アップデートを完全にやり直します。{{ic|/var/log/pacman.log}} を確認し、中断されたトランザクション中にアップグレードされていたパッケージ''全ての''リストを {{ic|pacman -S}} に渡して、再インストールを許可してください。例:

# pacman -S linux linux-headers systemd systemd-libs systemd-sysvcompat firefox texlive-basic texlive-fontsextra texlive-latex texlive-latexextra texlive-latexrecommended texlive-pictures

アップグレードを''完全に''やり直すのは、適切なスクリプトレットとフックが実行されるようにするために必要だからです。

=== アップグレード中に pacman がクラッシュしてしまった ===

''pacman'' が "database write" (データベース書き込み) エラーが発生してクラッシュし、その後、パッケージのアンインストール/再インストール/アップグレードができなくなってしまった場合、以下を行ってください:

# Arch Linux の [[USB インストールメディア]]を起動してください。システム上の ''pacman'' と同じバージョンかより新しいものを使うために、最近のメディアを使うことが望ましいです。
# システムのルートファイルシステムをマウントしてください (例えば、{{ic|mount /dev/sdaX /mnt}} を root として実行してください)。そして、{{ic|df -h}} を実行してファイルシステムに十分な空き領域が存在することを確認してください。
# ファイルシステム proc、sys、dev もマウントしてください: {{ic|mount -t proc proc /mnt/proc; mount --rbind /sys /mnt/sys; mount --rbind /dev /mnt/dev}}
# システムにおいてデータベースの場所とディレクトリの場所がデフォルトである場合、{{ic|1=pacman --root=/mnt --cachedir=/mnt/var/cache/pacman/pkg -Syu}} を root として実行すればシステムの ''pacman'' データベースを更新してシステムをアップグレードすることができます。
#* アップデート/アップグレードができない場合、[[pacman/ヒントとテクニック#全てのパッケージの再インストール]] を参照してください。
# アップグレードしたら、アップグレードされていない壊れているパッケージがないかチェックしてください: {{ic|find /mnt/usr/lib -size 0}}
# そのようなパッケージが依然として存在する場合は、そのパッケージを再インストールしてください: {{ic|1=pacman --root /mnt --cachedir=/mnt/var/cache/pacman/pkg -S ''package''}}。

==== pacman: command not found ====

{{ic|/var/cache/pacman/pkg}} がシンボリックリンクである場合、''pacman'' は自己アップデート時に同じディレクトリを作成しようとするため、このシンボリックリンクは削除されます。これにより、アップデートが失敗します。その結果、{{ic|/usr/bin/pacman}} と {{Pkg|pacman}} パッケージに含まれる他のコンテンツが消えてしまいます (訳注: [[#パッケージのインストール/アップグレード/アンインストール時に起こること]] の 4.2 を参照)。

{{ic|/var/cache/pacman/pkg}} は ''pacman'' によって管理されているため、シンボリックリンクにしないでください。代わりに {{ic|CacheDir}} オプションを使うか、このディレクトリをバインドマウントしてください ([[#パッケージのキャッシュディレクトリ]] を参照)。

この問題が既に発生していて、システムが壊れてしまっている場合、''pacman'' パッケージに含まれる {{ic|/usr}} 内のコンテンツを手動で展開して ''pacman'' を復元し、その後、適切に ''pacman'' を再インストールしてください。詳細は {{Bug|73306}} や[https://bbs.archlinux.org/viewtopic.php?id=241213 関連するフォーラムのスレッド]を参照してください。

=== Pacman の手動再インストール ===

==== pacman-static を使う ====

{{AUR|pacman-static}} は ''pacman'' を静的にコンパイルしたものなので、システム上のライブラリが機能していなくても実行できます。これは、[[部分的なアップグレード]]によって ''pacman'' が実行できなくなってしまった場合にも便利です。

{{AUR|pacman-static}} パッケージのページにある固定コメントと PKGBUILD には、バイナリを直接ダウンロードする方法が記されています。''pacman'' を再インストールしたり、部分的なアップグレードが起こった際にシステム全体をアップグレードしたりする際にこの方法が使えます。

==== 外部の pacman を使う ====

{{ic|pacman-static}} でさえも動作しない場合は、外部の ''pacman'' を使用してリカバリできます。最も簡単な方法の一つは、[[archiso]] を使い、{{ic|--sysroot}} か {{ic|--root}} で、操作を行うシステム上のマウントポイントを指定することです。{{ic|--sysroot}} に必要なファイルシステムをマウントする方法については、[[Chroot#chroot を使う]] を参照してください。

==== 手動で抽出する ====

{{Warning|この方法では、一歩間違うとシステムの状態をさらに悪化させてしまいます。[[#アップグレード中に pacman がクラッシュしてしまった]] に書かれてある方法を使えない場合の最後の手段としてのみ、以下を行ってください。}}

''pacman'' がどうしようもなく破壊されたとしても、最新のパッケージを手動でダウンロードして適切な場所に展開することで修復が可能です。以下のような手順で行います:

# インストールすべき {{Pkg|pacman}} の依存関係を調べる。
# それぞれの依存パッケージを[[ミラー]]からダウンロードする。
# 各パッケージをルートディレクトリに展開する。
# {{ic|pacman -S --overwrite}} を実行してパッケージデータベースを更新することで、パッケージを再インストールする。
# システムの完全なアップグレードを行う。

正常に動作している Arch システムがあれば、以下のコマンドで ''pacman'' の依存関係リストを見ることができます:

$ pacman -Q $(pactree -u pacman)

しかし、発生している問題によっては、それらの依存パッケージのうち数個だけをアップデートすれば良い場合もあります。パッケージは以下のようにして展開します:

# tar -xvpwf ''package.tar.zst'' -C / --exclude .PKGINFO --exclude .INSTALL --exclude .MTREE --exclude .BUILDINFO

注意点として、{{ic|w}} フラグを使用してインタラクティブモードにしてください。非インタラクティブモードでは、重要なファイルが問答無用で上書きされてしまうかもしれないので、非常に危険です。また、パッケージを展開する順番には注意を払ってください (つまり、依存パッケージを先に展開してください)。[https://bbs.archlinux.org/viewtopic.php?id=95007 このフォーラムの投稿]には、''pacman'' のいくつかの依存関係だけが壊れてしまった場合のこの手順の例が書かれてあります。

=== 再起動後に "Unable to find root device" エラー ===

[[カーネル]]の更新中に [[initramfs]] が破損してしまった可能性が高いです (''pacman'' の {{ic|--overwrite}} オプションを不適切に使用すると、起こることがあります)。この状況から抜け出す方法は2つあります。1つ目は、''fallback'' エントリです。

{{Tip|''Fallback'' エントリを削除してしまった場合、ブートローダのパラメータを変えれば ''Fallback'' イメージを起動できます。ブートローダのメニューが表示されたときに、Syslinux の場合は {{ic|Tab}} を、GRUB と systemd-boot の場合は {{ic|e}} を押してエントリの編集画面を開き、''initramfs'' イメージ名を {{ic|initramfs-linux-fallback.img}} に変更して {{ic|Enter}} か {{ic|b}} (キーは[[ブートローダー]]に依ります) を押してください。}}

システムが起動したら、コンソールかターミナルから以下のコマンドを実行して initramfs イメージを再ビルドしてください (以下のコマンドは標準の {{Pkg|linux}} カーネルの場合です):

# mkinitcpio -p linux

これでうまく行かなかった場合、最新の Arch リリース (CD/DVD あるいは USB スティック) を起動し、ルートパーティションとブートパーティションをそれぞれ {{ic|/mnt}} と {{ic|/mnt/boot}} に[[マウント]]してください。そして、''arch-chroot'' を使ってルートパーティションに [[chroot]] してください:

# arch-chroot /mnt
# pacman -Syu mkinitcpio systemd linux

{{Note|
* 最新の Arch リリースを持っていない場合や、Arch 以外の "ライブ" Linux ディストリビューションしかない場合、昔ながらの方法で [[chroot]] することができます。当然、{{ic|arch-chroot}} スクリプトを実行する場合よりも、たくさん入力しなければなりません。
* ''pacman'' が {{ic|Could not resolve host}} というエラーで失敗してしまう場合、[[ネットワーク設定#接続の確認|インターネット接続を確認してください]]。
* パッケージを再インストールする必要があるが、arch-chroot や chroot の環境に入れない場合、コマンド {{ic|pacman --sysroot /mnt -Syu foo bar}} を使えば、別のルートパーティションから ''pacman'' を使うことができます。
}}

カーネル ({{Pkg|linux}} パッケージ) を再インストールすれば、{{ic|mkinitcpio -p linux}} が実行されて initramfs イメージが再生成されます。イメージの再生成を別途行う必要はありません。

その後、{{ic|exit}}、{{ic|umount /mnt/{boot,} }}、そして {{ic|reboot}} を実行することが推奨されます。

=== "Warning: current locale is invalid; using default "C" locale" エラー ===

このエラーメッセージが言っている通り、ロケールが正しく設定されていません。[[ロケール]]の記事を参照してください。

=== Pacman がプロキシの設定に従わない ===

関連する環境変数 ({{ic|$http_proxy}}、{{ic|$ftp_proxy}} など) が設定されていることを確認してください。''pacman'' を [[sudo]] で実行する場合、[[sudo#環境変数|環境変数を pacman に渡す]]ように sudo を設定する必要があります。また、[[GnuPG#鍵サーバー|dirmngr]] の設定ファイル {{ic|/etc/pacman.d/gnupg/dirmngr.conf}} で、鍵をリフレッシュする際にプロキシの設定に従うようにする {{ic|honor-http-proxy}} オプションが存在していることも確認してください。

=== パッケージが明示的にインストールされたか依存関係としてインストールされたかの情報を保持しつつ、全パッケージを再インストールするには? ===

ネイティブなパッケージ (つまり、同期データベース内に存在するパッケージ) を全て再インストールするには、{{ic|pacman -Qnq {{!}} pacman -S -}} か {{ic|pacman -S $(pacman -Qnq)}} を実行してください ({{ic|-S}} オプションはデフォルトでインストール理由を維持します)。

次に、外部のパッケージを全て再インストールする必要があります。これらのパッケージの一覧は {{ic|pacman -Qmq}} で得られます。

=== "Cannot open shared object file" エラー ===

どうやら、以前の ''pacman'' トランザクションで、''pacman'' 自体が必要とする共有ライブラリが削除されたか破損したようです。

この問題を解決するには、必要なライブラリをファイルシステム上に手動で展開する必要があります。まず、必要なライブラリを含むパッケージを調べ、''pacman'' キャッシュ ({{ic|/var/cache/pacman/pkg/}}) からそのパッケージを見つけてください。そして、その共有ライブラリをファイルシステム上へ展開してください。これで ''pacman'' が実行できるようになりました。

その後、壊れたパッケージを[[#特定のパッケージのインストール|再インストール]]する必要があります。注意点として、システムファイルがファイルシステム上に展開されたことを ''pacman'' は知らないため、{{ic|--overwrite}} フラグを使用する必要があります。Pacman は、先程の共有ライブラリファイルをパッケージのものに適切に置き換えてくれます。

やるべきことは以上です。あとはシステムの残りも更新してください。

===パッケージのダウンロード時にフリーズする===

''pacman'' がリポジトリのアップデートや同期をできないというネットワークの問題がいくつか報告されています [https://bbs.archlinux.org/viewtopic.php?id=68944] [https://bbs.archlinux.org/viewtopic.php?id=65728]。Arch Linux のインストール時にこの問題が発生する場合、''pacman'' のデフォルトのファイルダウンローダを置き換えることで解決します (詳しくは [[pacman のパフォーマンスの向上]]を参照)。[[VirtualBox]] で Arch Linux をゲスト OS としてインストールする時にこの問題が起こる場合、マシンのプロパティで ''NAT'' の代わりに ''Host interface'' を使うことで解決します。

=== Failed retrieving file 'core.db' from mirror ===

[[ミラー]]を正しく設定しているにも関わらずこのエラーが発生する場合、別の[[Resolv.conf|ネームサーバー]]を設定してみてください。

=== error: 'local-package.pkg.tar': permission denied ===

{{ic|pacman -U}} を使用して sshfs のマウントポイント上にパッケージをインストールしようとしてこのエラーが発生する場合、インストールしたいパッケージをローカルのディレクトリに移動し、もう一度インストールしてみてください。

=== error: could not determine cachedir mount point /var/cache/pacman/pkg ===

Chroot 環境内で {{ic|pacman -Syu}} などを実行した際に以下のエラーが発生する場合:

エラー: キャッシュディレクトリ /var/cache/pacman/pkg のマウントポイントを決定できませんでした
エラー: 処理を完了できませんでした (空き容量が足りません)

このエラーのよくある原因は、chroot したディレクトリがマウントポイントでないことです。解決策は、[[既存の Linux からインストール#基本ツールをダウンロード]] に書かれてあるノートを見てください。また、{{man|8|arch-chroot}} には、バインとマウントを使って chroot ディレクトリをマウントポイント化する方法について例と共に説明されています。

=== error: GPGME error: No data ===

パッケージを更新できず、このエラーが発生する場合は、更新する前に {{ic|rm -r /var/lib/pacman/sync/}} を実行してみてください。

Sync ファイルを削除しても問題が解決しない場合は、更新する前に {{ic|file /var/lib/pacman/sync/*}} を実行して sync ファイルが {{ic|gzip compressed data}} であることを確認してください。ルーターかプロキシが、ダウンロードしたデータを破損させているのかもしれません。

Sync ファイルが正しい種類であった場合、ミラーサーバー側に問題があるのかもしれません。{{ic|pacman-conf -r core}} と {{ic|pacman-conf -r extra}} でミラーサーバーを確認してください。表示された URL の一番最初のものをブラうさの URL 欄にペーストし、ファイルの一覧が表示されるか確かめてください。ミラーがエラーを返した場合、{{ic|/etc/pacman.d/mirrorlist}} 内のそのミラーをコメントアウトしてください。

=== 壊れている、または同期されていないパッケージを再インストールする ===

{{ic|pacman -Qk $pkg}} コマンドを使えば、{{ic|$pkg}} パッケージのインストールされたファイルがデータベースのバージョンに含まれているファイルと一致するかどうかを確認することができます。複数のパッケージに対しては、以下のようなループを使うことで、存在しないファイルがあるパッケージを再インストールすることができます:

$ LC_ALL=C.UTF-8 pacman -Qk 2>/dev/null | grep -v ' 0 missing files' | cut -d: -f1 |
while read -r package; do
pacman -S "$package" --noconfirm
done

(部分的なダウングレードなどにより) {{ic|/var/lib/pacman}} のローカルデータベースが {{ic|/}} ファイルシステムにインストールされているパッケージよりも新しい場合、これはルートファイルシステムをローカルデータベースと再同期させる最適な方法です。

== 参照 ==

* {{man|3|libalpm}}
* {{man|8|pacman}}
* {{man|5|pacman.conf}}
* {{man|8|repo-add}}

{{TranslationStatus|pacman|2024-09-15|816454}}

Advanced Linux Sound Architecture

2025-04-04T07:13:44Z

Oech3: Warningの一部を翻訳して追加,文章の順番/* ハードウェアを直接割り当てる */

[[Category:サウンド]]
[[cs:Advanced Linux Sound Architecture]]
[[de:Alsa]]
[[en:Advanced Linux Sound Architecture]]
[[es:Advanced Linux Sound Architecture]]
[[fa:ALSA]]
[[fr:Alsa]]
[[he:Advanced Linux Sound Architecture]]
[[it:Advanced Linux Sound Architecture]]
[[nl:Advanced Linux Sound Architecture]]
[[pt:Advanced Linux Sound Architecture]]
[[ru:Advanced Linux Sound Architecture]]
[[sk:Advanced Linux Sound Architecture]]
[[th:Advanced Linux Sound Architecture]]
[[tr:Gelişmiş_ses_mimarisi_(ALSA)]]
[[zh-hans:Advanced Linux Sound Architecture]]
{{Related articles start}}
{{Related|Advanced Linux Sound Architecture/設定例}}
{{Related|Advanced Linux Sound Architecture/トラブルシューティング}}
{{Related|サウンドシステム}}
{{Related|PC スピーカーのビープ音の無効化}}
{{Related|PulseAudio}}
{{Related|Open Sound System}}
{{Related articles end}}
[[Wikipedia:ja:Advanced Linux Sound Architecture|Advanced Linux Sound Architecture]] ('''ALSA''') は、サウンドカードのデバイスドライバを提供する Open Sound System (OSSv3) を置き換えるために開発された Linux カーネルコンポーネントです。デバイスドライバの他に、'''ALSA''' は、カーネルドライバと直接やりとりせずに高レベルの API を使ってドライバ機能を使いたいという開発者のために、ユーザ空間のライブラリも提供しています。

==インストール==

ALSA はデフォルトの Arch カーネルにモジュールセットとして含まれているので、インストールは不要です。

起動時に自動で [[udev]] があなたのハードウェアを調べて、オーディオカード用の適切なカーネルモジュールをロードします。したがって、サウンドはすでに鳴らせるはずです。ただ、デフォルトでは全てのチャンネルはミュートにされています。[[#チャンネルのミュートを解除する|チャンネルのミュートを解除]]してください。

=== ユーザー権限 ===

通常、ローカルユーザーは音楽を再生したり、ミキサーレベルを変更する権限があります。

リモートユーザーが ALSA を使用できるようにするには、ユーザーを {{ic|audio}} グループに[[ユーザーとグループ#グループ管理|追加]]する必要があります。

{{Note|1={{ic|audio}} グループに含まれているユーザーは直接デバイスにアクセスできるので、アプリケーションから排他的にアウトプットしたり（ソフトウェアミキシングが破壊されます）、高速ユーザー切り替えや multiseat を破壊してしまうおそれがあります。よって、特に必要がないのならばユーザーを {{ic|audio}} グループに追加することは'''推奨されません'''[https://wiki.ubuntu.com/Audio/TheAudioGroup]。}}

===ALSA ユーティリティ===

{{Pkg|alsa-utils}} パッケージを[[インストール]]してください、サウンドデバイスをコンソールや端末から設定するための {{ic|alsamixer}} ユーザー空間ツールが含まれています。また、[[#高品質なリサンプリング|高品質なリサンプリング]]や[[#アップ・ダウンミキシング|アップ・ダウンミキシング]]などの高度な機能を使いたい場合は {{Pkg|alsa-plugins}} パッケージをインストールしてください。

===OSS との互換性===

{{Note|{{ic|/dev/dsp}} や {{ic|/dev/snd/seq}} が存在しないとアプリケーションがエラーを吐く場合は以下の設定が必要です。}}

ALSA には [[OSS]] のコールに介入して ALSA を使うようにさせる機能があります。このエミュレーションレイヤーは {{ic|/dev/dsp}} を開いて音声データを直接書き込むような古いアプリケーションで有用です。OSS やエミュレーションライブラリがないと、{{ic|/dev/dsp}} が見つからずにアプリケーションは音声を鳴らすことができません。

OSS アプリケーションに dmix (ソフトウェアミキシング) を扱わせたい場合は {{Pkg|alsa-oss}} パッケージをインストールして {{ic|snd-seq-oss}}, {{ic|snd-pcm-oss}}, {{ic|snd-mixer-oss}} [[カーネルモジュール]]をロードして OSS エミュレーションモジュールを有効にしてください。

=== PulseAudio との互換性 ===

{{AUR|apulse}} を使うことで [[PulseAudio]] にしか対応していないアプリケーションで ALSA を利用することができます。使用方法は {{ic|$ apulse ''yourapplication''}} とアプリケーションを起動するだけです。

===ALSA と systemd===
{{pkg|alsa-utils}} パッケージには、それぞれ起動時とシャットダウン時に動くように設定された {{ic|alsa-restore.service}} と {{ic|alsa-state.service}} が含まれています。

自動的にインストールされ有効化されるため、特に設定は必要ありません。{{ic|systemctl}} を使うことでステータスを確認できます。

{{Note|1=ALSA は設定を {{ic|/var/lib/alsa/asound.state}} に保存します。}}

=== ALSA ファームウェア ===

{{Pkg|alsa-firmware}} パッケージには特定のサウンドカードを使うのに必要なファームウェアが含まれています (例: Creative SB0400 Audigy2)。

==チャンネルのミュートを解除する==

現在のバージョンでは ALSA をインストールしたあと全てのチャンネルは'''デフォルトでミュートされています'''。手動でチャンネルをアンミュートする必要があります。

===amixer を使ってミュートを解除===

コマンドラインで {{ic|amixer}} を使うことでサウンドカードのマスターボリュームのミュートを解除できます:

$ amixer sset Master unmute

===alsamixer を使ってミュートを解除===

{{ic|alsamixer}} ncurses UI を使えば簡単にミュートを解除できます:

$ alsamixer

{{ic|alsamixer}} の、チャンネルの下の {{ic|MM}} ラベルはそのチャンネルがミュートになっていることを示しています。{{ic|00}} はミュートが解除されていることを示しています。

{{ic|←}} や {{ic|→}} キーを押して {{ic|Master}} や {{ic|PCM}} チャンネルに移動して {{ic|m}} キーを押してミュートを解除してください。{{ic|↑}} キーを押してボリュームを上げて値を {{ic|0}} dB ゲインにしてください。ゲインは左上の {{ic|項目:}} の隣に表示されます。

{{Note|ゲインを大きくしすぎると音にノイズが混じります。}}

=== 5.1/7.1 サウンドのミュートの解除 ===

5.1 または 7.1 サラウンドを鳴らしたいときは Front, Surround, Center, LFE (サブウーファー), Side などの他のチャンネルも同じようにミュートを解除してください（これらのチャンネル名は Intel HD Audio のものです、チャンネル名はハードウェアによって変わっているかもしれません）。

{{Note|ミュートを解除しただけではステレオ音源は自動でアップミキシングされません。[[#アップ・ダウンミキシング]] を見て下さい。}}

=== マイクの有効化 ===

マイクロフォンを有効にするには、Capture タブに {{ic|F4}} で切り替えてチャンネルを {{ic|Space}} で有効にしてください。マイクが使えない時は [[Advanced Linux Sound Architecture/トラブルシューティング#マイクロフォン]] を見て下さい。

=== テスト ===

次に、音が鳴るかテストしてみましょう:

$ speaker-test -c 2

{{ic|-c}} はスピーカーによって変えて下さい。例えば 7.1 では {{ic|-c 8}} を使います:

$ speaker-test -c 8

間違ったデバイスから音が出力される場合、{{ic|-D}} 引数を使って手動でデバイスを指定してみてください:

$ speaker-test -D default:PCH -c 8

{{ic|-D}} では PCM チャンネルの名前を値として指定できます。以下のコマンドで確認することができます:

{{hc|<nowiki>$ aplay -L | grep :CARD</nowiki>|2=
default:CARD=PCH # 'default:PCH' is the PCM channel name for -D
sysdefault:CARD=PCH
front:CARD=PCH,DEV=0
surround21:CARD=PCH,DEV=0
surround40:CARD=PCH,DEV=0
surround41:CARD=PCH,DEV=0
surround50:CARD=PCH,DEV=0
surround51:CARD=PCH,DEV=0
surround71:CARD=PCH,DEV=0
}}

音が出ない場合、[[#設定]]や [[Advanced Linux Sound Architecture/トラブルシューティング]]に進んで問題を解決してください。

===ノート===

* カードによってはアナログサウンドを聞くためにはデジタル出力をミュートする必要があります。Soundblaster Audigy LS では IEC958 チャンネルをミュートしてください。
* マシンによっては (Thinkpad T61 など)、Speaker チャンネルのミュートを解除する必要があります。
* マシンによっては (Dell E6400 など)、同じく {{ic|Front}} や {{ic|Headphone}} チャンネルのミュートを解除する必要があります。
* 再起動するとボリューム調整が元に戻ってしまう場合、root で alsamixer を実行してみて下さい。

==設定==

システムの設定ファイルは {{ic|/etc/asound.conf}} で、ユーザー別の設定ファイルは {{ic|~/.asoundrc}} です。

===デフォルトサウンドカードの設定===

起動毎にサウンドカードの順番が変わってしまうときは、{{ic|/etc/modprobe.d}} 内の {{ic|.conf}} で終わるファイル (例: {{ic|/etc/modprobe.d/alsa-base.conf}}) に順番を明記することができます。
例えば、mia サウンドカードを #0 にしたい場合は:

{{hc|/etc/modprobe.d/alsa-base.conf|2=<nowiki>
options snd slots=snd_mia,snd_hda_intel
options snd_mia index=0
options snd_hda_intel index=1
</nowiki>}}

{{ic|<nowiki>$ cat /proc/asound/modules</nowiki>}} を使ってロードされているサウンドモジュールとその順番を取得してください。{{ic|<nowiki>$ lsmod | grep snd</nowiki>}} を使ってデバイス・モジュールのリストを取得してください。この設定では {{ic|snd_mia}} を使うサウンドカードと {{ic|snd_hda_intel}} を使うサウンドカード (例: オンボード) を一枚づつ挿していると仮定しています。

index を {{ic|-2}} にすることで ALSA にカードを優先的に使わせないようにすることも可能です。Linux Mint や Ubuntu などのディストリビューションでは以下の設定を使うことで USB やその他の"一般的でない"ドライバに index {{ic|0}} を与えないようにしています:

{{hc|/etc/modprobe.d/alsa-base.conf|2=
options bt87x index=-2
options cx88_alsa index=-2
options saa7134-alsa index=-2
options snd-atiixp-modem index=-2
options snd-intel8x0m index=-2
options snd-via82xx-modem index=-2
options snd-usb-audio index=-2
options snd-usb-caiaq index=-2
options snd-usb-ua101 index=-2
options snd-usb-us122l index=-2
options snd-usb-usx2y index=-2
options snd-pcsp index=-2
options snd-usb-audio index=-2
}}

変更を反映させるには再起動する必要があります。

==== 環境変数を使ってデフォルト PCM を選択する ====

設定ファイルで、以下を追加してください:
pcm.!default {
type plug
slave.pcm {
@func getenv
vars [ ALSAPCM ]
default "hw:Audigy2"
}
}

default の行はあなたのカードの名前に置き換える必要があります (ここでは {{ic|Audigy2}} を例にしています)。{{ic|aplay -l}} で名前を取得することができ '''surround51''' のように PCM を使うことも可能です。ただしマイクロフォンを使う必要がある場合は full-duplex PCM をデフォルトにすると良いでしょう。

これで環境変数 {{ic|ALSAPCM}} を変更することでサウンドカードを選択できるようになります。カードを選択できない全てのプログラムで問題なく使えます。
例えば、'''mix51to20''' という名前の downmix PCM を書いたときは {{ic|mplayer}} を {{ic|ALSAPCM=mix51to20 mplayer example_6_channel.wav}} で使うことができます。

==== ハードウェアを直接割り当てる ====

{{Warning|この設定では他のアプリケーションからデバイスが使用不可能になります。この方法は、デジタル出力や音楽サーバーに捧げる場合など、わざとそうした場合にのみ推奨されます。サウンドサーバーや[[Advanced_Linux_Sound_Architecture#ミキシング|ミキシング]]無しの設定は[[Chromium]]等の幾つかのアプリケーションでサポートされていません。}}

まずデフォルトに設定したいカード・デバイスの id を {{ic|aplay -l}} で見つける必要があります:

{{hc|$ aplay -l|2=
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: CONEXANT Analog [CONEXANT Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: Conexant Digital [Conexant Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: JamLab [JamLab], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: Audio [Altec Lansing XT1 - USB Audio], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
}}

例えば、このリストの最後のエントリはカード ID 2,カード名 Audio でデバイス ID 0 です。このカードをデフォルトにするには、システム全体のファイル {{ic|/etc/asound.conf}} かユーザー定義ファイル {{ic|~/.asoundrc}} のどちらかを使ってください。ファイルが存在しないときは作成する必要があります。そして以下のオプションを適切なカード・デバイス id を使って挿入して下さい。

{{bc|
pcm.!default {
type hw
card Audio #又はcard 2
}

ctl.!default {
type hw
card Audio
}

pcm.dmixer {
type dmix
ipc_key 2048
slave {
pcm "hw:Audio"
}
}
}}

カードIDではなくカード名の使用をおすすめします。デバイスの順番に依存しないためです。

{{ic|pcm.dmixer}}は[[Advanced_Linux_Sound_Architecture#ミキシング|ミキシング]]が必要なアプリケーションの為の予備です。
{{Accuracy|General method to select alsa device should be introduced such as environment value.}}
例えば、{{ic|1=chromium -alsa-output-device=pcm.dmixer}}でChromiumがミキシングを使えるようになります。

{{Note|Asus U32U シリーズではカードの pcm と ctl の両方を 1 に設定する必要があります。}}

'pcm' オプションは音声の再生で使われるカード・デバイスに影響を与え、'ctl' オプションは alsamixer などのコントロールユーティリティで使われるカードに影響を与えます。

アプリケーション (mplayer など) を（再）起動すれば変更はすぐ適用されます。また、''aplay'' などのコマンドを使ってテストすることが可能です。

$ aplay -D default:PCH ''your_favourite_sound.wav''

asound 設定に関するエラーが表示される場合は、[http://www.alsa-project.org/main/index.php/Asoundrc#The_default_plugin 上流のドキュメント] を確認して設定ファイルフォーマットの変更を確認してください。

===サウンドモジュールがロードされていることを確かめる===

udev が正しくサウンドカードを検知しているかチェックするには次のコマンドを実行してください:

{{hc|<nowiki>$ lsmod | grep '^snd' | column -t</nowiki>|<nowiki>
snd_hda_codec_hdmi 22378 4
snd_hda_codec_realtek 294191 1
snd_hda_intel 21738 1
snd_hda_codec 73739 3 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel
snd_hwdep 6134 1 snd_hda_codec
snd_pcm 71032 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_timer 18992 1 snd_pcm
snd 55132 9 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer
snd_page_alloc 7017 2 snd_hda_intel,snd_pcm
</nowiki>}}

出力が上と同じようになっていれば、サウンドドライバが首尾よく自動検出されています。
{{Note|{{ic|udev>=171}} から、OSS エミュレーションモジュール ({{ic|snd_seq_oss, snd_pcm_oss, snd_mixer_oss}}) はデフォルトではロードされないようになりました: 必要ならば[[カーネルモジュール#ロード|手動でロードしてください]]。}}

{{ic|/dev/snd/}} ディレクトリにデバイスファイルがあるか調べてもいいかもしれません:

{{hc|$ ls -l /dev/snd|2=<nowiki>
total 0
crw-rw---- 1 root audio 116, 0 Apr 8 14:17 controlC0
crw-rw---- 1 root audio 116, 32 Apr 8 14:17 controlC1
crw-rw---- 1 root audio 116, 24 Apr 8 14:17 pcmC0D0c
crw-rw---- 1 root audio 116, 16 Apr 8 14:17 pcmC0D0p
crw-rw---- 1 root audio 116, 25 Apr 8 14:17 pcmC0D1c
crw-rw---- 1 root audio 116, 56 Apr 8 14:17 pcmC1D0c
crw-rw---- 1 root audio 116, 48 Apr 8 14:17 pcmC1D0p
crw-rw---- 1 root audio 116, 1 Apr 8 14:17 seq
crw-rw---- 1 root audio 116, 33 Apr 8 14:17 timer
</nowiki>}}

{{Note|IRC やフォーラムで助けを求める時は、上記のコマンドの出力を貼って下さい。}}

とにかく '''controlC0''' や '''pcmC0D0p''' のようなデバイスがあれば、サウンドモジュールが正しくロードされていることを示しています。

そうなってないのなら、あなたのサウンドモジュールは正しく検出されていません。これを解決するには、手動でモジュールのロードを試して下さい:

* サウンドカードのモジュールを確認します: [http://www.alsa-project.org/main/index.php/Matrix:Main ALSA Soundcard Matrix] モジュールには名前の前に 'snd-' が付きます (例: {{ic|snd-via82xx}})。
* [[カーネルモジュール#ロード|モジュールをロードします]]。
* {{ic|/dev/snd}} の中のデバイスファイルを確認したり（上述）、{{ic|alsamixer}} や {{ic|amixer}} に変化がないか調べて下さい。
* {{ic|snd-NAME-OF-MODULE}} と {{ic|snd-pcm-oss}} を[[カーネルモジュール#ロード|起動時にロード]]するよう設定して下さい。

===S/PDIF 出力===

[[wikipedia:ja:S/PDIF|S/PDIF]] はコンピュータとオーディオアンプを接続するときにしばしば使われるデジタルオーディオインターフェイスです (5.1/7.1 サラウンドのホームシアターなど)。
{{note|サウンドカードによっては以下の瀬底でアナログ出力が無効になることがあります (例: Sound Blaster Audigy 2)。}}
使用している[[シェル]]にあわせて、シェルの設定ファイルに以下の行を追加してください:
amixer -c 0 cset name='IEC958 Playback Switch' on

カードのデジタル出力の名前は以下のコマンドで確認できます:
$ amixer scontrols

===イコライザー===

====AlsaEqual を使う (UI あり)====

{{AUR|alsaequal}} パッケージをインストールしてください。

パッケージをインストールした後、以下を ALSA 設定ファイル ({{ic|~/.asoundrc}} か {{ic|/etc/asound.conf}}) に挿入してください:

ctl.equal {
type equal;
}

pcm.plugequal {
type equal;
# Modify the line below if you do not
# want to use sound card 0.
#slave.pcm "plughw:0,0";
#by default we want to play from more sources at time:
slave.pcm "plug:dmix";
}
#pcm.equal {
# If you do not want the equalizer to be your
# default soundcard comment the following
# line and uncomment the above line. (You can
# choose it as the output device by addressing
# it with specific apps,eg mpg123 -a equal 06.Back_In_Black.mp3)
pcm.!default {
type plug;
slave.pcm plugequal;
}

x86_64 環境で {{Pkg|lib32-flashplugin}}{{Broken package link|{{aur-mirror|lib32-flashplugin}}}} を使用している場合、上記の設定では flash で音が鳴りません。以下の設定で flash の音を有効にできますが、{{ic|pcm "hw:0,0"}} の行でサウンドカードを手動で指定する必要があります (利用可能なサウンドカードとカードのデバイス番号は {{ic|aplay -l}} で確認できます):

{{hc|/etc/asound.conf|2=
pcm.dmixer {
type dmix
ipc_key 2048
slave {
pcm "hw:0,0"
buffer_size 16384
}
}

ctl.equal {
type equal;
}

pcm.equalizer {
type equal
slave.pcm "plug:dmixer"
}

pcm.!default {
type plug
slave.pcm equalizer
}
}}

次のコマンドを使ってイコライザーを変更することができます:
$ alsamixer -D equal

設定ファイルはユーザーごとに違うので注意してください。{{ic|~/.alsaequal.bin}}　に保存されます。
AlsaEqual を異なるユーザーの [[Music Player Daemon|mpd]] などのソフトウェアで使いたいときは、次を実行することで設定できます:
# su mpd -c 'alsamixer -D equal'
もしくは、ユーザーの home にある {{ic|.alsaequal.bin}} のシンボリックリンクを作って下さい。

=====AlsaEqual の管理=====

{{AUR|alsaequal-mgr}} パッケージをインストールしてください。

通常通りイコライザーを設定してください:
$ alsamixer -D equal

状態に満足したら、名前を付けて保存してください (例: "foo"):
$ alsaequal-mgr save foo

イコライザーの状態 "foo" は次のコマンドで戻すことができます:
$ alsaequal-mgr load foo

ゲームや映画、音楽のジャンル別、VoIP アプリなどそれぞれに合わせてイコライザーの状態を作成し、必要なときにリロードできます。

オプションの詳細は [https://xyne.archlinux.ca/projects/alsaequal-mgr/ project page] を見て下さい。

====mbeq を使う====

{{Note|この方法では ladspa プラグインを使う必要があります。サウンドを再生する際に CPU の使用量が多めです。さらに、ステレオサウンドを念頭に置いて作成されています (例: ヘッドフォン)。}}

{{Pkg|alsa-plugins}}, {{Pkg|ladspa}}, {{Pkg|swh-plugins}} パッケージをインストールしてください。

まだ {{ic|~/.asoundrc}} か {{ic|/etc/asound.conf}} ファイルを作成していない場合は、どちらかを作成して以下を挿入して下さい:

{{hc|/etc/asound.conf|2=<nowiki>pcm.eq {
type ladspa

# The output from the EQ can either go direct to a hardware device
# (if you have a hardware mixer, e.g. SBLive/Audigy) or it can go
# to the software mixer shown here.
#slave.pcm "plughw:0,0"
slave.pcm "plug:dmix"

# Sometimes you may need to specify the path to the plugins,
# especially if you have just installed them. Once you have logged
# out/restarted this should not be necessary, but if you get errors
# about being unable to find plugins, try uncommenting this.
#path "/usr/lib/ladspa"

plugins [
{
label mbeq
id 1197
input {
#this setting is here by example, edit to your own taste
#bands: 50hz, 100hz, 156hz, 220hz, 311hz, 440hz, 622hz, 880hz, 1250hz, 1750hz, 25000hz,
#50000hz, 10000hz, 20000hz
controls [ -5 -5 -5 -5 -5 -10 -20 -15 -10 -10 -10 -10 -10 -3 -2 ]
}
}
]
}

# Redirect the default device to go via the EQ - you may want to do
# this last, once you are sure everything is working. Otherwise all
# your audio programs will break/crash if something has gone wrong.

pcm.!default {
type plug
slave.pcm "eq"
}

# Redirect the OSS emulation through the EQ too (when programs are running through "aoss")

pcm.dsp0 {
type plug
slave.pcm "eq"
}
</nowiki>}}

==高品質なリサンプリング==

ソフトウェアミキシングが有効になっていると、ALSA は全てを同じ周波数 (デフォルトで 48000) にリサンプリングします。dmix はサウンドの品質を落としてしまう低品質リサンプリングアルゴリズムを使っています。

{{pkg|alsa-plugins}} と {{pkg|libsamplerate}} をインストールして下さい。

デフォルトの変換器を libsamplerate に変更します:

{{hc|/etc/asound.conf|defaults.pcm.rate_converter "samplerate_best"}}

または:

{{hc|~/.asoundrc|defaults.pcm.rate_converter "samplerate_best"}}

'''samplerate_best''' は最高のサウンド品質を提供しますが、リアルタイムサンプリングをするには CPU サイクルが大量に必要になるので使うにはそこそこの CPU が必須です。また、dmix の設定で buffer_size を基本の 4096 から 8192 か 16384 に調整する必要もあるかもしれません。他のアルゴリズム ('''samplerate''' など) も利用できますがデフォルトのリサンプラーに比べておそらくあまり改善はないでしょう。

{{Warning|環境によっては、samplerate_best を有効にすると flashplayer でサウンドが出力されなくなるという問題が発生します。}}

==アップ・ダウンミキシング==

===アップミキシング===

音楽などのステレオ音源を 5.1 や 7.1 サウンドシステムをフルに使って再生するには、アップミキシングを使う必要があります。黎明期ではこれをするのはとても難しいものでした。ですが現在では簡単にアップミキシングができるプラグインがあります。{{Pkg|alsa-plugins}} に含まれている {{ic|upmix}} プラグインを使います。

それから以下を ALSA 設定ファイル ({{ic|/etc/asound.conf}} か {{ic|~/.asoundrc}}) に追加してください:
pcm.upmix71 {
type upmix
slave.pcm "surround71"
delay 15
channels 8
}

上の例は 7.1 のものですが 5.1 や 4.0 にも簡単に変えられます。

設定をするとアップミキシングに使う新しい pcm が加わります。全てのサウンド音源をこの pcm に通したい時は、次のようにデフォルトとして追加してください:

pcm.!default "plug:upmix71"

このプラグインは使うにあたって特に設定を変える必要はありません。
プラグインが動作しないときは、以下のようにしてアップミキシングする PCM のための dmixer を自分で設定してください:
pcm.dmix6 {
type asym
playback.pcm {
type dmix
ipc_key 567829
slave {
pcm "hw:0,0"
channels 6
}
}
}

そして "surround71" のかわりに "dmix6" を使って下さい。
音がスキップしたり歪むときは、buffer_size を増やす (例: 32768) か [[#高品質なリサンプリング|高品質リサンプラー]]を使ってください。

===ダウンミキシング===
5.1 サウンドの映画をステレオシステムで視聴するときなど、音源をステレオにダウンミキシングしたい場合、{{Pkg|alsa-plugins}} に含まれている {{ic|vdownmix}} プラグインを使って下さい。

設定ファイルに以下を追加して下さい:

pcm.!surround51 {
type vdownmix
slave.pcm "default"
}
pcm.!surround40 {
type vdownmix
slave.pcm "default"
}

{{Note|1=これだけではダウンミキシングが動作しないかもしれません、[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541786] を参照してください。その場合、{{ic|pcm.!default "plug:surround51"}} か {{ic|pcm.!default "plug:surround40"}} を追加する必要があります。{{ic|vdownmix}} プラグはひとつだけ使うことができます; 7.1 チャンネルのときは、上の設定の代わりに {{ic|surround71}} を使って下さい。{{ic|vdownmix}} と {{ic|dmix}} の両方を動かす設定例が[https://bbs.archlinux.org/viewtopic.php?id=167275 ここ]にあります。}}

==ミキシング==

ミキシングを使うことで複数のアプリケーションが同時に音を出力することが可能になります。外付けのサウンドカードはほとんどの場合ハードウェアミキシングをサポートしており、可能であればデフォルトで有効にされます。内蔵のマザーボードに載っているサウンドカード (Intel HD Audio など) は基本的にハードウェアミキシングをサポートしていません。そのようなカードでは、dmix という名前の ALSA プラグインを使ってソフトウェアミキシングを利用します。この機能はハードウェアミキシングが使えない場合に自動で有効にされます。

===手動で dmix を有効にする===

{{Note|ALSA 1.0.9rc2 以上ではアナログサウンドに dmix を設定する必要はありません。ハードウェアミキシングをサポートしていないサウンドカードのために Dmix はデフォルトで有効にされています。}}

ソフトウェアミキシングが動作しない場合は、あなたの home フォルダに以下の内容で .asoundrc ファイルを作成してください。

pcm.dsp {
type plug
slave.pcm "dmix"
}

これでソフトウェアミキシングが有効になり複数のアプリケーションがサウンドカードを使えるようになるはずです。使えない場合は、{{ic|/etc/asound.conf}} の中身を全て上のように置き換えてみて下さい。

S/PDIF などのデジタル音声出力をするために、ALSA パッケージは依然として dmix をデフォルトで有効にしていません。そのため、上の dmix 設定は S/PDIF デバイスで dmix を有効にするために使うことはできません。

一般的な問題と解決方法は [[Advanced Linux Sound Architecture/トラブルシューティング]] を見て下さい。

===ハードウェアミキシング===

====サポート====

ハードウェアでミキシングをサポートしているオーディオチップセットを持っている場合、設定は必要ありません。ほとんど全てのオンボード・オーディオチップセットはハードウェアミキシングをサポートしていないので、ソフトウェアでミキシングする必要があります（上述）。ハードウェアミキシングをサポートしているサウンドカードは少なく、Linux でサポートされているサウンドカードは以下になります:

* Creative SoundBlaster Live! (5.1 モデル)
* Creative SoundBlaster Audigy (複数)
* Creative SoundBlaster Audidy 2 (ZS モデル)
* Creative SoundBlaster Audigy 4 (Pro モデル)

{{Note|
* 上記のカードのローエンド版 (Audigy SE, Audigy 2 NX, SoundBlaster Live! 24bit, SoundBlaster Live! 7.1) は別のチップを使っているためハードウェアミキシングに対応していません。
* オンボードの VIA8237 チップは4ストリームのハードウェアミキシングに対応していますが、マザーボードによってはそれが3ストリームになったり (4番目のストリームが音を出さない) あるいは使えないこともあります。動作したとしても、他の方法と比べて音質は劣ります。}}

====フィックス====

64-bit Arch で Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02) を使っている場合、Enemy Territory でサウンドを鳴らすには以下を実行して下さい:
echo "et.x86 0 0 direct" > /proc/asound/card0/pcm0p/oss
echo "et.x86 0 0 disable" > /proc/asound/card0/pcm0c/oss

== ヒントとテクニック ==

=== USB サウンドカードのホットプラグ ===

USB サウンドカードが挿入されたときに、自動的に第一のアウトプットデバイスにするために、以下の udev ルールを使うことができます (例: 以下の2行を {{ic|/etc/udev/rules.d/00-local.rules}} に追加して再起動する)。

{{bc|1=KERNEL=="pcmC[D0-9cp]*", ACTION=="add", PROGRAM="/bin/sh -c 'K=%k; K=$${K#pcmC}; K=$${K%%D*}; echo defaults.ctl.card $$K > /etc/asound.conf; echo defaults.pcm.card $$K >>/etc/asound.conf'"
KERNEL=="pcmC[D0-9cp]*", ACTION=="remove", PROGRAM="/bin/sh -c 'echo defaults.ctl.card 0 > /etc/asound.conf; echo defaults.pcm.card 0 >>/etc/asound.conf'"}}

=== 同時出力 ===

ミニジャックで接続した外付けスピーカーと内蔵のスピーカーで同時に音楽を再生したい場合、{{ic|alsamixer}} や {{ic|amixer}} を使うことで ''Auto-Mute'' のミュートを解除してください:
$ amixer sset "Auto-Mute" unmute

そして ''Headphones''', ''Speaker'', '''Bass Speaker'' など他の必要なアイテムのミュートを解除してください。
{{Note|(ミニジャック) ヘッドフォンコネクタで接続した場合に音が割れる場合、[[Advanced Linux Sound Architecture/トラブルシューティング#ミニジャック (ヘッドフォンコネクタ) で音が割れる]]を見て下さい。}}

=== キーボードのボリュームコントロール ===

以下のコマンドをボリュームキーにマッピングしてください: {{ic|XF86AudioRaiseVolume}}, {{ic|XF86AudioLowerVolume}}, {{ic|XF86AudioMute}}

ボリュームを上げるには:
amixer set Master 5%+

ボリュームを下げるには:
amixer set Master 5%-

==トラブルシューティング==
[[Advanced Linux Sound Architecture/トラブルシューティング]]を見て下さい。

==設定例==

[[Advanced Linux Sound Architecture/設定例]]を見て下さい。

==参照==
* [http://www.alsa-project.org/ ALSA wiki]
* [http://www.alsa-project.org/main/index.php/Asoundrc Asoundrc]
* [http://alsa.opensrc.org/ 非公式 ALSA wiki]
* [https://www.mjmwired.net/kernel/Documentation/sound/alsa/ALSA-Configuration.txt 高度な ALSA モジュール設定]
* [https://bbs.archlinux.org/viewtopic.php?id=36815 HOWTO: compile driver from svn]
* [http://www.volkerschatz.com/noise/alsa.html A close look at ALSA: ALSA concept introduction]
* [http://www.sabi.co.uk/Notes/linuxSoundALSA.html Linux ALSA sound notes]

Wayland

2025-04-03T17:07:45Z

Oech3: waypipeをPkgに変更/* リモートディスプレイ */

[[Category:グラフィカルユーザーインターフェイス]]
[[en:Wayland]]
[[es:Wayland]]
[[pt:Wayland]]
[[ru:Wayland]]
[[zh-hans:Wayland]]
{{Related articles start}}
{{Related|カーネルモード設定}}
{{Related|Xorg}}
{{Related|スクリーンショットの取得#Wayland}}
{{Related articles end}}

[https://wayland.freedesktop.org/ Wayland] はディスプレイサーバープロトコルです。[[Xorg|X Window System]] の後継となることを目指しています。[[Wikipedia:Wayland_(display_server_protocol)#Differences_between_Wayland_and_X|Wikipedia に Wayland と Xorg の比較]] が掲載されています。

Wayland プロトコルを使用するディスプレイサーバは、[[Wikipedia:ja:コンポジット型ウィンドウマネージャ|コンポジット型ウィンドウマネージャ]] としても機能するため、'''コンポジタ''' と呼ばれます。以下に[[#コンポジタ|Wayland コンポジタのリスト]]を示します。

ネイティブな X11 アプリケーションをシームレスに動かすための後方互換性として、[[#Xwayland|Xwayland]] を使うことができます。これは Wayland に X サーバを提供します。

== 要件 ==

ほとんどの Wayland コンポジタは、[[カーネルモード設定]]を利用しているシステムでのみ動作します。Wayland それ自体はグラフィカルな環境を提供しません。ゆえに、Wayland に加えてコンポジタ (以下のセクションを参照)、あるいは、コンポジタを含むデスクトップ環境 (例: [[GNOME]]、[[Plasma]]) が必要となります。

GPU ドライバと Wayland コンポジタは、同一のバッファ API に対応している場合に互換性があります。主要な API は2つ存在します: [[Wikipedia:Generic Buffer Management|GBM]] と [https://www.phoronix.com/scan.php?page=news_item&px=XDC2016-Device-Memory-API EGLStreams] です。

{| class="wikitable"
! バッファ API !! GPU ドライバーのサポート !! Wayland コンポジタのサポート
|-
| GBM || [[NVIDIA]] < 495* 以外の全てのドライバー || 全て
|-
| EGLStreams || [[NVIDIA]] || [[GNOME]]
|}

: * Nvidia ≥ 495 は EGLStreams と GBM の両方をサポートします。[https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-495.44-Linux-Driver]

NVIDIA が GBM のサポートを導入して以来、NVIDIA ≥ 495 で多くのコンポジタ (Mutter と KWin を含む) がデフォルトで GBM を使用し始めました。GBM は一般的にベターでより幅広いサポートがあると考えられています。EGLStreams がサポートされていた理由は、NVIDIA GPU をプロプライエタリドライバで Wayland 下で使用する代替の方法を NVIDIA が提供しなかったからだけです。さらに、GBM が NVIDIA に導入された後、KWin は [https://invent.kde.org/plasma/kwin/-/merge_requests/1638 EGLStreams のサポートを打ち切りました]。

人気なデスクトップ環境/コンポジタと、NVIDIA によってまだサポートされている GPU を使用している場合、おそらくすでに GBM バックエンドを使用しています。確認するには、次を実行してください: {{ic|journalctl -b 0 --grep "renderer for"}}。GBM をバックエンドとして強制的に使用させるには、次の[[環境変数]]を設定してください:

GBM_BACKEND=nvidia-drm
__GLX_VENDOR_LIBRARY_NAME=nvidia

== コンポジタ ==

'''タイル型''', '''スタック型''', '''ダイナミック型''' の違いについては、[[ウィンドウマネージャ#種類]] を参照してください。

=== スタック型 ===

* {{App|[[Enlightenment]]|[[Enlightenment]]|[[Enlightenment#手動]] を参照してください。詳細: [https://git.enlightenment.org/enlightenment/enlightenment/src/branch/master/README.md] [https://www.enlightenment.org/about-wayland]|https://www.enlightenment.org/|{{Pkg|enlightenment}}}}
* {{App|hikari|FreeBSD で活発に開発されている [[cwm]] にインスパイアされた wlroots ベースのコンポジタ。Linux もサポートしています。|https://hikari.acmelabs.space/|{{AUR|hikari}}}}
* {{App|KDE [[w:KWin|KWin]]|[[KDE#Plasma の起動]] を参照。|https://userbase.kde.org/KWin|{{Pkg|kwin}}}}
* {{App|Liri Shell|[[Liri]] の一部、しかし、QtQuick と QtCompositor を使って Wayland 用のコンポジタとして作られています。|https://github.com/lirios/shell|{{AUR|liri-shell-git}}}}
* {{App|labwc|Openbox にインスパイアされた wlroots ベースのコンポジタ。|https://github.com/labwc/labwc|{{Pkg|labwc}}}}
* {{App|[[w:Mutter (software)|Mutter]]|[[GNOME#GNOME の起動]] を参照。|https://gitlab.gnome.org/GNOME/mutter|{{Pkg|mutter}}}}
* {{App|wayfire|[[Compiz]] にインスパイアされ、wlroots に基づく 3D コンポジタ。|https://wayfire.org/|{{AUR|wayfire}}}}
* {{App|[[Weston]]|正しさ、信頼性、予測可能性、性能のために設計された Wayland コンポジタ。|https://gitlab.freedesktop.org/wayland/weston|{{Pkg|weston}}}}
* {{App|wio|Plan 9 のリオデスクトップのルックアンドフィールを複製することを目的とする wlroots ベースのコンポジタ。|https://gitlab.com/Rubo/wio|{{AUR|wio-wl}}}}

=== タイル型 ===

* {{App|[[Cagebreak]]|cage をベースに、[[ratpoison]] にインスパイアされています。|https://github.com/project-repo/cagebreak|{{AUR|cagebreak}}}}
* {{App|niri|スクロール可能なタイル型 Wayland コンポジタ。|https://github.com/YaLTeR/niri/|{{Pkg|niri}}}}
* {{App|Polonium|[[KDE]] 6 上でタイル型ウィンドウを使用できる、Bismuth の後継。|https://github.com/zeroxoneafour/polonium|{{AUR|kwin-polonium}}}}
* {{App|[[Qtile]]|Python で記述および設定されたフル機能のハッキング可能なタイリングウィンドウマネージャーと Wayland コンポジタ。|https://github.com/qtile/qtile|{{Pkg|qtile}}}}
* {{App|[[Sway]]|wlroots ベースの [[i3]] 互換 Wayland コンポジタ。|https://github.com/swaywm/sway|{{Pkg|sway}}}}
* {{App|SwayFx|魅力的な視覚効果機能を追加した [[Sway]]。|https://github.com/WillPower3309/swayfx|{{AUR|swayfx}}}}
* {{App|Velox|swc ベースのシンプルなウィンドウマネージャです。[[dwm]] と [[xmonad]] の影響を受けています。|https://github.com/michaelforney/velox|{{AUR|velox-git}}}}

=== ダイナミック型 ===

* {{App|[[dwl]]|wlroots ベースの [[dwm]] ライクな Wayland コンポジタ。|https://codeberg.org/dwl/dwl|{{AUR|dwl}}}}
* {{App|[[Hyprland]]|見た目を犠牲にしないダイナミックなタイリング Wayland コンポジタ。|https://hyprland.org|{{Pkg|hyprland}}}}
* {{App|japokwm|wlroots ベースの、レイアウト作成を中心とした動的な Wayland タイリングコンポジタ。|https://github.com/werererer/japokwm|{{AUR|japokwm-git}}}}
* {{App|[[river]]|dwm と [[bspwm]] にインスパイアされた動的なタイル型 Wayland コンポジタ。|https://codeberg.org/river/river|{{Pkg|river}}}}
* {{App|Vivarium|wlroots を使用するダイナミックタイル型 Wayland コンポジタ。[[xmonad]] にインスパイアされたデスクトップセマンティクスを持ちます。|https://github.com/inclement/vivarium|{{AUR|vivarium-git}}}}

=== その他 ===

* {{App|Cage|キオスクのような単一のフルスクリーンアプリケーションを表示します。|https://www.hjdskes.nl/projects/cage/|{{Pkg|cage}}}}
* {{App|nwg-shell|Sway と Hyprland Wayland コンポジタのための GTK ベースシェル。|https://github.com/nwg-piotr/nwg-shell|{{Pkg|nwg-shell}}}}
* {{App|kiwmi|完全にプログラミング可能な Wayland コンポジタ。|https://github.com/buffet/kiwmi|{{AUR|kiwmi-git}}}}
* {{App|phoc|モバイル端末のための wlroots ベースの小さなコンポジタ。|https://gitlab.gnome.org/World/Phosh/phoc|{{Pkg|phoc}}}}

上記のいくつかは [[ディスプレイマネージャ]] をサポートする場合があります。
それらがどのように開始されるかを {{ic|/usr/share/wayland-sessions/''compositor''.desktop}} を見て確認してください。

== ディスプレイマネージャ ==

Wayland コンポジタの実行をサポートしている[[ディスプレイマネージャ]]は以下の表の通りです。

{| class="wikitable sortable"
! 名前
! それ自体は Wayland で動作するか?
! 説明
|-
| {{Pkg|emptty}}
| {{No}}
| TTY で動作するシンプルな CLI ディスプレイマネージャ。
|-
| [[GDM]]
| {{Yes}}
| [[GNOME]] ディスプレイマネージャ。
|-
| [[greetd]]
| {{G|Wayland の greeter を使用した場合}}
| 最小でありながら柔軟なログインデーモン。
|-
| {{Pkg|lemurs}}
| {{No}}
| Rust で書かれた TUI ディスプレイマネージャ。
|-
| [[LightDM]]
| {{No|https://github.com/canonical/lightdm/issues/267}}
| 様々なデスクトップに対応したディスプレイマネージャ。
|-
| [[Ly]]
| {{No}}
| C で書かれた TUI ディスプレイマネージャ。
|-
| [[SDDM]]
| {{Yes}}
| QML ベースのディスプレイマネージャ。
|-
| [[tbsm]]
| {{No}}
| bash のみに依存するシンプルな CLI セッションランチャー。
|-
| [[Universal_Wayland_Session_Manager|UWSM]]
| {{No}}
| Systemd のメカニズムを使用するスタンドアローンなコンポジタのための、セッションと XDG autostart のマネージャ。
|}

== Xwayland ==

[https://wayland.freedesktop.org/xserver.html Xwayland] は、Wayland の下で実行される X サーバーで、Wayland サポートをまだ提供していないネイティブな [[X11]] アプリケーションに互換性を提供します。これを使用するには、{{Pkg|xorg-xwayland}} パッケージを[[インストール]]します。

Xwayland はコンポジタを介して開始されるため、あなたの使用しているコンポジタのドキュメントを読み、Xwayland との互換性についてや、Xwayland の起動方法に関する指示を確認しておく必要があります。

{{Note|
* セキュリティ: Xwayland は X サーバーであるため、 Wayland のセキュリティ機能はありません。
* パフォーマンス: Xwayland は X11 と[https://openbenchmarking.org/result/2202053-NE-NVIDIARTX35 ほぼ同等のパフォーマンス]を発揮します。しかし、一部のケースで (特に NVIDIA カード上で) パフォーマンスの低下を感じるかもしれません。
* 互換性: Xwayland は X11 と完全な後方互換性があるわけではありません。一部のアプリケーションは Xwayland 下では正しく動作しない場合があります。}}

=== NVIDIA ドライバ ===

{{Note|バージョン 470 より前の Nvidia ドライバ(例: {{aur|nvidia-390xx-dkms}}) はハードウェア支援のある Xwayland をサポートしておらず、非 Wayland ネイティブなアプリケーションは Wayland セッションでのパフォーマンスが低下します。}}

なお、[[NVIDIA#DRM カーネルモード設定|DRM KMS]] を有効にする必要があります。また、お使いのディスプレイマネージャ(例: [[GDM#Wayland と独自の NVIDIA ドライバ|GDM]])の[https://download.nvidia.com/XFree86/Linux-x86_64/515.48.07/README/xwayland.html 公式ドキュメント]に記載されている情報も見てください。

=== Kwin Wayland デバッグコンソール ===

{{pkg|kwin}} を使用している場合、以下を実行すると、どのウィンドウが Xwayland とネイティブ Wayland を使用しているか、表面、入力イベント、クリップボードの内容などを確認することができます。

$ qdbus6 org.kde.KWin /KWin org.kde.KWin.showDebugConsole

=== Xwayland アプリケーションであることを視認する ===

アプリケーションが Xwayland 経由で実行されているかどうかを判断するには、{{AUR|extramaus}} を使用します。
アプリケーションのウィンドウ上にマウスポインタを移動して、マウスポインタが赤くなる場合は、アプリケーションが Xwayland 経由で実行されています。

または、{{pkg|xorg-xeyes}} を使用して、アプリケーションウィンドウ上でマウスポインタを移動するときに、目が動いているかどうかで確認することもできます。

他の方法として、({{Pkg|xorg-xwininfo}} の) ''xwininfo'' をターミナルウィンドウで実行するというものがあります。Xwayland ウィンドウ上にマウスポインタをホバーすると、マウスポインタが + マークに変わります。ウィンドウをクリックすると、xwininfo は情報を表示して終了しますが、ネイティブな Wayland ウィンドウでは何も起こりません。{{ic|Ctrl+C}} を押すことで xwininfo を終了できます。

あるいは、''xlsclients'' ({{Pkg|xorg-xlsclients}} パッケージ) を使用することもできます。Xwayland で動作中のアプリケーションを全てリストアップするには、{{ic|xlsclients -l}} を実行してください。

== GUI ライブラリ ==

[https://wayland.freedesktop.org/toolkits.html 公式ウェブサイト] で詳細を確認してください。

=== GTK ===

{{Pkg|gtk3}} と {{Pkg|gtk4}} パッケージは Wayland バックエンドが有効になっています。GTK ではデフォルトで Wayland バックエンドを使いますが、[[環境変数]]を設定することで Xwayland を使うように上書きできます: {{ic|1=GDK_BACKEND=x11}}。

テーマの問題は [[GTK#Wayland バックエンド]] を見てください。

=== Qt ===

[[Qt]] 5 または 6 で Wayland のサポートを有効化するには、Qt 5 と 6 に対してそれぞれ {{Pkg|qt5-wayland}} または {{Pkg|qt6-wayland}} パッケージをインストールしてください。これで、Qt アプリケーションは Wayland セッション上では Wayland で動作するようになります。

必須ではないはずですが、明示的に Wayland プラグインを使って Qt 5 アプリケーションを動作させるには、[https://wiki.qt.io/QtWayland#How_do_I_use_QtWayland.3F] にあるように、{{ic|1=-platform wayland}} を使用するか、[[環境変数]] {{ic|1=QT_QPA_PLATFORM=wayland}} をセットして下さい。

一方、Wayland セッション上で [[X11]] を使用させるには、{{ic|1=QT_QPA_PLATFORM=xcb}} と設定してください。これは、{{AUR|zoom}} など、システムの Qt の実装を使用しない一部のプロプライエタリアプリケーションで必要になる場合があります。
また、{{ic|1=QT_QPA_PLATFORM="wayland;xcb"}} を使用すると、Qt が Wayland を利用できない場合に、代わりに xcb (X11)プラグインを使用させることができます。[https://www.qt.io/blog/2018/05/29/whats-new-in-qt-5-11-for-the-wayland-platform-plugin]

[[sway]] などの一部のコンポジターでは、ネイティブに実行されている Qt アプリケーションの機能が不足している場合があります。たとえば、[https://keepassxc.org KeepassXC] はトレイに最小化できません。これは、アプリケーションを実行する前に {{Pkg|qt5ct}} をインストールし、{{ic|1=QT_QPA_PLATFORMTHEME=qt5ct}} を設定することで解決できます。

=== Clutter ===

Clutter ツールキットには Wayland バックエンドがあり、Clutter を Wayland のクライアントとして動作させることが可能です。このバックエンドは {{Pkg|clutter}} パッケージで有効になっています。

Clutter アプリを Wayland 上で動作させるには、環境変数 {{ic|1=CLUTTER_BACKEND=wayland}} を設定する必要があります。

=== SDL2 ===

SDL2 アプリケーションを Wayland 上で動作させるには、{{ic|1=SDL_VIDEODRIVER=wayland}} を設定してください。

{{ic|1=SDL_VIDEODRIVER="wayland,x11"}} とすることにより、Wayland が利用できない場合に代わりに X11 ビデオドライバを使用するように SDL2 を設定できます [https://wiki.libsdl.org/SDL2/FAQUsingSDL]。ウィンドウ装飾を有効化するために {{Pkg|libdecor}} をインストールすると良いかもしれません (例えば、GNOME で)。

=== GLFW ===

{{Pkg|glfw}} パッケージには Wayland に対するサポートがあります。{{ic|1=XDG_SESSION_TYPE}} が {{ic|1=wayland}} に設定されていて、かつアプリケーションの開発者が特定のバックエンドを使用するようにしていなければ、Wayland バックエンドが使用されます。

詳細は GLFW の[https://github.com/glfw/glfw/blob/3.4/src/platform.c#L87-L99 ソースコード]を参照してください。

=== GLEW ===

{{AUR|glew-wayland}} パッケージは現在のところ、多くの GLEW ベースのアプリケーションでまだ動作しませんので、唯一の選択肢は Xwayland で {{Pkg|glew}} を使うことです。{{Bug|62713}} を参照してください。

=== EFL ===

EFL は Wayland を完全にサポートしています。Wayland で EFL アプリケーションを動かすには、Wayland の [https://wayland.freedesktop.org/efl.html プロジェクトページ] を見て下さい。

=== winit ===

Winit は [[Rust]] で書かれたウィンドウ管理ライブラリです。デフォルトでは Wayland が X11 より優先される仕様ですが、環境変数を設定することで Xwayland を使うように上書きすることができます:

* バージョン 0.29.2 より前の場合、{{ic|1=WINIT_UNIX_BACKEND=x11}} を設定してください。
* バージョン 0.29.2 以降の場合、{{ic|1=WAYLAND_DISPLAY}} を unset してください。そうすることで、強制的に {{ic|1=DISPLAY}} 変数を使用して X にフォールバックされます。[https://github.com/rust-windowing/winit/blob/baf10de95843f156b0fbad6b10c3137f1ebd4f1e/src/changelog/v0.29.md?plain=1#L134]

=== Electron ===

Wayland サポートを有効化する方法は次の2つです: アプリケーションごとのコマンドラインフラグを使って有効化するか、設定ファイルを使ってグローバルに有効化するかです。

アプリケーションがどの electron バージョンを使用しているか確認する方法については [https://stackoverflow.com/q/50345957] を見てください。

{{Note|Plasma では、一部の Electron アプリケーションで間違ったアイコン (デフォルトの Wayland アイコン) がウィンドウに表示され、一方タスクバーには正しいアイコンが表示されることがあります。この問題は、デスクトップファイルの名前を強制する特殊なアプリケーション/ウィンドウルールを作成することで解決できます。}}

==== 環境変数 ====

Electron 28 及びそれ以降を使用するアプリケーションは、[[環境変数]] [https://www.electronjs.org/docs/latest/api/environment-variables#electron_ozone_platform_hint-linux ELECTRON_OZONE_PLATFORM_HINT] を {{ic|auto}} または {{ic|wayland}} に設定することで、Wayland モードを使用することができます。

コマンドラインフラグは、この環境変数より優先されます。

==== コマンドラインフラグ ====

Electron がベースとしている Chromium とは異なり、Electron アプリケーションはデフォルトで PipeWire による WebRTC 画面共有を有効化しません。なので、Wayland 上で画面共有の問題を防ぐために {{ic|1=--enable-features=WebRTCPipeWireCapturer}} を使用することが推奨されます。画面共有は {{Pkg|xdg-desktop-portal}} をベースとしています。

環境変数を使うことが望ましくない、または不可能である場合に、{{Pkg|electron}} ベースのアプリケーションを Wayland でネイティブに使用するには、Electron 20 以降では {{ic|1=--ozone-platform-hint=auto}} フラグを使用することで可能です。

トップバーが消失してしまう場合、{{ic|1=--enable-features=WaylandWindowDecorations}} フラグを使用することで解決します。これは、典型的には [[GNOME]] で必須です ([https://github.com/electron/electron/pull/29618 electron17] からsパオートされています)。

これらのフラグを永続的に設定する方法は2つあります。1つ目は、アプリケーションの [[デスクトップエントリ#desktop ファイルの変更|.desktop ファイルを変更]]して {{ic|1=Exec=}} 行の末尾にフラグを追加する方法。もう一つは、以下で説明している設定ファイルを使用する方法で、こちらはよりきれいに設定できます。

{{Note|一部のアプリケーションは、Electron に対してフラグを渡さないため、そのアプリケーションの開発者が解決策を実装する必要があります。}}

==== 設定ファイル ====

Electron 系のパッケージは {{ic|1=~/.config/electron''XX''-flags.conf}} を読み込みます。ここで、''XX'' は Electron のバージョンです。該当するバージョンのファイルが存在しない場合、{{ic|1=~/.config/electron-flags.conf}} を代わりに読み込みます。

前述のフラグを一行ずつ書き込んでください:

{{hc|~/.config/electron-flags.conf|2=
--enable-features=WaylandWindowDecorations
--ozone-platform-hint=auto
}}

{{Note|このような設定ファイルは、公式リポジトリ内の Electron のパッケージと、それらの設定ファイルを使用するパッケージでのみ機能します。{{AUR|slack-desktop}} などのような Electron の独自のビルドをバンドルしているパッケージでは機能しません。{{AUR|slack-electron}} のように代替のパッケージが存在する場合があります。}}

==== 古い Electron バージョン ====

{{ic|electron25-flags.conf}} は Electron バージョン 25 に対してだけ適用されます。それより古い Electron のバージョンは {{ic|electron<バージョン>-flags.conf}} ファイルで設定できます。

古いバージョンでは、対応する Chromium バージョンによって異なるフラグが必要になる場合があります。例えば、以下のフラグは Electron 13 で機能します:

{{hc|~/.config/electron13-flags.conf|2=
--enable-features=UseOzonePlatform
--ozone-platform=wayland
}}

=== Java ===

[[Java]] プラットフォームのオープンソース実装である OpenJDK は、まだ Wayland のネイティブサポートを備えていません。
OpenJDK に Wayland を実装することを目的としたプロジェクトである [https://openjdk.java.net/projects/wakefield/ Wakefield] が実用できるようになるまでは、Xwayland を代わりに使用できます。

[[Debian:Wayland#Java Programs (supported since OpenJDK 16?)]] を参照してください:

:OpenJDK 16から、JRE は (Wayland をサポートしている) GTK3 を動的にロードできるようになりました。この[https://stackoverflow.com/questions/39197208/java-gui-support-on-wayland 議論]によると、これがサポートされているかもしれません。
:{{ic|_JAVA_AWT_WM_NONREPARENTING}} [[環境変数]]を "1" に設定することで、アプリケーションが空白の画面で起動する不具合を修正することができます。

== ヒントとテクニック ==

=== 自動化 ===

* [https://github.com/ReimuNotMoe/ydotool ydotool] ({{Pkg|ydotool}}) - 汎用のコマンドラインツール (wayland 以外でも利用可能)。{{ic|ydotool.service}} [[ユーザーユニット]]を[[起動/有効化]]してください。{{man|8|ydotoold}}、{{man|1|ydotool|url=https://github.com/ReimuNotMoe/ydotool/blob/master/manpage/ydotool.1.scd}} を参照。
* [https://github.com/atx/wtype wtype] ({{Pkg|wtype}}) - Wayland 用 xdotool type。{{man|1|wtype}} を参照。
* [https://github.com/boppreh/keyboard keyboard] - Windows と Linux で動作する Python ライブラリ。実験的な OS X サポートあり。[https://github.com/boppreh/mouse mouse] ライブラリも参照。
* [https://git.sr.ht/~brocellous/wlrctl wlrctl] ({{AUR|wlrctl}}) - 雑多な wlroots 拡張のためのコマンドラインユーティリティ (foreign-toplevel-management、virtual-keyboard、virtual-pointer をサポート)。

=== キーボードやマウスキーのリマップ ===

[[入力リマップユーティリティ]] を見てください。

=== X11 アプリケーションで Wayland ウィンドウをスクリーンキャストする ===

[[スクリーンキャプチャ#X11 アプリケーションで Wayland ウィンドウをスクリーンキャストする]] を見てください。

=== Chromium で完全に最大化出来ない ===

chrome://settings/appearance ''メニューから'' Use system title bar and borders'' を有効にする必要があります。

=== Waylandコンポジタをsystemdサービスとして自動的に起動する ===
{{Note|この設定はdbusセッションを破壊し,[[PipeWire#WebRTC 画面共有]]を破壊するかも知れません.}}
ディスプレイマネージャーやシェルを使いたくなければ、Waylandコンポジタを[[systemd]]サービスを使って自動的に起動できます。{{ic|ExecStart}}行を使いたいコンポジタに変えて下さい:

{{hc|/etc/systemd/system/wayland-compositor.service|2=
[Unit]
After=graphical.target systemd-user-sessions.service modprobe@drm.service
Conflicts=getty@tty1.service

[Service]
User=''username''
WorkingDirectory=~

PAMName=login
TTYPath=/dev/tty1
UnsetEnvironment=TERM

StandardOutput=journal
ExecStart=/bin/labwc -s gtklock

[Install]
WantedBy=graphical.target
}}

{{Note|[[セキュリティ#物理セキュリティ]]の為に、{{Pkg|swaylock}}や{{Pkg|gtklock}}等のスクリーンロッカーを、コンポジタの設定を通して自動的に起動する必要があるかも知れません。}}

==トラブルシューティング==

=== 色補正 ===

[[バックライト#色補正]]を参照。

=== 動作が遅い、表示がおかしい、クラッシュする ===

Gnome-shell で X から Wayland に切り替えるとグラフィック表示に問題が発生することがあります。原因として Xorg ベースの gnome-shell 用に {{ic|1=CLUTTER_PAINT=disable-clipped-redraws:disable-culling}} が設定されている可能性があります。{{ic|/etc/environment}} や rc ファイルから該当箇所を削除してみてください。

=== リモートディスプレイ ===

* ([[sway]] で使用されている) {{pkg|wlroots}} は、バージョン 0.10 より、{{Pkg|wayvnc}} を使って VNC バックエンドを提供しています。RDP バックエンドは削除されました [https://github.com/swaywm/wlroots/releases/tag/0.10.0]。
* {{pkg|mutter}} はコンパイル時にリモートデスクトップが有効化されています。詳細は [https://wiki.gnome.org/Projects/Mutter/RemoteDesktop] と {{Pkg|gnome-remote-desktop}} を見てください。
* {{pkg|krfb}} は {{pkg|kwin}} に VNC サーバを提供します。{{ic|krfb-virtualmonitor}} を使えば、他のデバイスを外部モニタとしてセットアップすることが可能です。
* 2013年に FreeRDP が Weston にマージされました。コンパイルフラグで有効化されています。{{Pkg|weston}} パッケージは、バージョン 6.0.0 より、FreeRDP が有効化されています。
* {{Pkg|waypipe}} は Wayland アプリケーションの透過プロキシです。[[SSH]] 上で動作するラッパーコマンドあり。
** 以下は、Plasma デスクトップでリモートの KDE kcalc を起動する例です:
$ waypipe ssh example.local env QT_QPA_PLATFORM=wayland-egl QT_QPA_PLATFORMTHEME=KDE dbus-launch kcalc

=== ゲームやリモートデスクトップ、仮想マシンウィンドウでの入力捕捉 ===

Xorg と異なり、Wayland では入力デバイスを独占 (グラブ) することができません (例: [https://tronche.com/gui/x/xlib/input/XGrabKeyboard.html キーボード]、[https://tronche.com/gui/x/xlib/input/XGrabPointer.html マウス])。キーボードショートカットやポインタデバイスをアプリケーションウィンドウに渡すのは Wayland コンポジタの役目となっています。

入力グラブが変わったことで以下のように既存のアプリケーションで問題が発生します:

* ホットキーや修飾キーがコンポジタによって認識されてしまい、リモートデスクトップや仮想マシンのウィンドウに送信されなくなります。
* マウスポインタがアプリケーションウィンドウに制限されなくなるため、仮想マシンやリモートデスクトップのウィンドウ内のマウスポインタの位置がホスト環境のマウスポインタとずれるようになります。

Wayland と Xwayland にプロトコル拡張を追加することで解決を図っていますが、Wayland コンポジタが拡張をサポートしている必要があり、ネイティブの Wayland クライアントの場合、ウィジェットツールキット (例: GTK, Qt) やアプリケーション自身が拡張に対応していなければなりません。Xorg アプリケーションの場合、Xwayland のサポートで十分であるため、アプリケーションやウィジェット・ツールキットに変更を加える必要はありません。

これらの拡張はすでに {{pkg|wayland-protocols}} に含まれており、{{pkg|xorg-xwayland}} によってサポートされています。

関連する拡張:

* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml Xwayland keyboard grabbing protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml Compositor shortcuts inhibit protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/relative-pointer/relative-pointer-unstable-v1.xml Relative pointer protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml Pointer constraints protocol]

サポートしている Wayland コンポジタ:

* Mutter, [[GNOME]] のコンポジタ ([https://bugzilla.gnome.org/show_bug.cgi?id=783342 リリース 3.28] 以降)。
* wlroots (Relative pointer protocols と Pointer constraints protocol に対応)
* Kwin
** [[KDE#Wayland で X11 のショートカットが衝突する]]
** [https://invent.kde.org/plasma/kwin/-/blob/master/src/wayland/keyboard_shortcuts_inhibit_v1_interface.cpp Keyboard shortcuts inhibit]

サポートしているウィジェットツールキット:

* GTK (リリース 3.22.18 以降)

=== GTK テーマが動かない ===

https://github.com/swaywm/sway/wiki/GTK-3-settings-on-Wayland を参照してください。

=== NVIDIA モジュールを読み込まないようにする ===

[[sway]] などの Wayland コンポジターを起動する前に {{ic|1=__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json}} を [[環境変数]] として追加します。

=== 拡大/サーフェススケーリング ===

スクリーンの拡大は、まだ解決していません。[https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/145 wp-surface-scale プロトコルを提供する]プルリクエストが2022年半ばにマージされました。

=== カーネル 6.11.2 (AMD) 以降、Wayland にラグ/スタッタリングが発生する ===

将来のカーネルリリースでこの問題が修正されるまで、回避策は、コマンドラインに {{ic|1=amdgpu.dcdebugmask=0x400}} を追加することです。

こちらを参照: https://community.frame.work/t/wayland-lag-stuttering-since-kernel-6-11-2/59422

== 参照 ==

* [https://wayland.freedesktop.org/docs/html/ Wayland オンラインドキュメント]
* [https://gitlab.freedesktop.org/wayland 公式リポジトリ]
* [[Fedora:How to debug Wayland problems]]
* [https://arewewaylandyet.com/ Are we Wayland yet?]
* [https://awesomeopensource.com/projects/wayland Awesome Wayland projects]
* [[カーソルテーマ]]
* [https://bbs.archlinux.org/viewtopic.php?id=107499 Arch Linux forum discussion]
* [https://github.com/swaywm/sway/wiki/i3-Migration-Guide#common-x11-apps-used-on-i3-with-wayland-alternatives i3 Migration Guide - Common X11 apps used on i3 with Wayland alternatives]
* [https://wayland.app/protocols/ Wayland Explorer - A better way to read Wayland documentation]
* [https://askubuntu.com/questions/1393618/how-can-i-tell-if-an-application-is-using-xwayland How can I tell if an application is using XWayland]

{{TranslationStatus|Wayland|2024-08-24|814878}}

Wayland

2025-04-03T17:04:50Z

Oech3: uwsmのリンク/* ディスプレイマネージャ */

[[Category:グラフィカルユーザーインターフェイス]]
[[en:Wayland]]
[[es:Wayland]]
[[pt:Wayland]]
[[ru:Wayland]]
[[zh-hans:Wayland]]
{{Related articles start}}
{{Related|カーネルモード設定}}
{{Related|Xorg}}
{{Related|スクリーンショットの取得#Wayland}}
{{Related articles end}}

[https://wayland.freedesktop.org/ Wayland] はディスプレイサーバープロトコルです。[[Xorg|X Window System]] の後継となることを目指しています。[[Wikipedia:Wayland_(display_server_protocol)#Differences_between_Wayland_and_X|Wikipedia に Wayland と Xorg の比較]] が掲載されています。

Wayland プロトコルを使用するディスプレイサーバは、[[Wikipedia:ja:コンポジット型ウィンドウマネージャ|コンポジット型ウィンドウマネージャ]] としても機能するため、'''コンポジタ''' と呼ばれます。以下に[[#コンポジタ|Wayland コンポジタのリスト]]を示します。

ネイティブな X11 アプリケーションをシームレスに動かすための後方互換性として、[[#Xwayland|Xwayland]] を使うことができます。これは Wayland に X サーバを提供します。

== 要件 ==

ほとんどの Wayland コンポジタは、[[カーネルモード設定]]を利用しているシステムでのみ動作します。Wayland それ自体はグラフィカルな環境を提供しません。ゆえに、Wayland に加えてコンポジタ (以下のセクションを参照)、あるいは、コンポジタを含むデスクトップ環境 (例: [[GNOME]]、[[Plasma]]) が必要となります。

GPU ドライバと Wayland コンポジタは、同一のバッファ API に対応している場合に互換性があります。主要な API は2つ存在します: [[Wikipedia:Generic Buffer Management|GBM]] と [https://www.phoronix.com/scan.php?page=news_item&px=XDC2016-Device-Memory-API EGLStreams] です。

{| class="wikitable"
! バッファ API !! GPU ドライバーのサポート !! Wayland コンポジタのサポート
|-
| GBM || [[NVIDIA]] < 495* 以外の全てのドライバー || 全て
|-
| EGLStreams || [[NVIDIA]] || [[GNOME]]
|}

: * Nvidia ≥ 495 は EGLStreams と GBM の両方をサポートします。[https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-495.44-Linux-Driver]

NVIDIA が GBM のサポートを導入して以来、NVIDIA ≥ 495 で多くのコンポジタ (Mutter と KWin を含む) がデフォルトで GBM を使用し始めました。GBM は一般的にベターでより幅広いサポートがあると考えられています。EGLStreams がサポートされていた理由は、NVIDIA GPU をプロプライエタリドライバで Wayland 下で使用する代替の方法を NVIDIA が提供しなかったからだけです。さらに、GBM が NVIDIA に導入された後、KWin は [https://invent.kde.org/plasma/kwin/-/merge_requests/1638 EGLStreams のサポートを打ち切りました]。

人気なデスクトップ環境/コンポジタと、NVIDIA によってまだサポートされている GPU を使用している場合、おそらくすでに GBM バックエンドを使用しています。確認するには、次を実行してください: {{ic|journalctl -b 0 --grep "renderer for"}}。GBM をバックエンドとして強制的に使用させるには、次の[[環境変数]]を設定してください:

GBM_BACKEND=nvidia-drm
__GLX_VENDOR_LIBRARY_NAME=nvidia

== コンポジタ ==

'''タイル型''', '''スタック型''', '''ダイナミック型''' の違いについては、[[ウィンドウマネージャ#種類]] を参照してください。

=== スタック型 ===

* {{App|[[Enlightenment]]|[[Enlightenment]]|[[Enlightenment#手動]] を参照してください。詳細: [https://git.enlightenment.org/enlightenment/enlightenment/src/branch/master/README.md] [https://www.enlightenment.org/about-wayland]|https://www.enlightenment.org/|{{Pkg|enlightenment}}}}
* {{App|hikari|FreeBSD で活発に開発されている [[cwm]] にインスパイアされた wlroots ベースのコンポジタ。Linux もサポートしています。|https://hikari.acmelabs.space/|{{AUR|hikari}}}}
* {{App|KDE [[w:KWin|KWin]]|[[KDE#Plasma の起動]] を参照。|https://userbase.kde.org/KWin|{{Pkg|kwin}}}}
* {{App|Liri Shell|[[Liri]] の一部、しかし、QtQuick と QtCompositor を使って Wayland 用のコンポジタとして作られています。|https://github.com/lirios/shell|{{AUR|liri-shell-git}}}}
* {{App|labwc|Openbox にインスパイアされた wlroots ベースのコンポジタ。|https://github.com/labwc/labwc|{{Pkg|labwc}}}}
* {{App|[[w:Mutter (software)|Mutter]]|[[GNOME#GNOME の起動]] を参照。|https://gitlab.gnome.org/GNOME/mutter|{{Pkg|mutter}}}}
* {{App|wayfire|[[Compiz]] にインスパイアされ、wlroots に基づく 3D コンポジタ。|https://wayfire.org/|{{AUR|wayfire}}}}
* {{App|[[Weston]]|正しさ、信頼性、予測可能性、性能のために設計された Wayland コンポジタ。|https://gitlab.freedesktop.org/wayland/weston|{{Pkg|weston}}}}
* {{App|wio|Plan 9 のリオデスクトップのルックアンドフィールを複製することを目的とする wlroots ベースのコンポジタ。|https://gitlab.com/Rubo/wio|{{AUR|wio-wl}}}}

=== タイル型 ===

* {{App|[[Cagebreak]]|cage をベースに、[[ratpoison]] にインスパイアされています。|https://github.com/project-repo/cagebreak|{{AUR|cagebreak}}}}
* {{App|niri|スクロール可能なタイル型 Wayland コンポジタ。|https://github.com/YaLTeR/niri/|{{Pkg|niri}}}}
* {{App|Polonium|[[KDE]] 6 上でタイル型ウィンドウを使用できる、Bismuth の後継。|https://github.com/zeroxoneafour/polonium|{{AUR|kwin-polonium}}}}
* {{App|[[Qtile]]|Python で記述および設定されたフル機能のハッキング可能なタイリングウィンドウマネージャーと Wayland コンポジタ。|https://github.com/qtile/qtile|{{Pkg|qtile}}}}
* {{App|[[Sway]]|wlroots ベースの [[i3]] 互換 Wayland コンポジタ。|https://github.com/swaywm/sway|{{Pkg|sway}}}}
* {{App|SwayFx|魅力的な視覚効果機能を追加した [[Sway]]。|https://github.com/WillPower3309/swayfx|{{AUR|swayfx}}}}
* {{App|Velox|swc ベースのシンプルなウィンドウマネージャです。[[dwm]] と [[xmonad]] の影響を受けています。|https://github.com/michaelforney/velox|{{AUR|velox-git}}}}

=== ダイナミック型 ===

* {{App|[[dwl]]|wlroots ベースの [[dwm]] ライクな Wayland コンポジタ。|https://codeberg.org/dwl/dwl|{{AUR|dwl}}}}
* {{App|[[Hyprland]]|見た目を犠牲にしないダイナミックなタイリング Wayland コンポジタ。|https://hyprland.org|{{Pkg|hyprland}}}}
* {{App|japokwm|wlroots ベースの、レイアウト作成を中心とした動的な Wayland タイリングコンポジタ。|https://github.com/werererer/japokwm|{{AUR|japokwm-git}}}}
* {{App|[[river]]|dwm と [[bspwm]] にインスパイアされた動的なタイル型 Wayland コンポジタ。|https://codeberg.org/river/river|{{Pkg|river}}}}
* {{App|Vivarium|wlroots を使用するダイナミックタイル型 Wayland コンポジタ。[[xmonad]] にインスパイアされたデスクトップセマンティクスを持ちます。|https://github.com/inclement/vivarium|{{AUR|vivarium-git}}}}

=== その他 ===

* {{App|Cage|キオスクのような単一のフルスクリーンアプリケーションを表示します。|https://www.hjdskes.nl/projects/cage/|{{Pkg|cage}}}}
* {{App|nwg-shell|Sway と Hyprland Wayland コンポジタのための GTK ベースシェル。|https://github.com/nwg-piotr/nwg-shell|{{Pkg|nwg-shell}}}}
* {{App|kiwmi|完全にプログラミング可能な Wayland コンポジタ。|https://github.com/buffet/kiwmi|{{AUR|kiwmi-git}}}}
* {{App|phoc|モバイル端末のための wlroots ベースの小さなコンポジタ。|https://gitlab.gnome.org/World/Phosh/phoc|{{Pkg|phoc}}}}

上記のいくつかは [[ディスプレイマネージャ]] をサポートする場合があります。
それらがどのように開始されるかを {{ic|/usr/share/wayland-sessions/''compositor''.desktop}} を見て確認してください。

== ディスプレイマネージャ ==

Wayland コンポジタの実行をサポートしている[[ディスプレイマネージャ]]は以下の表の通りです。

{| class="wikitable sortable"
! 名前
! それ自体は Wayland で動作するか?
! 説明
|-
| {{Pkg|emptty}}
| {{No}}
| TTY で動作するシンプルな CLI ディスプレイマネージャ。
|-
| [[GDM]]
| {{Yes}}
| [[GNOME]] ディスプレイマネージャ。
|-
| [[greetd]]
| {{G|Wayland の greeter を使用した場合}}
| 最小でありながら柔軟なログインデーモン。
|-
| {{Pkg|lemurs}}
| {{No}}
| Rust で書かれた TUI ディスプレイマネージャ。
|-
| [[LightDM]]
| {{No|https://github.com/canonical/lightdm/issues/267}}
| 様々なデスクトップに対応したディスプレイマネージャ。
|-
| [[Ly]]
| {{No}}
| C で書かれた TUI ディスプレイマネージャ。
|-
| [[SDDM]]
| {{Yes}}
| QML ベースのディスプレイマネージャ。
|-
| [[tbsm]]
| {{No}}
| bash のみに依存するシンプルな CLI セッションランチャー。
|-
| [[Universal_Wayland_Session_Manager|UWSM]]
| {{No}}
| Systemd のメカニズムを使用するスタンドアローンなコンポジタのための、セッションと XDG autostart のマネージャ。
|}

== Xwayland ==

[https://wayland.freedesktop.org/xserver.html Xwayland] は、Wayland の下で実行される X サーバーで、Wayland サポートをまだ提供していないネイティブな [[X11]] アプリケーションに互換性を提供します。これを使用するには、{{Pkg|xorg-xwayland}} パッケージを[[インストール]]します。

Xwayland はコンポジタを介して開始されるため、あなたの使用しているコンポジタのドキュメントを読み、Xwayland との互換性についてや、Xwayland の起動方法に関する指示を確認しておく必要があります。

{{Note|
* セキュリティ: Xwayland は X サーバーであるため、 Wayland のセキュリティ機能はありません。
* パフォーマンス: Xwayland は X11 と[https://openbenchmarking.org/result/2202053-NE-NVIDIARTX35 ほぼ同等のパフォーマンス]を発揮します。しかし、一部のケースで (特に NVIDIA カード上で) パフォーマンスの低下を感じるかもしれません。
* 互換性: Xwayland は X11 と完全な後方互換性があるわけではありません。一部のアプリケーションは Xwayland 下では正しく動作しない場合があります。}}

=== NVIDIA ドライバ ===

{{Note|バージョン 470 より前の Nvidia ドライバ(例: {{aur|nvidia-390xx-dkms}}) はハードウェア支援のある Xwayland をサポートしておらず、非 Wayland ネイティブなアプリケーションは Wayland セッションでのパフォーマンスが低下します。}}

なお、[[NVIDIA#DRM カーネルモード設定|DRM KMS]] を有効にする必要があります。また、お使いのディスプレイマネージャ(例: [[GDM#Wayland と独自の NVIDIA ドライバ|GDM]])の[https://download.nvidia.com/XFree86/Linux-x86_64/515.48.07/README/xwayland.html 公式ドキュメント]に記載されている情報も見てください。

=== Kwin Wayland デバッグコンソール ===

{{pkg|kwin}} を使用している場合、以下を実行すると、どのウィンドウが Xwayland とネイティブ Wayland を使用しているか、表面、入力イベント、クリップボードの内容などを確認することができます。

$ qdbus6 org.kde.KWin /KWin org.kde.KWin.showDebugConsole

=== Xwayland アプリケーションであることを視認する ===

アプリケーションが Xwayland 経由で実行されているかどうかを判断するには、{{AUR|extramaus}} を使用します。
アプリケーションのウィンドウ上にマウスポインタを移動して、マウスポインタが赤くなる場合は、アプリケーションが Xwayland 経由で実行されています。

または、{{pkg|xorg-xeyes}} を使用して、アプリケーションウィンドウ上でマウスポインタを移動するときに、目が動いているかどうかで確認することもできます。

他の方法として、({{Pkg|xorg-xwininfo}} の) ''xwininfo'' をターミナルウィンドウで実行するというものがあります。Xwayland ウィンドウ上にマウスポインタをホバーすると、マウスポインタが + マークに変わります。ウィンドウをクリックすると、xwininfo は情報を表示して終了しますが、ネイティブな Wayland ウィンドウでは何も起こりません。{{ic|Ctrl+C}} を押すことで xwininfo を終了できます。

あるいは、''xlsclients'' ({{Pkg|xorg-xlsclients}} パッケージ) を使用することもできます。Xwayland で動作中のアプリケーションを全てリストアップするには、{{ic|xlsclients -l}} を実行してください。

== GUI ライブラリ ==

[https://wayland.freedesktop.org/toolkits.html 公式ウェブサイト] で詳細を確認してください。

=== GTK ===

{{Pkg|gtk3}} と {{Pkg|gtk4}} パッケージは Wayland バックエンドが有効になっています。GTK ではデフォルトで Wayland バックエンドを使いますが、[[環境変数]]を設定することで Xwayland を使うように上書きできます: {{ic|1=GDK_BACKEND=x11}}。

テーマの問題は [[GTK#Wayland バックエンド]] を見てください。

=== Qt ===

[[Qt]] 5 または 6 で Wayland のサポートを有効化するには、Qt 5 と 6 に対してそれぞれ {{Pkg|qt5-wayland}} または {{Pkg|qt6-wayland}} パッケージをインストールしてください。これで、Qt アプリケーションは Wayland セッション上では Wayland で動作するようになります。

必須ではないはずですが、明示的に Wayland プラグインを使って Qt 5 アプリケーションを動作させるには、[https://wiki.qt.io/QtWayland#How_do_I_use_QtWayland.3F] にあるように、{{ic|1=-platform wayland}} を使用するか、[[環境変数]] {{ic|1=QT_QPA_PLATFORM=wayland}} をセットして下さい。

一方、Wayland セッション上で [[X11]] を使用させるには、{{ic|1=QT_QPA_PLATFORM=xcb}} と設定してください。これは、{{AUR|zoom}} など、システムの Qt の実装を使用しない一部のプロプライエタリアプリケーションで必要になる場合があります。
また、{{ic|1=QT_QPA_PLATFORM="wayland;xcb"}} を使用すると、Qt が Wayland を利用できない場合に、代わりに xcb (X11)プラグインを使用させることができます。[https://www.qt.io/blog/2018/05/29/whats-new-in-qt-5-11-for-the-wayland-platform-plugin]

[[sway]] などの一部のコンポジターでは、ネイティブに実行されている Qt アプリケーションの機能が不足している場合があります。たとえば、[https://keepassxc.org KeepassXC] はトレイに最小化できません。これは、アプリケーションを実行する前に {{Pkg|qt5ct}} をインストールし、{{ic|1=QT_QPA_PLATFORMTHEME=qt5ct}} を設定することで解決できます。

=== Clutter ===

Clutter ツールキットには Wayland バックエンドがあり、Clutter を Wayland のクライアントとして動作させることが可能です。このバックエンドは {{Pkg|clutter}} パッケージで有効になっています。

Clutter アプリを Wayland 上で動作させるには、環境変数 {{ic|1=CLUTTER_BACKEND=wayland}} を設定する必要があります。

=== SDL2 ===

SDL2 アプリケーションを Wayland 上で動作させるには、{{ic|1=SDL_VIDEODRIVER=wayland}} を設定してください。

{{ic|1=SDL_VIDEODRIVER="wayland,x11"}} とすることにより、Wayland が利用できない場合に代わりに X11 ビデオドライバを使用するように SDL2 を設定できます [https://wiki.libsdl.org/SDL2/FAQUsingSDL]。ウィンドウ装飾を有効化するために {{Pkg|libdecor}} をインストールすると良いかもしれません (例えば、GNOME で)。

=== GLFW ===

{{Pkg|glfw}} パッケージには Wayland に対するサポートがあります。{{ic|1=XDG_SESSION_TYPE}} が {{ic|1=wayland}} に設定されていて、かつアプリケーションの開発者が特定のバックエンドを使用するようにしていなければ、Wayland バックエンドが使用されます。

詳細は GLFW の[https://github.com/glfw/glfw/blob/3.4/src/platform.c#L87-L99 ソースコード]を参照してください。

=== GLEW ===

{{AUR|glew-wayland}} パッケージは現在のところ、多くの GLEW ベースのアプリケーションでまだ動作しませんので、唯一の選択肢は Xwayland で {{Pkg|glew}} を使うことです。{{Bug|62713}} を参照してください。

=== EFL ===

EFL は Wayland を完全にサポートしています。Wayland で EFL アプリケーションを動かすには、Wayland の [https://wayland.freedesktop.org/efl.html プロジェクトページ] を見て下さい。

=== winit ===

Winit は [[Rust]] で書かれたウィンドウ管理ライブラリです。デフォルトでは Wayland が X11 より優先される仕様ですが、環境変数を設定することで Xwayland を使うように上書きすることができます:

* バージョン 0.29.2 より前の場合、{{ic|1=WINIT_UNIX_BACKEND=x11}} を設定してください。
* バージョン 0.29.2 以降の場合、{{ic|1=WAYLAND_DISPLAY}} を unset してください。そうすることで、強制的に {{ic|1=DISPLAY}} 変数を使用して X にフォールバックされます。[https://github.com/rust-windowing/winit/blob/baf10de95843f156b0fbad6b10c3137f1ebd4f1e/src/changelog/v0.29.md?plain=1#L134]

=== Electron ===

Wayland サポートを有効化する方法は次の2つです: アプリケーションごとのコマンドラインフラグを使って有効化するか、設定ファイルを使ってグローバルに有効化するかです。

アプリケーションがどの electron バージョンを使用しているか確認する方法については [https://stackoverflow.com/q/50345957] を見てください。

{{Note|Plasma では、一部の Electron アプリケーションで間違ったアイコン (デフォルトの Wayland アイコン) がウィンドウに表示され、一方タスクバーには正しいアイコンが表示されることがあります。この問題は、デスクトップファイルの名前を強制する特殊なアプリケーション/ウィンドウルールを作成することで解決できます。}}

==== 環境変数 ====

Electron 28 及びそれ以降を使用するアプリケーションは、[[環境変数]] [https://www.electronjs.org/docs/latest/api/environment-variables#electron_ozone_platform_hint-linux ELECTRON_OZONE_PLATFORM_HINT] を {{ic|auto}} または {{ic|wayland}} に設定することで、Wayland モードを使用することができます。

コマンドラインフラグは、この環境変数より優先されます。

==== コマンドラインフラグ ====

Electron がベースとしている Chromium とは異なり、Electron アプリケーションはデフォルトで PipeWire による WebRTC 画面共有を有効化しません。なので、Wayland 上で画面共有の問題を防ぐために {{ic|1=--enable-features=WebRTCPipeWireCapturer}} を使用することが推奨されます。画面共有は {{Pkg|xdg-desktop-portal}} をベースとしています。

環境変数を使うことが望ましくない、または不可能である場合に、{{Pkg|electron}} ベースのアプリケーションを Wayland でネイティブに使用するには、Electron 20 以降では {{ic|1=--ozone-platform-hint=auto}} フラグを使用することで可能です。

トップバーが消失してしまう場合、{{ic|1=--enable-features=WaylandWindowDecorations}} フラグを使用することで解決します。これは、典型的には [[GNOME]] で必須です ([https://github.com/electron/electron/pull/29618 electron17] からsパオートされています)。

これらのフラグを永続的に設定する方法は2つあります。1つ目は、アプリケーションの [[デスクトップエントリ#desktop ファイルの変更|.desktop ファイルを変更]]して {{ic|1=Exec=}} 行の末尾にフラグを追加する方法。もう一つは、以下で説明している設定ファイルを使用する方法で、こちらはよりきれいに設定できます。

{{Note|一部のアプリケーションは、Electron に対してフラグを渡さないため、そのアプリケーションの開発者が解決策を実装する必要があります。}}

==== 設定ファイル ====

Electron 系のパッケージは {{ic|1=~/.config/electron''XX''-flags.conf}} を読み込みます。ここで、''XX'' は Electron のバージョンです。該当するバージョンのファイルが存在しない場合、{{ic|1=~/.config/electron-flags.conf}} を代わりに読み込みます。

前述のフラグを一行ずつ書き込んでください:

{{hc|~/.config/electron-flags.conf|2=
--enable-features=WaylandWindowDecorations
--ozone-platform-hint=auto
}}

{{Note|このような設定ファイルは、公式リポジトリ内の Electron のパッケージと、それらの設定ファイルを使用するパッケージでのみ機能します。{{AUR|slack-desktop}} などのような Electron の独自のビルドをバンドルしているパッケージでは機能しません。{{AUR|slack-electron}} のように代替のパッケージが存在する場合があります。}}

==== 古い Electron バージョン ====

{{ic|electron25-flags.conf}} は Electron バージョン 25 に対してだけ適用されます。それより古い Electron のバージョンは {{ic|electron<バージョン>-flags.conf}} ファイルで設定できます。

古いバージョンでは、対応する Chromium バージョンによって異なるフラグが必要になる場合があります。例えば、以下のフラグは Electron 13 で機能します:

{{hc|~/.config/electron13-flags.conf|2=
--enable-features=UseOzonePlatform
--ozone-platform=wayland
}}

=== Java ===

[[Java]] プラットフォームのオープンソース実装である OpenJDK は、まだ Wayland のネイティブサポートを備えていません。
OpenJDK に Wayland を実装することを目的としたプロジェクトである [https://openjdk.java.net/projects/wakefield/ Wakefield] が実用できるようになるまでは、Xwayland を代わりに使用できます。

[[Debian:Wayland#Java Programs (supported since OpenJDK 16?)]] を参照してください:

:OpenJDK 16から、JRE は (Wayland をサポートしている) GTK3 を動的にロードできるようになりました。この[https://stackoverflow.com/questions/39197208/java-gui-support-on-wayland 議論]によると、これがサポートされているかもしれません。
:{{ic|_JAVA_AWT_WM_NONREPARENTING}} [[環境変数]]を "1" に設定することで、アプリケーションが空白の画面で起動する不具合を修正することができます。

== ヒントとテクニック ==

=== 自動化 ===

* [https://github.com/ReimuNotMoe/ydotool ydotool] ({{Pkg|ydotool}}) - 汎用のコマンドラインツール (wayland 以外でも利用可能)。{{ic|ydotool.service}} [[ユーザーユニット]]を[[起動/有効化]]してください。{{man|8|ydotoold}}、{{man|1|ydotool|url=https://github.com/ReimuNotMoe/ydotool/blob/master/manpage/ydotool.1.scd}} を参照。
* [https://github.com/atx/wtype wtype] ({{Pkg|wtype}}) - Wayland 用 xdotool type。{{man|1|wtype}} を参照。
* [https://github.com/boppreh/keyboard keyboard] - Windows と Linux で動作する Python ライブラリ。実験的な OS X サポートあり。[https://github.com/boppreh/mouse mouse] ライブラリも参照。
* [https://git.sr.ht/~brocellous/wlrctl wlrctl] ({{AUR|wlrctl}}) - 雑多な wlroots 拡張のためのコマンドラインユーティリティ (foreign-toplevel-management、virtual-keyboard、virtual-pointer をサポート)。

=== キーボードやマウスキーのリマップ ===

[[入力リマップユーティリティ]] を見てください。

=== X11 アプリケーションで Wayland ウィンドウをスクリーンキャストする ===

[[スクリーンキャプチャ#X11 アプリケーションで Wayland ウィンドウをスクリーンキャストする]] を見てください。

=== Chromium で完全に最大化出来ない ===

chrome://settings/appearance ''メニューから'' Use system title bar and borders'' を有効にする必要があります。

=== Waylandコンポジタをsystemdサービスとして自動的に起動する ===
{{Note|この設定はdbusセッションを破壊し,[[PipeWire#WebRTC 画面共有]]を破壊するかも知れません.}}
ディスプレイマネージャーやシェルを使いたくなければ、Waylandコンポジタを[[systemd]]サービスを使って自動的に起動できます。{{ic|ExecStart}}行を使いたいコンポジタに変えて下さい:

{{hc|/etc/systemd/system/wayland-compositor.service|2=
[Unit]
After=graphical.target systemd-user-sessions.service modprobe@drm.service
Conflicts=getty@tty1.service

[Service]
User=''username''
WorkingDirectory=~

PAMName=login
TTYPath=/dev/tty1
UnsetEnvironment=TERM

StandardOutput=journal
ExecStart=/bin/labwc -s gtklock

[Install]
WantedBy=graphical.target
}}

{{Note|[[セキュリティ#物理セキュリティ]]の為に、{{Pkg|swaylock}}や{{Pkg|gtklock}}等のスクリーンロッカーを、コンポジタの設定を通して自動的に起動する必要があるかも知れません。}}

==トラブルシューティング==

=== 色補正 ===

[[バックライト#色補正]]を参照。

=== 動作が遅い、表示がおかしい、クラッシュする ===

Gnome-shell で X から Wayland に切り替えるとグラフィック表示に問題が発生することがあります。原因として Xorg ベースの gnome-shell 用に {{ic|1=CLUTTER_PAINT=disable-clipped-redraws:disable-culling}} が設定されている可能性があります。{{ic|/etc/environment}} や rc ファイルから該当箇所を削除してみてください。

=== リモートディスプレイ ===

* ([[sway]] で使用されている) {{pkg|wlroots}} は、バージョン 0.10 より、{{Pkg|wayvnc}} を使って VNC バックエンドを提供しています。RDP バックエンドは削除されました [https://github.com/swaywm/wlroots/releases/tag/0.10.0]。
* {{pkg|mutter}} はコンパイル時にリモートデスクトップが有効化されています。詳細は [https://wiki.gnome.org/Projects/Mutter/RemoteDesktop] と {{Pkg|gnome-remote-desktop}} を見てください。
* {{pkg|krfb}} は {{pkg|kwin}} に VNC サーバを提供します。{{ic|krfb-virtualmonitor}} を使えば、他のデバイスを外部モニタとしてセットアップすることが可能です。
* 2013年に FreeRDP が Weston にマージされました。コンパイルフラグで有効化されています。{{Pkg|weston}} パッケージは、バージョン 6.0.0 より、FreeRDP が有効化されています。
* {{AUR|waypipe}} (や {{AUR|waypipe-git}}) は Wayland アプリケーションの透過プロキシです。[[SSH]] 上で動作するラッパーコマンドあり。
** 以下は、Plasma デスクトップでリモートの KDE kcalc を起動する例です:
$ waypipe ssh example.local env QT_QPA_PLATFORM=wayland-egl QT_QPA_PLATFORMTHEME=KDE dbus-launch kcalc

=== ゲームやリモートデスクトップ、仮想マシンウィンドウでの入力捕捉 ===

Xorg と異なり、Wayland では入力デバイスを独占 (グラブ) することができません (例: [https://tronche.com/gui/x/xlib/input/XGrabKeyboard.html キーボード]、[https://tronche.com/gui/x/xlib/input/XGrabPointer.html マウス])。キーボードショートカットやポインタデバイスをアプリケーションウィンドウに渡すのは Wayland コンポジタの役目となっています。

入力グラブが変わったことで以下のように既存のアプリケーションで問題が発生します:

* ホットキーや修飾キーがコンポジタによって認識されてしまい、リモートデスクトップや仮想マシンのウィンドウに送信されなくなります。
* マウスポインタがアプリケーションウィンドウに制限されなくなるため、仮想マシンやリモートデスクトップのウィンドウ内のマウスポインタの位置がホスト環境のマウスポインタとずれるようになります。

Wayland と Xwayland にプロトコル拡張を追加することで解決を図っていますが、Wayland コンポジタが拡張をサポートしている必要があり、ネイティブの Wayland クライアントの場合、ウィジェットツールキット (例: GTK, Qt) やアプリケーション自身が拡張に対応していなければなりません。Xorg アプリケーションの場合、Xwayland のサポートで十分であるため、アプリケーションやウィジェット・ツールキットに変更を加える必要はありません。

これらの拡張はすでに {{pkg|wayland-protocols}} に含まれており、{{pkg|xorg-xwayland}} によってサポートされています。

関連する拡張:

* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml Xwayland keyboard grabbing protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml Compositor shortcuts inhibit protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/relative-pointer/relative-pointer-unstable-v1.xml Relative pointer protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml Pointer constraints protocol]

サポートしている Wayland コンポジタ:

* Mutter, [[GNOME]] のコンポジタ ([https://bugzilla.gnome.org/show_bug.cgi?id=783342 リリース 3.28] 以降)。
* wlroots (Relative pointer protocols と Pointer constraints protocol に対応)
* Kwin
** [[KDE#Wayland で X11 のショートカットが衝突する]]
** [https://invent.kde.org/plasma/kwin/-/blob/master/src/wayland/keyboard_shortcuts_inhibit_v1_interface.cpp Keyboard shortcuts inhibit]

サポートしているウィジェットツールキット:

* GTK (リリース 3.22.18 以降)

=== GTK テーマが動かない ===

https://github.com/swaywm/sway/wiki/GTK-3-settings-on-Wayland を参照してください。

=== NVIDIA モジュールを読み込まないようにする ===

[[sway]] などの Wayland コンポジターを起動する前に {{ic|1=__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json}} を [[環境変数]] として追加します。

=== 拡大/サーフェススケーリング ===

スクリーンの拡大は、まだ解決していません。[https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/145 wp-surface-scale プロトコルを提供する]プルリクエストが2022年半ばにマージされました。

=== カーネル 6.11.2 (AMD) 以降、Wayland にラグ/スタッタリングが発生する ===

将来のカーネルリリースでこの問題が修正されるまで、回避策は、コマンドラインに {{ic|1=amdgpu.dcdebugmask=0x400}} を追加することです。

こちらを参照: https://community.frame.work/t/wayland-lag-stuttering-since-kernel-6-11-2/59422

== 参照 ==

* [https://wayland.freedesktop.org/docs/html/ Wayland オンラインドキュメント]
* [https://gitlab.freedesktop.org/wayland 公式リポジトリ]
* [[Fedora:How to debug Wayland problems]]
* [https://arewewaylandyet.com/ Are we Wayland yet?]
* [https://awesomeopensource.com/projects/wayland Awesome Wayland projects]
* [[カーソルテーマ]]
* [https://bbs.archlinux.org/viewtopic.php?id=107499 Arch Linux forum discussion]
* [https://github.com/swaywm/sway/wiki/i3-Migration-Guide#common-x11-apps-used-on-i3-with-wayland-alternatives i3 Migration Guide - Common X11 apps used on i3 with Wayland alternatives]
* [https://wayland.app/protocols/ Wayland Explorer - A better way to read Wayland documentation]
* [https://askubuntu.com/questions/1393618/how-can-i-tell-if-an-application-is-using-xwayland How can I tell if an application is using XWayland]

{{TranslationStatus|Wayland|2024-08-24|814878}}

アクセシビリティ

2025-04-03T16:59:38Z

Oech3: /*アクセシビリティの無効化*/

[[Category:アクセシビリティ]]
[[en:Accessibility]]
身体的または視覚的なハンディキャップを持っているユーザーのためにアクセシビリティを提供する方法は様々なものがあります。しかしながら、[[デスクトップ環境]]を使わない場合、きちんと使えるようにするまで設定に多少の手直しが必要になります。

== デスクトップ環境 ==

最近のデスクトップ環境は拡張機能のセットが付いており、その中にアクセシビリティのオプションを設定するツールも入っています。大抵は、'アクセシビリティ'とかそれぞれの入力デバイス (例: 'キーボード'や'マウス') の設定にオプションが存在します。

{{Note|デスクトップ環境の設定ツールを使用する場合、デスクトップ環境に非依存のツールと設定が衝突する可能性があります。}}

== 身体支援 ==

音声認識については、[[音声認識]]を見て下さい。

=== キーボードの操作 ===

点字については、[[TalkingArch]] を見て下さい。

==== コンソール ====

===== スティッキーキー =====

TTY でスティッキーキーを有効にするには、使用するキーのキーコードを知る必要があります。キーコードは {{Pkg|xorg-xev}} や {{Pkg|xkeycaps}} などのツールで確認することが可能です。または、(現在のキーマップが正しければ) ''dumpkeys'' の出力を調査することもできます。

例えば、Logitech Ultra-X における修飾キーのキーコードは以下の通りです:
LCtrl = 29
LShift = 42
LAlt = 56
RShift = 54
RCtrl = 97

次に、''dumpkeys'' を使ってキーコードの範囲を確認します:
# dumpkeys | head -1
keymaps 0-63

適当な名前 (例: "stickyKeys") で新しいファイルを作成して、好きなエディタを使って先に確認した情報と必要なキーの機能を組み合わせます。

上に書かれたキーコードの場合、以下のようになります:
keymaps 0-63
keycode 29 = SCtrl
keycode 42 = SShift
keycode 56 = SAlt
keycode 54 = SShift
keycode 97 = SCtrl

ここで、修飾キーの前の "S" という文字はそのキーのスティッキーバージョンを使用することを示しています。

{{Note|以下の手順は全ての TTY のキーマッピングが変更されます。キーコードが正しいことを確認してください。間違っていると重要なキーが使えなくなる可能性があります。}}

次のコマンドを実行して新しいマッピングをロード:
# loadkeys ./stickyKeys

結果に満足したら、適当なディレクトリにファイルを移動して、起動時にロードされるようにします。上記のコマンドを {{ic|/etc/rc.local}} に記述するか (古い方法)、または [[systemd]] のサービスを使います (推奨される方法)。

systemd の場合、サービスファイルは以下のようになります:
[Unit]
Description="load custom keymap (sticky keys)"

[Service]
Type=oneshot
ExecStart=/usr/bin/loadkeys /path/to/stickyKeys
StandardInput=tty
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target emergency.target rescue.target

最後にファイル (例: {{ic|loadkeys.service}}) を {{ic|/usr/lib/systemd/system/}} に移動して次を実行して有効にします:
# systemdctl enable loadkeys

==== グラフィカル環境非依存 ====

One method of enabling desktop environment-independent accessibility function is by passing it through X, given that it is build with XKB support. This can be done by setting parameters for the X server, as specified in its man page:
[+-]accessx [ timeout [ timeout_mask [ feedback [ options_mask ] ] ] ]
enables(+) or disables(-) AccessX key sequences (Sticky Keys).

-ardelay milliseconds
sets the autorepeat delay (length of time in milliseconds that
a key must be depressed before autorepeat starts).

-arinterval milliseconds
sets the autorepeat interval (length of time in milliseconds
that should elapse between autorepeat-generated keystrokes).

上記のパラメータは {{ic|~/.xserverrc}} ファイルに記述してください (ファイルは作成する必要があるかもしれません)。

For example, to enable Sticky Keys without timeout and without audible or visible feedback, the following can be used:
if [ -z "$XDG_VTNR" ]; then
exec /usr/bin/X -nolisten tcp "$@" +accessx 0 0x1e 0 0xcef
else
exec /usr/bin/X -nolisten tcp "$@" vt$XDG_VTNR +accessx 0 0x1e 0 0xcef
fi

Note that once X has started, e.g. by executing {{ic|startx}}, it still requires you to press the shift key 5 times to enable Sticky Keys. Unfortunately, this is needed each time X starts. Alternatively, a script can be used to automate this process.

Similar to most implementations, Sticky Keys can be disabled by pressing a modifier key and any other key at the same time.

=== マウスの操作 ===

==== グラフィカル環境非依存 ====

===== ボタンのマッピング =====

''xmodmap'' を使うことで、グラフィカル環境に依存しない形でマウスボタンに機能をマッピングすることができます。その場合、{{Pkg|xorg-xev}} などのツールによってマウスの物理的なボタンがどのように認識されて読み込まれているのか確かめる必要があります。通常、左・中・右の物理ボタンが順番に読み込まれます。

Once you have acquired these, continue by creating a configuration file on a suitable location, e.g. {{ic|~/.mousekeys}}. Next, open the file with your favourite editor, and write the keyword {{ic|1=pointer = }} followed by an enumeration of the previously-found number of mouse buttons.

For example, a three button mouse with a scroll wheel is able to provide five physical actions: left, middle, and right click, as well as scroll up and scroll down. This can be mapped to the same functions by using the following line in the configuration file:
pointer = 1 2 3 4 5

Here, the location will tell the action required to perform an internal mouse-button function. For example, a mapping for left-handed people (left- and right button switched) might look like
pointer = 3 2 1 4 5

設定が完了したら {{ic|xmodmap}} を実行してマッピングをテストできます:
$ xmodmap ~/.mousekeys
$ xmodmap -pp

設定に満足したら、{{ic|~/.xinitrc}} に上記の最初の行を記述することで起動時に有効にできます。

== 視覚支援 ==

身体支援と同じように、最近のデスクトップ環境にはシステムの視覚的な部分を調整できる拡張機能のセットがあります。大抵は、'アクセシビリティ'や'視覚支援'というようなところにオプションがあります。また、個別のアプリケーションの設定に有用なオプションがある場合もあります。

=== テキスト読み上げ ===

[[音声認識|テキスト読み上げ]]を見て下さい。

=== コンソールと仮想ターミナルエミュレータ ===

* {{ic|/etc/vconsole.conf}} を編集。
* {{ic|~/.Xresources}} を編集。

== 問題 ==

* [[Wine]], [[VirtualBox]], [[QEMU]] など、ソフトウェアレイヤーを迂回するソフトウェアは入力デバイスの設定を認識しません。

== アクセシビリティの無効化 ==

アクセシビリティが不要で、少しでもプロセスを節約したければ、
{{ic|1=NO_AT_BRIDGE=1}}と{{ic|1=GTK_A11Y=none}}を設定し、
{{ic|systemctl --user mask at-spi-dbus-bus}}を実行します。

Chromium

2025-04-03T16:46:43Z

Oech3: XDG_CACHE_HOME/* tmpfs にキャッシュ */

[[Category:ウェブブラウザ]]
[[Category:Google]]
[[de:Chromium]]
[[en:Chromium]]
[[zh-hans:Chromium]]
{{Related articles start}}
{{Related|ブラウザ拡張機能}}
{{Related|Firefox}}
{{Related|Vivaldi}}
{{Related articles end}}

[[Wikipedia:ja:Chromium|Chromium]] は、[[Wikipedia:ja:Blink (レンダリングエンジン)|Blink]] レンダリングエンジンをベースとした、オープンソースなグラフィカルウェブブラウザです。プロプライエタリな Google Chrome ブラウザの基礎となっています。

Chromium と Google Chrome との違いについては [https://chromium.googlesource.com/chromium/src/+/master/docs/chromium_browser_vs_google_chrome.md このページ] を見てください。さらに:

* 同期は Chromium 89 以上 (2021-03-02) で利用できません。[https://archlinux.org/news/chromium-losing-sync-support-in-early-march/]

{{Note|同期は、[https://gist.github.com/foutrelis/14e339596b89813aa9c37fd1b4e5d9d5 Chrome の OAuth2 認証情報を使用する]か、[https://www.chromium.org/developers/how-tos/api-keys 自分の認証情報を取得する]ことで一時的に利用可能にできますが、免責事項に注意し、この方法を長期的な解決策と考えないでください。
長期的な解決策としては、ブックマークの同期するための [https://www.xbrowsersync.org xbrowsersync] に移行することを検討してください。}}

他の Chromium ベースのブラウザは [[アプリケーション一覧/インターネット#Blink ベース]] を見てください。

== インストール ==

Chromium を[[インストール]]できるパッケージがいくつか存在します:

* {{Pkg|chromium}} — 安定版
* {{AUR|chromium-dev}} — 開発版
* {{AUR|chromium-snapshot-bin}} — nightly ビルド

Google Chrome のパッケージは:

* {{AUR|google-chrome}} — 安定版
* {{AUR|google-chrome-beta}} — ベータ版
* {{AUR|google-chrome-dev}} — 開発版
* {{AUR|google-chrome-canary}} — カナリアリリース

{{Note|[https://www.chromium.org/Home/chromium-privacy Chromium プライバシーページ]によると(日本語訳):「Chromium のソースコードをコンパイルすることで利用可能になる Google と通信する機能は、[https://www.google.com/policies/privacy/ Google プライバシーポリシー]に従います。」Google サービスとの統合をすべて避けたい人向けに[[アプリケーション一覧/インターネット#プライバシー重視の chromium 派生版|プライバシー重視の Chromium 派生版]]があります。}}

== 設定 ==

=== デフォルトアプリケーション ===

Chromium をデフォルトのブラウザに設定したり、ダウンロードしたファイルを開くときに Chromium がどのアプリケーションを起動するかを変更したりするには、[[デフォルトアプリケーション]] を見てください。

=== 証明書 ===

Chromium は証明書の管理に [[Network Security Services]] を使っています。{{ic|chrome://settings/certificates}} で証明書を管理できます。

=== フラグを永続化する ===

{{Note|{{ic|chromium-flags.conf}} ファイルとそれに付随するカスタムランチャースクリプトは、Arch Linux の様々な Chromium パッケージに固有のものです。Google Chrome に対しては、代わりに {{ic|chrome-flags.conf}} (開発版やベータ版の場合は {{ic|chrome-''チャネル名''-flags.conf}}) を使用してください。}}

フラグは、{{ic|$HOME/.config/}} 内 ({{ic|$XDG_CONFIG_HOME}} 環境変数を設定した場合は、その環境変数が示すディレクトリの中) の {{ic|chromium-flags.conf}} ファイルに記述することができます。グローバルに設定したい場合は、{{ic|/etc/}} 内に配置できます。

特別な構文は使用されず、フラグはターミナルに書き込まれるのと同じように定義されます。

* 引数は空白で分割され、シェルの引用符の規則が適用されますが、それ以上の解析は実行されません。
* ファイル中のどこかが不適切に引用符によって囲まれている場合、致命的なエラーが発生します。
* フラグは読みやすくするために個別の行に分けることができますが、これは必須ではありません。
* ハッシュ記号 (#) で始まる行は読み飛ばされます。(これは Chromium のランチャースクリプトでのみサポートされており、Google Chrome を使用している場合は動作しません。)

以下は、フラグ {{ic|--start-maximized --incognito}} を定義している {{ic|chromium-flags.conf}} ファイルの例です:

{{hc|~/.config/chromium-flags.conf|
# この行は無視されます。
--start-maximized
--incognito
}}

=== GPU アクセラレーションを強制する ===

少なくとも Chromium 110 から、ほとんどのシステムに対して GPU アクセラレーションがデフォルトで有効化されています。あなたのシステム構成が[https://chromium.googlesource.com/chromium/src/gpu/+/master/config/software_rendering_list.json ブラックリスト]と合致する場合、以下のフラグを[[#フラグを永続化する|永続的な設定]]に[[追加]]する必要があります:

{{Warning|レンダリングブラックリストを無効化すると、ホストのクラッシュなどの不安定な挙動を引き起こすかもしれません。詳細については {{ic|chrome://gpu}} にあるバグレポートを見てください。}}

{{hc|~/.config/chromium-flags.conf|
--ignore-gpu-blocklist
--enable-zero-copy
}}

=== ハードウェアビデオアクセラレーション ===

{{Note|1=<nowiki/>
* この機能に対する Chromium や Arch Linux からの公式サポートはありません [https://chromium.googlesource.com/chromium/src/+/master/docs/gpu/vaapi.md#vaapi-on-linux]。しかし、公式リポジトリの {{Pkg|chromium}} は VA-API サポートありでコンパイルされており、[https://bbs.archlinux.org/viewtopic.php?id=244031 専用のフォーラムスレッド]で助けを求めることができます。
* Chromium バージョン 122 から、追加の [[VA-API]] のパッケージはもはや必要なくなりました。公式リポジトリの {{Pkg|chromium}} パッケージでネイティブな Wayland バックエンドを使用している場合、VA-API は動作します。
* AMD GPU デバイス上では、VA-API は[https://crbug.com/1445074 そのままでは動作しません]。動作させるには mesa >= 24.1 が必要であり、[https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26165 Vulkan を有効化する]必要があります。これによって、X11/XWayland で WebGL の問題が発生する場合があります。[[#ネイティブ Wayland サポート|ネイティブ Wayland サポートでの]] Vulkan はバージョン 125.0.6422.141-1 から動作します。
}}

{{Note|1=<nowiki/>
{{ic|chromium-flags.conf}} の適切なフラグの組み合わせを見つけようとしているのであれば、このファイルには {{ic|--enable-features}} や {{ic|--disable-features}} で始まる行はそれぞれ多くとも1行しか含むことができないことに注意してください。複数の機能はコンマで繋げることができます。
}}

{{ic|1=vainfo}} ([[ハードウェアビデオアクセラレーション#VA-API の確認]] を参照) の出力を見て VA-API のサポートがあることを確認した場合は、ひとまず以下のフラグだけで試してみてください:

{{hc|~/.config/chromium-flags.conf|2=
--enable-features=AcceleratedVideoDecodeLinuxGL
}}

{{Note|バージョン 131 より前の Chromium では、上記のフラグではなく {{ic|1=--enable-features=VaapiVideoDecodeLinuxGL}} を使用する必要があります。}}

それ以外の場合は、以下も読んでください。

Chromium でアクセラレートされた'''エン'''コードを有効化するには:

* {{ic|AcceleratedVideoEncoder}} を features に追加してください (例: {{ic|1=--enable-features=AcceleratedVideoDecodeLinuxGL,AcceleratedVideoEncoder}})。詳細は、[https://github.com/chromium/chromium/blob/main/docs/gpu/vaapi.md#vaapi-on-linux] と [https://issues.chromium.org/issues/40225939#comment54] を読んでください。

VA-API サポートを有効にするには:

* 使用中のビデオカード用の適切な VA-API ドライバをインストールしてください。そして、VA-API が有効化されて正常に動作していることを確認してください。[[ハードウェアビデオアクセラレーション]]を見てください。プロプライエタリな NVIDIA サポートは、{{Pkg|libva-nvidia-driver}} をインストールする必要があります。
* {{ic|1=--enable-features=VaapiVideoDecoder}} オプションを設定してください。ANGLE GL レンダラーと {{Pkg|libva-intel-driver}} を使用している場合は、これで十分です。
* ANGLE を使用すると、{{Pkg|intel-media-driver}} が使用されている場合、Chromium は古い i965 ドライバを強制的に使用し失敗します。回避策として、[[ハードウェアビデオアクセラレーション#VA-API の設定|VA-API を手動で設定]]してください。詳細については [https://github.com/intel/media-driver/issues/818] を見てください。
* Xorg か Wayland でシステムの GL レンダラを使用するには、{{ic|1=--use-gl=egl}} を使用してください。Chrome 112 を使用している場合、このオプションはもはや必要ないかもしれず、AMD GPU を使用している場合は GPU アクセラレーションの機能が壊れる場合があります。
* VA-API がまだ動かない場合は、{{ic|1=--enable-features=VaapiIgnoreDriverChecks}} か {{ic|1=--disable-features=UseChromeOSDirectVideoDecoder}} フラグを試してください。
* VA-API が Xorg と古い GPU 上でまだ動かない場合は、{{ic|1=LIBVA_DRI3_DISABLE=1}} [[環境変数]]を設定してください [https://www.phoronix.com/news/VA-API-libva-2.18]。

==== Vulkan ====

Vulkan を使用する場合、以下のフラグが必要で、Chromium 126 と Mesa 24.1 ではこれで十分でしょう:

{{hc|~/.config/chromium-flags.conf|2=
--enable-features=VaapiVideoDecoder,VaapiIgnoreDriverChecks,Vulkan,DefaultANGLEVulkan,VulkanFromANGLE
}}

先述の追加のフラグは入れないでください。

==== ヒントとテクニック ====

{{Out of date|
* Wayland + RADV の環境では Chromium は AV1 に VaapiVideoDecoder を使用します。
* Wayland + RADV の環境では Chromium は全てのサイスの動画に VaapiVideoDecoder を使用します。
}}

使用中の VA-API ドライバでサポートされているコーデックの動画の視聴がうまく行くかどうか確認するには (''vainfo'' はどのコーデックがサポートされているかを表示しますが、Chromium は VP9 と h264 だけをサポートします):

* {{ic|Ctrl+Shift+I}} を押すか、コンテキスト (右クリック) メニューの ''検証'' ボタンを押して DevTools を開いてください
* Media inspection タブを追加してください: ''ハンバーガーメニュー(︙) > More tools > Media''
* 新しく開いた Media タブで、Video Decoder の Hardware decoder の状態を見てください。

十分に大きな動画でテストしてください。バージョン 86 から、デスクトップ版の Chromium は [https://bugs.chromium.org/p/chromium/issues/detail?id=684792 720p よりも大きい動画でしかアクセラレーションを使用しません]。

VP8/VP9 ハードウェアデコードが使用できない Youtube 動画を視聴しているときに CPU 使用率を減らすには、[https://chrome.google.com/webstore/detail/h264ify/aleakchihdccplidncghkekgioiakgal h264ify] や [https://chrome.google.com/webstore/detail/enhanced-h264ify/omkfmpieigblcllmkgbflkikinpkodlk enhanced-h264ify]、[https://chrome.google.com/webstore/detail/not-yet-av1/dcmllfkiihingappljlkffafnlhdpbai Not yet, AV1][https://bbs.archlinux.org/viewtopic.php?pid=2039884#p2039884] 拡張機能を使用してください。

一部のシステム (特に Xwayland) では、[[#GPU アクセラレーションを強制する]] 必要があるかもしれません。このセクションでの目的に対しては {{ic|--ignore-gpu-blocklist}} のみで十分です。

Skia レンダラーは、現在ビデオデコードアクセラレーションと互換性がないので、無効化する必要があるかもしれません: {{ic|1=--disable-features=UseSkiaRenderer}}

=== KDE 統合 ===

[[Plasma]] との統合は {{Pkg|plasma-browser-integration}} を[[インストール]]してください。詳細は [https://community.kde.org/Plasma/Browser_Integration KDE Plasma Browser Integration] を見てください。

=== PDF ビューアプラグイン ===

Chromium と Google Chrome には ''Chromium PDF Viewer'' プラグインがバンドルされています。このプラグインを使用したくない場合は、{{ic|chrome://settings/content/pdfDocuments}} 内の ''Download PDFs'' を確認してください。

=== Xwayland での動作 ===

NVIDIA 社のプロプライエタリドライバを使用している場合、Xwayland 上で Chromium を実行すると、GPU プロセスが時々クラッシュすることがあります。GPU プロセスがクラッシュしないようにするには、以下のフラグを追加してください:

--use-angle=vulkan --use-cmd-decoder=passthrough

{{Note|これはすべての Xwayland 関連のクラッシュを防止するわけではありません。}}

=== ネイティブ Wayland サポート ===

バージョン 97 以降、Chromium でのネイティブ [[Wayland]] サポートは、次のフラグを使用して有効にできます [https://chromium.googlesource.com/chromium/src/+/43cfb2f92a5cdc1a787d7326e74676884abf5052]:

--ozone-platform-hint=auto

これがうまくいかない場合 (例えば [[Weston]] バージョン 106 以下の場合)、次を使ってください:

--ozone-platform=wayland

永続的な設定については [[#フラグを永続化する]] を参照してください。このフラグは[[#chrome:// URL|ブラウザのフラグメニュー]]からも設定できます。

この設定により、wayland セッション内では wayland Ozone バックエンドが選択されます。なので、X11 と Wayland を頻繁に切り替える場合でも、デスクトップエントリは一つだけで大丈夫です。

{{Note|ブラウザのフラグメニューで "ozone-platform-hint" を変更すると、ブラウザが再起動ボタンを表示させます。しかし、これは使用しないでください。ブラウザは、フラグが変更される前のプラットフォームで再起動されるからです。ブラウザを閉じて、その後、再び開く必要があります。}}

追加で、[https://bugs.chromium.org/p/chromium/issues/detail?id=1422087 インプットメソッドの問題]が発生している場合は、新しい GTK を強制すると良いかもしれません:

--gtk-version=4

Fcitx5 を使用していて上記のフラグを使うと正しく動作しない場合は、{{ic|1=--gtk-version=4}} の代わりに {{ic|--enable-wayland-ime}} フラグを使用してみてください。[https://fcitx-im.org/wiki/Using_Fcitx_5_on_Wayland#Chromium_.2F_Electron]

--enable-wayland-ime --wayland-text-input-version=3

{{Note|{{ic|text_input_v1}} プロトコルがデフォルトで実装されている場合、{{ic|--enable-wayland-ime}} フラグは機能します。このプロトコルを実装している既知のコンポジタは Weston、KWin、Hyprland です。}}

==== ナビゲーションのタッチパッドジェスチャ ====

2本の指でスワイプすると戻ったり進んだりする機能を有効にするには、以下のフラグを使用してください:

--ozone-platform-hint=auto --enable-features=TouchpadOverscrollHistoryNavigation

== ヒントとテクニック ==

特に注意書きがなければ以下のヒントとテクニックは Chromium と Chrome の両方で使うことができます。

=== ブラウズのエクスペリエンス ===

==== chrome:// URL ====

多くの調整は Chrome の URL からアクセスすることができます。完全なリストは '''chrome://chrome-urls''' を参照してください。

* '''chrome://flags''' - WebGL などの実験的な機能や GPU によるウェブページのレンダリングなどにアクセスできます。
* '''chrome://extensions''' - 現在使用している Chromium 拡張を表示・有効化・無効化。
* '''chrome://gpu''' - 様々な GPU オプションの状態。
* '''chrome://sandbox''' - サンドボックスの状態を表示。
* '''chrome://version''' - バージョンや {{ic|/usr/bin/chromium}} を実行するときに使われたスイッチを表示。

Chromium のスイッチ (コマンドラインパラメータ) の自動的に更新される完全なリストが [https://peter.sh/experiments/chromium-command-line-switches/ こちら] にあります。

==== Chromium タスクマネージャ ====

Shift+ESC でブラウザのタスクマネージャを立ち上げることができます。メモリや CPU、ネットワークの使用量が閲覧可能です。

==== Chromium が Preferences ファイルを上書き/オーバーライドしてしまう ====

Google アカウントの同期を有効にしている場合、{{ic|~/.config/chromium/Default/Preferences}} 下の Preferences ファイルに直接編集を加えていても Chromium によって上書きされてしまいます。上書きされないようにするには、{{ic|--disable-sync-preferences}} スイッチを付けて Chromium を起動してください:
$ chromium --disable-sync-preferences

デスクトップ環境のログイン時にバックグラウンドで Chromium を起動する場合、デスクトップ環境から使用するコマンドを以下のようにしてください:
$ chromium --disable-sync-preferences --no-startup-window

==== 検索エンジン ====

[https://wiki.archlinux.org wiki.archlinux.org] や [https://en.wikipedia.org wikipedia.org] などのウェブサイトは検索を実行してから ''Settings > Search'' を選択して ''Manage search engines..'' ボタンをクリックすることで簡単に検索できるように設定できます。エントリを "Edit" してキーワードを '''w''' などに変更してください (ショートカットは自由に決めて下さい)。これでアドレスバーに "'''w arch linux'''" と入力するだけで "Arch Linux" で検索できるようになります。

{{Note|URL バーに何か入力すると自動的に Google 検索が使われます。また、ハードコードされたキーワードトリガとして '''?''' プレフィックスが使えます。}}

==== Tmpfs ====

===== tmpfs にキャッシュ =====

{{Note|Chromium はブラウザのプロファイルディレクトリとキャッシュディレクトリを分離して保存します。}}

物理ディスクに対する Chromium のキャッシュの書き込みを制限したい場合、{{ic|--disk-cache-dir}} フラグでキャッシュの書き込み先を変更することができます:

$ chromium --disk-cache-dir="$XDG_RUNTIME_DIR/chromium-cache"

キャッシュは一時的になり、再起動したりハードロックすると'''消えます'''。もしくは、tmpfs 領域を {{ic|/etc/fstab}} 内でセットアップすることもできます:

{{hc|/etc/fstab|2=
tmpfs /home/''username''/.cache tmpfs noatime,nodev,nosuid,size=400M 0 0
}}

または、{{ic|/tmp}} へのシンボリックリンクを作成してください。以下のコマンドを実行する前に、Chromium のキャッシュフォルダは削除しておいてください:

$ ln -s /tmp /home/''ユーザ名''/.cache/chromium

また、全てのアプリケーションで有効な[[XDG_Base_Directory#ユーザーディレクトリ|XDG_CACHE_HOME]]もあります。

===== tmpfs にプロファイル =====

{{ic|/tmp}} や {{ic|/dev/shm}} などの [[Wikipedia:ja:Tmpfs|tmpfs]] ファイルシステムにプロファイルを保存することで、プロファイル全体が RAM 内に保存されるので、Chromium の応答性が改善されます。

{{Pkg|profile-sync-daemon}} などの、プロファイルを動的に管理するスクリプトを使うことで信頼性と使いやすさを最大限高めることができます。profile-sync-daemon はブラウザプロファイルのディレクトリのシンボリックリンクを作成し、定期的にメモリと同期をとります。詳細については [[Profile-sync-daemon]] の記事を参照して下さい。

==== 新しいブラウザインスタンスを起動 ====

ブラウザを起動すると、最初に同じプロファイルを使っているインスタンスが他にないか確認されます。存在する場合、新しいウィンドウは既存のインスタンスに関連付けられます。以下のように {{ic|--user-data-dir}} パラメータを使って起動することで別のプロファイルでブラウザを起動できます:

$ chromium --user-data-dir=''/path/to/some/directory''

{{Note|ユーザーデータのデフォルトパスは {{ic|~/.config/chromium/}} です。}}

==== torrent クライアントで *.torrent ファイルやマグネットリンクを直接開く ====

デフォルトでは Chromium は {{ic|*.torrent}} ファイルを直接ダウンロードするため、ファイルを torrent クライアントで開くには画面左下の通知をクリックする必要があります。以下の方法で毎回クリックする手間を省けます:

* {{ic|*.torrent}} ファイルをダウンロード。
* 画面左下に表示される通知を右クリック。
* "Always Open Files of This Type" チェックボックスにチェックを入れる。

デフォルトの関連付けの変更については [[xdg-open]] を見てください。

==== タッチスクリーンデバイスでタッチスクロール ====

使用するタッチデバイスを指定する必要があります。タッチスクリーンデバイスを {{ic|xinput list}} で確認して、{{ic|1=--touch-devices='''x'''}} パラメータを付けて Chromium を起動してください ("'''x'''" はデバイスの id に置き換えてください)。
{{Note|スレーブポインタのデバイスは使えません。マスターポインタの ID を使ってください。}}

==== メモリの使用量を減らす ====

デフォルトでは、Chromium は開いているウェブサイトの数だけ OS プロセスを作成します [https://www.chromium.org/developers/design-documents/process-models#Supported_Models]。Chromium の起動時にコマンドラインスイッチを指定することで挙動を変更することが可能です。

例えば、全てのウェブサイトでひとつのプロセスを共有するには:

$ chromium --process-per-site

シングルプロセスモデルを使うには:

$ chromium --single-process

{{Warning|シングルプロセスモデルは安全でなく他のモデルに存在しないバグが含まれている可能性があるため推奨されていません [https://www.chromium.org/developers/design-documents/process-models#TOC-Single-process]。}}

さらに [https://chrome.google.com/webstore/detail/tab-suspender/fiabciakcmgepblmdkmemdbbkilneeeh?hl=en Tab Suspender] や [https://chrome.google.com/webstore/detail/onetab/chphlpgkkbolifaimnlloiipkdnihall?hl=en OneTab] などの拡張を使うことでアクティブでないタブを停止・保存することができます。

==== ユーザーエージェント ====

Chromium の起動時に {{Ic|<nowiki>--user-agent="[string]"</nowiki>}} パラメータを指定することでユーザーエージェントは任意に変更することができます。

==== DOM Distiller ====

Chromium には Firefox にあるのと似たレンダリングモードが存在します。これは DOM Distiller と呼ばれ、[https://github.com/chromium/dom-distiller オープンソースプロジェクト]です。
デフォルトでは無効化されていますが、{{Ic|chrome://flags/#enable-reader-mode}} フラグを使用することにより有効化できます。このフラグは[[#フラグを永続化する|永続化]]させることができます。
DOM Distiller は、ページのコンテンツから不要なものを取り除くことでより良いレンダリングエクスペリエンスを提供するだけでなく、印刷用にページを単純化してくれます。後者のチェックボックスオプションが印刷ダイアログから削除されたものの、不要なものを取り除いたページを印刷することは依然として可能です。これらには、基本的には同じ効果があります。

フラグを有効化すると、ウェブサイトから不要なものを取り除くことができると Chromium が判断したときに、"Enter reader mode" メニューアイテムとアイコンがアドレスバーに出現します。

==== 特定の GPU の使用を強制する ====

GPU が複数ある環境の場合、Chromium はレンダリングに使用する GPU (ディスクリートや統合 GPU) を自動的に検出します。99% は問題ありませんが、誤った GPU が選択された場合 (VFIO GPU パススルー環境でディスクリートグラフィックが選ばれるなど)、{{ic|chrome://gpu}} は GPU プロセスを初期化できないというエラーを吐きます。同じページの '''Driver Information''' には複数の GPU が表示されます (GPU0, GPU1, ...)。ユーザーフレンドリな方法で GPU を切り替えることはできませんが、デバイス/ベンダー ID を使って Chromium のフラグで使用する GPU を設定できます:

$ chromium --gpu-testing-vendor-id=0x8086 --gpu-testing-device-id=0x1912

{{ic|0x8086}} と {{ic|0x1912}} は使用したい GPU の ID に置き換えてください ({{ic|chrome://gpu}} ページで確認できます)。

==== Firefox からブックマークをインポート ====

[[Firefox]] から Chromium にブックマークをインポートすることができます。

Chromium で {{ic|chrome://settings/importData}} を開いてください。

コンピュータに Firefox がインストールされている場合、直接 Firefox からブックマークなどをインポートできます。

'''Mozilla Firefox''' を選択してください。不要なアイテムのチェックは外してかまいません。'''Import''' をクリックしてから '''Done''' をクリックすればインポートは完了です。

{{note|Chromium でまだ何もブックマークを作成していない場合、ブックマークバーにブックマークが表示されます。既にブックマークが存在する場合、ブックマークは "Imported From Firefox" というラベルが付いた新しいフォルダに保存されます。}}

他の PC からブックマークをインポートする場合、先に Firefox からブックマークをエクスポートする必要があります。

Firefox で {{ic|Ctrl+Shift+o}} ''Import and Backup > Export Bookmarks To HTML'' を選択してください

後の作業は同じです。{{ic|chrome://settings/importData}} を開いてください。ただし今度は '''From''' ドロップダウンメニューで '''Bookmarks HTML File''' を選択して '''Choose File''' ボタンをクリックしてブックマークファイルをアップロードします。

後の作業は同じです。{{ic|chrome://settings/importData}} を開いてください。ただし今度は '''From''' ドロップダウンメニューで '''Bookmarks HTML File''' を選択して '''Choose File''' ボタンをクリックしてブックマークファイルをアップロードします。

==== ネイティブ通知の有効化 ====

{{ic|chrome://flags#enable-system-notifications}} を開いて、''Enabled'' を選択してください。

==== マウスの中ボタンでの自動スクロールを有効化する ====

自動スクロールはまだ試験的な機能です [https://niek.github.io/chrome-features/]。開発版ビルドでない Chromium または Chromium ベースのブラウザで、Linux 環境で動作させている場合は、デフォルトで無効化されています。[https://issues.chromium.org/issues/40811836]

この機能を有効化するには、ブラウザを {{ic|1=--enable-features=MiddleClickAutoscroll}} フラグで起動してください。このオプションを永続化させたい場合は、[[#フラグを永続化する]] を見てください。

{{Note|
* {{ic|--enable-blink-features}} は {{ic|--enable-features}} と同じように動作しますが、ブラウザが、このフラグはサポートされておらず、安定性とセキュリティが損なわれると警告を表示することがあります。
* 代替策として Chrome Web Store から似たような機能を持つ [https://chromewebstore.google.com/detail/wheely-wheel-scroll-for-l/kkmfljfnlmppiaoijkfaejgkhccokpdn WHEELY] のような拡張機能を追加することもできます。
}}

{{Tip|もう一つの手段は、{{AUR|chromium-extension-autoscroll}} です。しかし、このパッケージは古くなっており、公式ではないため、推奨されていません。使用する場合は注意してください。}}

==== U2F 認証 ====

{{Pkg|libfido2}} ライブラリをインストールしてください。このパッケージは、(通常) ユーザとして [[U2F]] キーにアクセスできるようにするために必要な udev ルールを提供します。
U2F キーはデフォルトでは root としてしかアクセスできないので、これらのルールが無いと Chromium はエラーを吐きます。

==== テーマ ====

Chromium に現在の GTK テーマをブラウザメニューやコントロールで使用させることができます。{{ic|chrome://settings/appearance}} で ''Use GTK'' を押してください。

==== ダークモード ====

Chromium 114 から、ユーザの優先外観を自動的に決定するために [[XDG デスクトップポータル]] が使用されるようになりました ([https://bugs.chromium.org/p/chromium/issues/detail?id=998903 issue])。よって、ダークモードの有効化とユーザの GTK テーマが切り離されました。この設定は、CSS、JavaScript、設定、そして Dev-Tools の ''prefers-color-scheme'' に適用されます。

優先外観を変更する方法は、XDG Desktop Portal バックエンドに依存します。例えば、多くのデスクトップ環境はそれぞれの外観設定インターフェイスにモードを切り替えるスイッチを提供しています。または、例えば {{Pkg|xdg-desktop-portal-gtk}} 場合は、以下のコマンドを使って優先モードを {{ic|prefer-light}} や {{ic|prefer-dark}}、{{ic|default}} に設定します:

$ dconf write /org/gnome/desktop/interface/color-scheme \'prefer-dark\'

{{Pkg|dbus}} の {{ic|dbus-send}} を使用することで、現在の優先外観をクエリできます ([https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Settings ドキュメント]):

$ dbus-send --session --print-reply=literal --dest=org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Settings.Read string:org.freedesktop.appearance string:color-scheme | tr -s ' ' | cut -d ' ' -f 5

* '''0''': 設定無し
* '''1''': ダークモードを優先
* '''2''': ライトモードを優先

===== Chromium 114 より前 =====

ダークモードを有効化し、ダークテーマ (通常、incognito モードで使用されます) を有効化するには、以下のフラグを[[#フラグを永続化する|永続的な設定]]に[[追加]]してください:

{{hc|1=~/.config/chromium-flags.conf|2=
--force-dark-mode
--enable-features=WebUIDarkMode
}}

==== サイドパネルを有効化する ====

サイドパネルは {{ic|chrome://flags}} から有効化できます。'''Side panel''' を有効化/無効化することができ、'''Side panel border''' や '''Side panel drag and drop''' といったオプションを変更できます。

=== プロファイルのメンテナンス ===

Chromium は [[Sqlite]] データベースを使用して履歴やお気に入りを管理しています。Sqlite データベースは使っているうちに断片化していきます。しかしながら、データベースをチェックしたり最適化するプロセスが存在しないため、断片化によって段々とパフォーマンスに影響が出て来ます。デフラグを行ってデータベースから未使用領域を削除することで、起動時間やブックマークや履歴に関連する作業を素早く実行することができます。

{{Pkg|profile-cleaner}} と {{AUR|browser-vacuum}} でメンテナンスができます。

=== セキュリティ ===

==== JIT を無効化 ====

[https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ JS エンジンにおけるセキュリティ上の脆弱性のうち約半分]は JIT に原因があります。パフォーマンスが劣化しますが、{{ic|1=--js-flags=--jitless}} フラグを使用することで、JavaScript からネイティブなコードへの just-in-time コンパイルを無効化できます。

==== WebRTC ====

WebRTC は JavaScript を使用する通信プロトコルですが、VPN を使っている場合でもマシンの IP アドレスやハードウェアのハッシュ値が漏洩する可能性があります。VPN ソフトウェアによってはスクリプトの実行が阻止されることもありますが、プロトコルを直接ブロックしてしまう方が安全です。2016年10月現在、デスクトップ版 Chromium で WebRTC を無効化する方法はありませんが、ローカル IP アドレスの漏洩を阻止する拡張が存在します。そのひとつがこの[https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia 拡張機能]です。

WebRTC は https://browserleaks.com/webrtc でテストできます。

{{Warning|IP の漏洩は防げても、Chromium はユニークなハッシュを送信しており、それを止める方法はありません。詳しくは https://www.browserleaks.com/webrtc#webrtc-disable を読んでください。}}

==== SSL 証明書 ====

Chromium には SSL 証明書マネージャが存在しません。Chromium は NSS の共有データベース {{ic|~/.pki/nssdb}} を使用しています。データベースに SSL 証明書を追加するには、シェルを使う必要があります。

===== 自己署名証明書の CAcert 証明書を追加 =====

CAcerts を取得して {{ic|nssdb}} を作成してください (存在しない場合)。作成するには {{Pkg|nss}} パッケージをインストールして以下を実行する必要があります:

$ mkdir -p $HOME/.pki/nssdb
$ cd $HOME/.pki/nssdb
$ certutil -N -d sql:.

$ curl -k -o "cacert-root.crt" "http://www.cacert.org/certs/root.crt"
$ curl -k -o "cacert-class3.crt" "http://www.cacert.org/certs/class3.crt"
$ certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "CAcert.org" -i cacert-root.crt
$ certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "CAcert.org Class 3" -i cacert-class3.crt

{{Note|データベースのパスワードを作成していない場合、作成する必要があります。}}

これでユーザーは手動で自己署名証明書をインポートできるようになります。

===== 例 1: シェルスクリプトを使って TomatoUSB から証明書を分離 =====

以下は証明書を展開してユーザーの {{ic|nssdb}} に追加するシンプルなスクリプトです:

#!/bin/sh
#
# usage: import-cert.sh remote.host.name [port]
#
REMHOST=$1
REMPORT=${2:-443}
exec 6>&1
exec > $REMHOST
echo | openssl s_client -connect ${REMHOST}:${REMPORT} 2>&1 |sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n "$REMHOST" -i $REMHOST
exec 1>&6 6>&-

使用方法はコメント化されている行を見てください。

参照:
*https://web.archive.org/web/20180718193807/https://blog.avirtualhome.com/adding-ssl-certificates-to-google-chrome-linux-ubuntu
*https://chromium.googlesource.com/chromium/src/+/master/docs/linux/cert_management.md

===== 例 2: Firefox を使って TomatoUSB から証明書を分離 =====

{{Pkg|firefox}} ブラウザを使って証明書をファイルに保存してデータベースに手動でインポートすることができます。

Firefox を使って:
#取得先の URL を開く。
#"This Connection is Untrusted" 警告画面が表示されたら ''I understand the Risks > Add Exception...'' をクリック。
#''View > Details > Export'' をクリックしてどこか一時的な場所に証明書を保存 (以下の例では {{ic|/tmp/easy.pem}} を使用)。

Chromium で使用する証明書をインポート:
$ certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "easy" -i /tmp/easy.pem

{{Note|名前は証明書にあわせて変更してください。上記の例では "easy" が証明書の名前です。}}

参照:
*https://sahissam.blogspot.com/2012/06/new-ssl-certificates-for-tomatousb-and.html

==== Canvas Fingerprinting ====

Canvas Fingerprinting は HTML5 の canvas のレンダリング結果の差異を使ってユーザーを識別する技術です。{{ic|--disable-reading-from-canvas}} フラグを使うことで Canvas Fingerprinting を使えないようにすることができます。

フラグが機能しているかどうか確認するには [https://panopticlick.eff.org こちらのテスト] を実行して "hash of canvas fingerprint" の結果を確認してください。

{{Note|1=<nowiki/>
* 一部の拡張機能は canvas からの読み込みを必要としており、{{ic|--disable-reading-from-canvas}} を設定すると壊れる場合があります。
* YouTube プレイヤーや Google マップは canvas からの読み込みができないと正しく動作しません ([https://github.com/qutebrowser/qutebrowser/issues/5345 Qutebrowser issue 5345]、[https://bbs.archlinux.org/viewtopic.php?id=255958 BBS#255958]、[https://bbs.archlinux.org/viewtopic.php?id=276425 BBS#276425] を参照)。
}}

==== プライバシー拡張 ====

[[ブラウザ拡張機能#プライバシー]] を参照してください。

{{Tip|あまりにも多くの拡張機能をインストールしてしまうと、ツールバーのスペースを圧迫してしまうかもしれません。ユーザと対話しない拡張機能は、拡張機能を右クリックして ''Hide in Chromium menu'' を選択することで隠すことができます。}}

==== Do Not Track ====

[[wikipedia:Do Not Track|Do Not Track]] を有効化するには、{{ic|chrome://settings}} を開き、''Advanced'' まで下へスクロールして、''Privacy and security'' の ''Send a "Do Not Track" request with your browsing traffic'' にチェックを入れてください。

==== 特定のパスワードストアを強制する ====

Chromium はパスワードストアを使ってパスワードと (cookie の値を暗号化するのに使われる) ''Chromium Safe Storage'' キーを保存します [https://codereview.chromium.org/24734007]。

デフォルトでは Chromium は使用するパスワードストアを自動的に認識しますが、デスクトップ環境やウィンドウマネージャを変えたときにパスワードと cookie が失われてしまう可能性があります。

{{ic|--password-store}} フラグで以下のどれかの値を指定して Chromium を起動することで特定のパスワードストアを強制的に使うようにすることができます [https://chromium.googlesource.com/chromium/src/+/master/docs/linux/password_storage.md]:

* {{ic|gnome-libsecret}} - [https://gitlab.gnome.org/GNOME/libsecret libsecret] 経由で [[Gnome Keyring]] を使用
* {{ic|kwallet5}} - [[KDE Wallet]] 5 を使用。
* {{ic|kwallet6}} - [[KDE Wallet]] 6 を使用。
* {{ic|basic}} - {{ic|Login Data}} ファイルにプレーンテキストとしてパスワードと cookie の暗号鍵を保存
* {{ic|detect}} - デフォルトの自動認識

例えば、Gnome Keyring を使うようにするには {{ic|1=--password-store=gnome-libsecret}} を付けてください。永続化する方法は [[#フラグを永続化する]] を参照。

他のデスクトップ環境のパスワードストアを使う場合、自動的にアンロックされるように設定すると良いでしょう。[[GNOME/Keyring#キーリングを使用する]] や [[KDE Wallet#ログイン時に KDE ウォレットを自動的にアンロック]] を参照。

==== ハイブリッドポスト量子鍵交換を有効化する ====

バージョン 155 から Chromium は、TLS 1.3 向けのハイブリッドポスト量子鍵交換 [https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html X25519Kyber768] をサポートしています [https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html]。この機能はデフォルトで無効化されていますが、{{Ic|chrome://flags/#enable-tls13-kyber}} フラグで有効化できます。

== トラブルシューティング ==

=== フォント ===

{{Note|Chromium は独自のサンドボックスを使っているため、fontconfig/GTK/Pango/X などと完全な統合がされていません。詳しくは [https://dev.chromium.org/developers/linux-technical-faq Linux Technical FAQ] を参照してください。}}

==== タブのフォントサイズが大きすぎる ====

[[GTK#設定]] で言及されているように、Chromium は GTK の設定を使用します。Chromium はタブに {{ic|gtk-font-name}} の設定を使用します (これにより、ウインドウのフォントサイズと合わなくなる場合があります)。この設定を上書きするには、{{ic|1=--force-device-scale-factor=1.0}} を使用してください。

Chrome Refresh 2023 がデフォルトになってから、Cantarell フォントを使用している GNOME で動かすとタブタイトル内の一部の文字 (小文字の g など) が切れてしまうことがあります。[https://issues.chromium.org/issues/40934082 chromium.org のイシュー]を参照してください。

この問題が解決するまでの回避策は、[[フォント設定#デフォルトまたは代替フォントを設定する]] に載っている設定を使って Cantarell から別のフォントに変えることです。例えば:

{{hc|~/.config/fontconfig/conf.d/10-chromium-font.conf|<nowiki>
<match target="pattern">
<test name="prgname" compare="eq">
<string>chromium</string>
</test>
<test qual="any" name="family">
<string>Cantarell</string>
</test>
<edit name="family" mode="assign" binding="strong">
<string>Ubuntu</string>
</edit>
</match>
</nowiki>}}

この設定は、プロセスの名前が {{ic|chromium}} にマッチする場合にのみ適用されます。Google Chrome に対しては {{ic|chrome}} としてください。

=== WebGL ===

使用中のグラフィックカードが Chromium のブラックリストに入っている可能性があります。[[#GPU アクセラレーションを強制する]] を見てください。

[[Bumblebee]] で Chromium を使っている場合、GPU のサンドボックスによって WebGL がクラッシュすることがあります。このようなときは、{{ic|optirun chromium --disable-gpu-sandbox}} で GPU のサンドボックスを無効にできます。

WebGL サポートのデバッグ情報は {{ic|chrome://gpu/}} を見てください。

Chromium はユーザプロファイルに GPU に関する誤った情報を保存することがあります。例えば、Optimus を使って Nvidia カードから Intel カードに切り替えた場合、たとえ Nvidia カードや primusrun/optirun を使用していなくても、{{ic|chrome://gpu}} に Nvidia カードが表示されます。異なるユーザデータディレクトリを使って実行することにより (例: {{ic|1=chromium --user-data-dir=$(mktemp -d)}})、この問題を解決できる場合があります。持続的な解決策として、{{ic|~/.config/chromium/Local\ State}} を削除して GPU の情報をリセットできます。

=== HiDPI の描画がおかしい ===

Chromium は自動的に [[HiDPI]] ディスプレイでの倍率設定を行います。しかし、これにより GUI の描画がおかしくなることがあります。

{{ic|1=--force-device-scale-factor=1}} フラグをを使用して、自動倍率設定を上書きできます。

[[#ネイティブ Wayland サポート|ネイティブの Wayland サポート]] が有効化されている場合、Chromium は、各モニタに設定された倍率を元に自動的に倍率を設定します。

=== GNOME Keyring を使用していると起動するたびにパスワードを要求される ===

[[GNOME/Keyring#パスワードが保存されない]] を見てください。

=== パスワードだけが同期されない ===

同期がパスワードに対してだけ機能しない場合 ({{ic|chrome://sync-internals/}} で確認できます)、プロファイルのログインデータを削除してください:

$ rm ~/.config/chromium/Default/Login\ Data*

詳細は [https://support.google.com/chrome/thread/9947763?hl=en&msgid=23687608 Google Chrome Help forum] を見てください。

=== デスクトップ環境を切り替えると cookie とパスワードが消える ===

Chromium を起動したときにターミナルに {{ic|Failed to decrypt token for service AccountId-*}} というメッセージが表示される場合、Chromium が間違ったパスワード保存バックエンドを使おうとしたのかもしれません。これはデスクトップ環境を切り替えたときに起こりえます。

[[#特定のパスワードストアを強制する]] を見てください。

=== Google Sync を有効化すると起動時に固まる ===

{{ic|1=--password-store=basic}} フラグを使うか、他の適切なパスワードストアを使って Chrome を起動してみてください。

[[#特定のパスワードストアを強制する]] を見てください。

=== デフォルトのブラウザとして設定するかを毎回尋ねてくる ===

KDE を使用していて、一度 Firefox を (Firefox 内のボタンをクリックして) デフォルトのブラウザとして設定したことがある場合、たとえ "デフォルトに設定" ボタンをクリックしたとしても、Chromium を起動するたびに毎回 Chromium をデフォルトのブラウザとして設定するかを尋ねられることがあります。

Chromium は {{ic|xdg-settings check default-web-browser chromium.desktop}} を実行することで chromium がデフォルトのブラウザであるかを確認します。そのコマンドの出力が "no" である場合、chromium がデフォルトのブラウザでないと認識します。{{ic|xdg-settings}} スクリプトは以下の MIME の関連付けを確認し、すべてが {{ic|chromium.desktop}} であることを期待します:

{{bc|
x-scheme-handler/http
x-scheme-handler/https
text/html}}

これを直すには、''システム設定 > アプリケーション > デフォルトのアプリケーション > Web browser'' を開いて、Chormium を指定してください。そして、{{ic|text/html}} の MIME の関連付けを設定してください:

$ xdg-mime default chromium.desktop text/html

最後に、[[XDG_MIME_Applications#新しい MIME タイプ|MIME のデータベースを更新]]してください:

$ update-mime-database ~/.local/share/mime

=== "このブラウザまたはアプリは安全でない可能性があります" Google へのログインエラー ===

2020年04月20日以降、Web 開発用に {{ic|1=--remote-debugging-port=9222}} フラグを指定して chromium を実行すると、 Google アカウントにログインできません。このフラグを一時的に無効にしてログインすると、再び有効にできます。

=== 60 FPS より高いリフレッシュレートのディスプレイを使用しているのに Chromium は 60 FPS で描画される ===

一般的な問題に関する上流のバグレポートは[https://bugs.chromium.org/p/chromium/issues/detail?id=1200167 ここ]にあり、その他の回避策が見つかるかもしれません。また、混合リフレッシュレートに関する問題は[https://bugs.chromium.org/p/chromium/issues/detail?id=1138080 ここ]で報告されています。

==== 混合リフレッシュレート ====

{{Tip|この問題は Wayland バックエンドには存在しない可能性があります。要検証。}}

混合リフレッシュレート (例えば 60 Hz と 144 Hz) のあるディスプレイを使用している場合、Chromium は最も低いリフレッシュレートのディスプレイに合わせて描画するかもしれません。

この問題に対する適切な回避策があります。以下のフラグを[[#フラグを永続化する|永続的な設定]]に[[追加]]してください:

{{hc|1=~/.config/chromium-flags.conf|2=
--use-gl=egl
--ignore-gpu-blocklist
--enable-gpu-rasterization
}}

これにより、コンポジタが 144 FPS でリフレッシュする場合、144Hz ディスプレイ上で使用すると Chromium が 144 FPS で実行されます。これにより、少しカクつくかもしれないことを留意してください {{Bug|67035}}。しかし、60 FPS で止まるよりはマシです。

==== Wayland バックエンドで実行する ====

この問題を引き起こす Wayland コンポジタ固有の問題があるようです。

特に、Plasma 5 は環境によらず 60Hz で描画されるようですが、Plasma 6 (この記事の時点では rc1) では Chromium が高いリフレッシュレートでも問題なく動作します。

その他の解決策がうまく行かなかった場合は、XWayland バックエンドに切り替えてみてください。

=== Chromium でスクロール速度が遅い ===

Chromium や Electron ベースのアプリケーションでマウスホイールのスクロールが遅すぎることがあります。以下にいくつか解決法を挙げます。

[[Libinput#マウスホイールのスクロール速度の調整]] では libinput の {{ic|libinput_event_pointer_get_axis_value}} 関数をインジェクトし、スケール係数を変更するインターフェイスを提供します。これはアプリケーションレベルのインジェクションではないので、アプリケーション固有のスケール係数調整用の追加スクリプトが必要です。Chromium の縦幅の小さい開発者ツールでは、スケール係数を十分大きくするとスクロールが速くなりすぎるかもしれないことに注意してください。

[[imwheel]] は X のホイールボタンのイベントを複数回リプレイすることでスクロールの距離を増やします。しかし、chromium は実際のスクロールとリプレイされたスクロールを2つのイベントとして認識します。これらの間には小さいですが感知できる遅延が存在します。なので、一回のマウスホイールスクロールで2回のページジャンプが発生します。タッチパッドのスクロールでも注意が必要です。

[https://chrome.google.com/webstore/detail/linux-scroll-speed-fix/mlboohjioameadaedfjcpemcaangkkbp Linux Scroll Speed Fix] と [https://chrome.google.com/webstore/detail/smoothscroll/nbokbjkabcmbfdlbddjidfmibcpneigj SmoothScroll] はスクロール距離の変更をサポートする chromium 拡張機能です。ウェブページ内でスクロールすると、現在フォーカスされているノードの最も近いスクロールできる祖先を見つけて、たとえその祖先が一番下までスクロールされていたとしても、その祖先に対してスクロールメソッドがピクセル距離を使って呼ばれます。なので、テキストエディタやスクロール可能な要素にスクロールすると、マウスを動かす以外の方法でその要素からスクロールして出ることはできません。また、拡張機能ベースの手段は Chromium 外では利用できません。

=== 動画がロードされるが再生されない ===

これは PulseAudio の問題である場合があります。[[PulseAudio/トラブルシューティング#ブラウザ (firefox) が動画をロードするが、再生しない]] で提案されている修正方法を確認してください。

=== データベースの破損によりパスワードが保存されない ===

パスワードデータベースは破損することがあり、その場合、再ビルドする必要があります。再ビルドすると、データベース内の全データが破壊され、保存されているパスワードは失われます。

ターミナルから Chromium を起動すると、以下のように出力されます:

[472531:472565:1207/055404.688559:ERROR:login_database.cc(1048)] Password decryption failed, encryption_result is 2

Chromium を終了し、3つのデータベースファイル ({{ic|~/.config/chromium/Default/Login Data*}}) を削除してください。

Chromium を再度起動すると、データベースファイルが再作成されるはずです。

=== KDE Wayland でカーソルが正しく描画されない ===

[[KDE#Plasma のカーソルがときどきおかしくなる]] を参照してください。

=== Wayland で Chromium のウィンドウが透明になる ===

ある[https://issues.chromium.org/issues/329678163 バグ]により、chromium 124 はコマンドラインフラグ {{ic|1=--ozone-platform=wayland}} を明示的に指定して起動する必要があります。

=== Wayland hardware acceleration buffer handle is null エラー ===

とある[https://issues.chromium.org/issues/331796411 バグ]により (特にハードウェアアクセラレーションが有効化されている場合)、ターミナルから起動した際に以下のような出力がログに現れることがあります:

{{bc|1=[333310:333425:0919/121130.103852:ERROR:gpu_channel.cc(502)] Buffer Handle is null.
[333341:18:0919/121130.104000:ERROR:shared_image_interface_proxy.cc(134)] Buffer handle is null. Not creating a mailbox from it.
[333310:333425:0919/121130.137149:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
}}

今のところの回避策は以下のフラグを使用することです:

{{hc|1=~/.config/chromium-flags.conf|2=
--disable-gpu-memory-buffer-video-frames
}}

=== サウンドサーバー無しだと音が出ない ===

Chromiumは[[Advanced_Linux_Sound_Architecture#ハードウェアを直接割り当てる]]をサポートしません。
ミキシングの為の出力デバイス{{ic|pcm.dmixer}}を設定し、
{{ic|1=--alsa-output-device=pcm.dmixer}}フラグを使ってください。

== 参照 ==

* [https://www.chromium.org/ Chromium ホームページ]
* [https://chromereleases.googleblog.com/ Google Chrome リリースノート]
* [https://chrome.google.com/webstore/ Chrome ウェブストア]
* [[Wikipedia:Chromium (web browser)#Differences from Google Chrome|Chromium と Google Chrome の違い]]
* [https://peter.sh/experiments/chromium-command-line-switches/ Chromium コマンドラインスイッチのリスト]
* [[Profile-sync-daemon]] - Chromium プロファイルを tmpfs に保存し、ディスクと同期する systemd サービス
* [[Tmpfs]] - {{ic|/etc/fstab}} での tmpfs ファイルシステム
* [https://docs.kernel.org/filesystems/tmpfs.html 公式の tmpfs カーネルドキュメント]

{{TranslationStatus|Chromium|2025-03-08|827760}}