5.4. バグ修正

本パートでは、ユーザーに大きな影響を及ぼしていた Red Hat Enterprise Linux 8.3 のバグで修正されたものを説明します。

5.4.1. インストーラーおよびイメージの作成

RHEL 8 初期セットアップが SSH で適切に動作するように

以前は、SSH を使用してシステムにログインすると、RHEL 8 の初期セットアップインターフェイスが表示されませんでした。これにより、SSH を介して管理される RHEL 8 マシンの初期設定を実行できません。この問題は修正され、SSH を介して実行された場合に RHEL 8 の初期設定が正しく機能するようになりました。

(BZ#1676439)

reboot --kexec コマンドを使用するとインストールが失敗しました。

以前では、reboot --kexec コマンドを含むキックスタートファイルを使用すると、RHEL 8 のインストールに失敗していました。

今回の更新で、reboot --kexec を使用したインストールが予想通りに機能するようになりました。

(BZ#1672405)

America/New York タイムゾーンを正しく設定可能

以前では、インタラクティブな Anaconda インストールプロセスでは、キックスタートファイルの使用時に America/New York タイムゾーンをユーザーが設定できませんでした。今回の更新で、タイムゾーンがキックスタートファイルで指定されていない場合に、インタラクティブなインストーラーの希望のタイムゾーンとして America/New York を設定できるようになりました。

(BZ#1665428)

SELinux コンテキストが正しく設定されるようになる

以前では、SELinux が Enforcing モードの場合、一部のフォルダーおよびファイルの誤った SELinux コンテキストにより、インストール後にこれらのファイルにアクセスしようとする際に、予期しない AVC 拒否が発生していました。

今回の更新で、Anaconda は正しい SELinux コンテキストを設定します。これにより、ファイルシステムを手動で再ラベル付けせずにフォルダーおよびファイルにアクセスできるようになりました。

(BZ#1775975)

自動パーティション作成が有効な /boot パーティションを作成

以前は、自動パーティション設定を使用して、または事前設定されたパーティションを持つキックスタートファイルを使用してシステムに RHEL をインストールすると、インストーラーは無効な /boot パーティションを含むパーティション設定スキームを作成していました。したがって、パーティション設定スキームの検証に失敗していたため、自動インストールプロセスが途中で終了しました。今回の更新で、Anaconda が、有効な /boot パーティションを含むパーティション設定スキームを作成するようになりました。その結果、自動インストールは期待どおりに完了します。

(BZ#1630299)

Binary DVD ISO イメージを使用した GUI インストールが、CDN の登録なしで正常に完了するようになりました。

以前のバージョンでは、Binary DVD ISO イメージファイルを使用して GUI インストールを実行する場合は、Red Hat 機能への接続機能を使用してシステムを登録するまで、インストーラーの競合状態によりインストールが続行できなくなることがあります。

今回の更新で、Red Hat への接続機能を使用してシステムを登録しなくてもインストールに進むことができるようになりました。

(BZ#1823578)

キックスタートで iSCSI デバイスまたは FCoE デバイスを作成し、ignoredisk --only-use コマンドでインストールプロセスを停止しなくなりました。

以前では、キックスタートで作成された iSCSI デバイスまたは FCoE デバイスが ignoredisk --only-use コマンドで使用されると、インストールプログラムは、Disk "disk/by-id/scsi-360a9800042566643352b476d674a774a" で指定されている error のようなエラーを出して失敗しました。これによりインストールプロセスが停止しました。

今回の更新で、この問題が修正されています。インストールプログラムは機能を続行します。

(BZ#1644662)

CDN を使用したシステム登録に失敗し、エラーメッセージ Name or service not knownが表示

コンテンツ配信ネットワーク (CDN) を使用してシステムを登録しようとすると、登録プロセスが失敗し、Name or service not known というエラーメッセージが表示されていました。

この問題は、空のカスタムサーバー URLカスタムベース URL の値がシステム登録のデフォルト値をオーバーライドするために発生しました。

今回の更新により、空の値はデフォルト値を上書きせず、システム登録が正常に完了するようになりました。

(BZ#1862116)

5.4.2. ソフトウェア管理

dnf-automatic が、正しい GPG 署名を持つパッケージのみを更新

以前は、dnf-automatic 設定ファイルは、更新を実行する前にダウンロードしたパッケージの GPG 署名を確認しませんでした。そのため、リポジトリー設定に GPG 署名の確認 (gpgcheck=1) が必要ですが、インポートされていない鍵で署名されていない更新または更新は、dnf-automatic でインストールできませんでした。今回の更新で問題が修正され、dnf-automatic は、更新を実行する前にダウンロードしたパッケージの GPG 署名をチェックするようになりました。その結果、正しい GPG 署名を使用した更新は、GPG 署名の確認が必要なリポジトリーからのみインストールされます。

(BZ#1793298)

末尾にコンマがあると append タイプオプションでエントリーが削除されなくなる

以前のバージョンでは、末尾のコンマ (リストの最後に空のエントリー) を append タイプオプション (例: excludeexcludepkgsincludepkgs) に追加すると、オプション内のすべてのエントリーが削除されることがありました。また、2 つのコンマ (空のエントリー) を追加すると、コンマを使用した後のエントリーのみが使用されることがありました。

今回の更新で、先頭にコンマ以外の空のエントリー (リストの先頭に空のエントリー) は無視されます。その結果、先頭のコンマだけが append タイプオプションから既存のエントリーを削除し、ユーザーはこのエントリーを上書きできるようになりました。

(BZ#1788154)

5.4.3. シェルおよびコマンドラインツール

ReaR ディスクレイアウトに Rancher 2 Longhorn iSCSI デバイスおよびファイルシステムのエントリーが含まれなくなりました。

今回の更新で、ReaR が作成したディスクレイアウトから Rancher 2 Longhorn iSCSI デバイスおよびファイルシステムのエントリーが削除されました。

(BZ#1843809)

IBM POWER (リトルエンディアン) では、4 GB を超えるファイルを使用したレスキューイメージの作成が有効になりました。

以前のリリースでは、ReaR ユーティリティーは、IBM POWER (リトルエンディアン) アーキテクチャーに 4GB を超えるファイルを含むレスキューイメージを作成できませんでした。今回の更新で問題が修正され、IBM POWER、リトルエンディアンに 4 GB を超えるファイルでレスキューイメージを作成できるようになりました。

(BZ#1729502)

5.4.4. セキュリティー

SELinux により、systemd-journal-gatewaydcorosync で使用される /dev/shm/ ファイルで newfstatat() を呼び出さなくなりました。

以前のバージョンでは、SELinux ポリシーには、systemd-journal-gatewaydcorosync サービスによって作成されるファイルにアクセスできるルールが含まれません。その結果、SELinux は、systemd-journal-gatewayd による、corosync で作成された共有メモリーファイルの newfstatat() 関数を呼び出しを拒否します。今回の更新で、SELinux は、systemd-journal-gatewayd が、corosync で作成された共有メモリーファイルの newfstatat() を呼び出すのを回避しなくなりました。

(BZ#1746398)

Libreswan が、すべての設定で seccomp=enabled で動作するようになりました。

この更新以前は、Libreswan SECCOMP サポート実装で許可された syscall のセットが、RHEL ライブラリーの新たな使用と一致しませんでした。したがって、SECCOMP が ipsec.conf ファイルで有効になっていると、syscall のフィルタリングは pluto デーモンの正常な機能に必要な syscall に拒否されました。このデーモンは強制終了され、ipsec サービスが再起動されました。今回の更新で、新しく要求されたシステムコールがすべて許可され、Libreswanseccomp=enabled オプションで正しく機能するようになりました。

(BZ#1544463)

auditd によるシステムの停止や電源オフが SELinux によって阻止されなくなりました

以前のバージョンでは、SELinux ポリシーに、Audit デーモンが power_unit_file_t systemd ユニットを起動できるようにするルールがありませんでした。したがって、Logging ディスクパーティションに領域が残っていない場合などに auditd がシステムの停止や電源オフを行うことができるように設定されていても、これを行うことができませんでした。

selinux-policy パッケージの今回の更新で、不足しているルールが追加され、auditd が Enforcing モードでのみシステムを停止したり、電源をオフにできるようになりました。

(BZ#1826788)

IPTABLES_SAVE_ON_STOP が正常に動作するように

以前のバージョンでは、保存された IP テーブルコンテンツを持つファイルが間違った SELinux コンテキストを受け取るため、iptables サービスの IPTABLES_SAVE_ON_STOP 機能は機能しませんでした。これにより、iptables スクリプトはパーミッションを変更できず、その後のスクリプトでは変更を保存できませんでした。今回の更新で、iptables.save ファイルおよび ip6tables.save ファイルの適切なコンテキストを定義し、ファイル名の移行ルールが作成されます。これにより、iptables サービスの IPTABLES_SAVE_ON_STOP 機能が正しく機能します。

(BZ#1776873)

NSCD データベースが異なるモードを使用できるようになりました。

nsswitch_domain 属性のドメインは、Name Service Cache Daemon (NSCD) サービスにアクセスできます。各 NSCD データベースは thenscd.conf ファイルで設定され、共有プロパティーはデータベースが shared メモリー または Socket モードを使用するかどうかを決定します。以前のバージョンでは、すべての NSCD データベースは thenscd_use_shm ブール値に応じて同じアクセスモードを使用する必要がありました。現在は、Unix ストリームソケットが常に許可されるようになったため、異なる NSCD データベースが異なるモードを使用できるようになりました。

(BZ#1772852)

oscap-ssh ユーティリティーが、--sudo でリモートシステムをスキャンすると、正しく機能するようになりました。

oscap-ssh ツールで --sudo オプションを使用してリモートシステムの Security Content Automation Protocol (SCAP) スキャンを実行すると、リモートシステムの oscap ツールが、root ユーザーとして、スキャン結果ファイルとレポートファイルを一時ディレクトリーに保存します。以前は、リモートマシンの umask 設定を変更すると、oscap-ssh がこれらのファイルにアクセスできないことがありました。今回の更新で問題が修正され、oscap がターゲットユーザーとしてファイルを保存し、oscap -ssh が通常ファイルにアクセスします。

(BZ#1803116)

OpenSCAP が、リモートファイルシステムを正しく処理

以前は、マウント仕様が 2 つのスラッシュで開始されなかった場合に、OpenSCAP はリモートファイルシステムを確実に検出しませんでした。これにより、OpenSCAP が、一部のネットワークベースのファイルシステムをローカルとして処理していました。今回の更新で、OpenSCAP はマウント仕様ではなく、ファイルシステムタイプを使用してファイルシステムを特定します。これにより、OpenSCAP がリモートファイルシステムを正しく処理するようになりました。

(BZ#1870087)

OpenSCAP で YAML の複数行文字列から空の行が削除されなくなる

以前のバージョンでは、OpenSCAP は YAML の複数ライン文字列から、データストリームから生成された Ansible 修正から空の行を削除していました。この影響を受ける Ansible の修正により、openscap ユーティリティーが対応する Open Vulnerability and Assessment Language (OVAL) チェックに失敗し、誤検出結果が生成されます。この問題は修正され、openscap は YAML の複数行の文字列から空の行を削除しなくなりました。

(BZ#1795563)

OpenSCAP はメモリーが不足することなく、ファイルが大量に含まれるシステムをスキャンできるように。

以前のリリースでは、メモリーが少なく、ファイルが多数あるシステムをスキャンすると、OpenSCAP スキャナーが原因でシステムのメモリーがなくなることがありました。今回の更新で、OpenSCAP スキャナーのメモリー管理が改善されました。その結果、スキャナーは、たとえば、Server with GUI および Workstation を使用するパッケージグループなど、多数のファイルをスキャンする際に、RAM が少ないシステムでメモリーが不足することがなくなりました。

(BZ#1824152)

config.enabled がステートメントを適切に制御

以前のバージョンでは、rsyslog は、ステートメントの設定処理中に config.enabled ディレクティブを誤って評価していました。そのため、include() を除く各ステートメントに対して parameter not known エラーが表示されました。今回の更新で、すべてのステートメントに対して設定が同等に処理されます。その結果、config.enabled はエラーを表示せずに、ステートメントを正しく無効または有効にするようになりました。

(BZ#1659383)

fapolicyd が RHEL の更新を阻止しなくなりました。

更新で実行中のアプリケーションのバイナリーが置き換えられると、カーネルにより、接尾辞 " (deleted) が追加されて、メモリー内のアプリケーションのバイナリーパスが変更されます。以前のバージョンでは、fapolicyd ファイルアクセスポリシーデーモンは、信頼できないアプリケーションなどのように処理し、他のファイルを開き、実行できませんでした。そのため、更新の適用後にシステムを起動できないことがありました。

RHBA-2020:5242 アドバイザリーのリリースでは、fapolicyd がバイナリーパスの接尾辞を無視し、バイナリーが信頼データベースに一致するようにします。これにより、fapolicyd がルールを正しく適用し、更新プロセスを完了できるようになりました。

(BZ#1897090)

e8 プロファイルを使用して、Server with GUI で RHEL 8 システムを修復可能に

OpenSCAP Anaconda Add-on を使用して、Verify Integrity with RPM グループからルールを選択するプロファイルが含まれる Server With GUI パッケージグループでシステムを強化すると、システム上のメモリーが過剰に必要ではなくなりました。この問題の原因は OpenSCAP スキャナーでした。詳細は Scanning large numbers of files with OpenSCAP causes systems to run out of memory を参照してください。これにより、RHEL 8 Essential Eight (e8) プロファイルを使用してシステムを強化すると、Server With GUI も機能するようになりました。

(BZ#1816199)

5.4.5. ネットワーク

nft_compat モジュールによる iptables 拡張機能モジュールの自動読み込みがハングしなくなる

以前は、ネットワーク名前空間 (netns) が並行して操作中に nft_compat モジュールが拡張モジュールがロードされた場合、その拡張が初期化中に pernet サブシステムを登録すると、ロックの競合が発生する可能性がありました。これにより、modprobe コマンド と呼ばれるカーネルがハングします。これは、libvirtd などの他のサービスが、iptables コマンドも実行するその他のサービスが原因である可能性があります。この問題が修正されました。その結果、nft_compat モジュールによる iptables 拡張機能モジュールの読み込みでハングしなくなりました。

(BZ#1757933)

firewalld サービスは、サービスが停止すると ipsets を削除するようになりました。

以前は、firewalld サービスを停止すると、ipsets が削除されませんでした。今回の更新でこの問題が修正されています。これにより、firewalld が停止すると、ipset がシステムに残らなくなくなりました。

(BZ#1790948)

firewalld がシャットダウン後に ipset エントリーを保持しない

以前は、firewalld をシャットダウンすると、ipset エントリーが削除されませんでした。したがって、firewalld サービスを停止した後も、ipset エントリーはカーネル内でアクティブな状態のままになりました。今回の修正により、firewalld をシャットダウンすると、ipset エントリーが期待どおりに削除されるようになりました。

(BZ#1682913)

firewalld が、リロード後に ipset エントリーを復元するようになりました。

以前は、再読み込み後に firewalld がランタイム ipset エントリーを保持しませんでした。したがって、ユーザーは不足しているエントリーをもう一度手動で追加する必要がありました。今回の更新で、再読み込み後に ipset エントリーを復元するように firewalld が変更されました。

(BZ#1809225)

nftables サービスおよび firewalld サービスが相互に排他的に

以前は、nftables サービスと firewalld サービスを同時に有効にできました。これにより、nftablesfirewalld ルールセットを上書きしていました。今回の更新で、nftables サービスおよび firewalld サービスは相互排他的になり、同時に有効にできなくなりました。

(BZ#1817205)

5.4.6. カーネル

huge_page_setup_helper.py スクリプトが正しく動作する

Python 3 の huge_page_setup_helper.py スクリプトしたパッチが、誤って削除されました。これにより、huge_page_setup_helper.py の実行後に、以下のエラーメッセージが表示されます。

SyntaxError: Missing parentheses in call to 'print'

今回の更新で、libhugetlbfs.spec ファイルを更新してこの問題が修正されています。その結果、huge_page_setup_helper.py に上記のシナリオでエラーが表示されなくなりました。

(BZ#1823398)

大量の永続メモリーを備えたシステムは、タイムアウトなしでより迅速に起動します

元のソースコードではノードごとに 1 つの初期化スレッドしか許可されていなかったため、大量の永続メモリーを備えたシステムは起動に長い時間がかかりました。たとえば、4 ノードシステムの場合は、4 つのメモリー初期化スレッドがありました。したがって、/etc/fstab ファイルに永続メモリーのファイルシステムがあると、デバイスが利用できるようになるまで待つ際に、システムがタイムアウトする場合があります。今回の更新では、ソースコードが単一ノード内で複数のメモリー初期化スレッドを許可するようになったため、問題が修正されました。その結果、システムはより迅速に起動し、説明されているシナリオではタイムアウトは発生しません。

(BZ#1666538)

bcc スクリプトが正常に BPF モジュールをコンパイル

スクリプトコードをコンパイルして Berkeley Packet Filter (BPF) モジュールを作成すると、bcc ツールキットはデータタイプ定義にカーネルヘッダーを使用していました。一部のカーネルヘッダーには、KBUILD_MODNAME マクロを定義する必要がありました。そのため、KBUILD_MODNAME を追加しない bcc スクリプトでは、さまざまな CPU アーキテクチャー全体で BPF モジュールをコンパイルする可能性がありました。以下の bcc スクリプトは影響を受けます。

  • bindsnoop
  • sofdsnoop
  • solisten
  • tcpaccept
  • tcpconnect
  • tcpconnlat
  • tcpdrop
  • tcpretrans
  • tcpsubnet
  • tcptop
  • tcptracer

今回の更新で、bcc のデフォルトの cflags パラメーターに KBUILD_MODNAME を追加することで、この問題が修正されています。その結果、この問題は上記のシナリオで表示されなくなります。また、カスタマースクリプトは、KBUILD_MODNAME 自体を定義する必要はありません。

(BZ#1837906)

IBM Z で bcc-tools および bpftrace が適切に動作するようになりました。

以前のバージョンでは、機能のバックポートにより、ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE カーネルオプションが導入されました。ただし、IBM Z アーキテクチャー用の bcc-tools パッケージおよび bpftrace トレース言語パッケージでは、このオプションが適切にサポートされませんでした。そのため、bpf() システムコールが Invalid argument exception で失敗し、bpftrace が BPF プログラムを読み込む際に Error loading program を示すエラーを出して失敗しました。今回の更新により、ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE オプションが削除されました。その結果、上記のシナリオで問題が表示されなくなりました。

(BZ#1847837、BZ#1853964)

エントロピーがないためブートプロセスが失敗しなくなる

以前のバージョンでは、エントロピーがないためにブートプロセスが失敗しました。カーネルがブートプロセスの早い段階でエントロピーを収集できるように、より良いメカニズムが使用されるようになりました。これは、ハードウェア固有の割り込みに依存しません。今回の更新では、起動の初期で無作為な生成のセキュリティーを保護するのに十分なエントロピーの可用性を確保することでこの問題が修正されています。その結果、この修正によりキックスタートのタイムアウトや起動速度が遅くなり、起動プロセスが期待どおりに機能します。

(BZ#1778762)

kexec を使用した再起動が期待どおりに動作する

以前のバージョンでは、Amazon EC2 Nitro プラットフォームでカーネルを再起動すると、カーネル実行パスの shutdown() の呼び出し中に remove モジュール (rmmod) が呼び出されませんでした。したがって、kexec システムコールを使用してカーネルを再起動すると、失敗していました。今回の更新で、安全なカーネル実行を可能にする PCI shutdown() ハンドラーを追加してこの問題が修正されています。その結果、Amazon EC2 Nitro プラットフォームで kexec を使用した再起動が繰り返し行われなくなりました。

(BZ#1758323)

ダンプターゲットとして vPMEM メモリーを使用した繰り返し再起動が期待どおりに機能するようになりました。

以前は、kdump または fadump のダンプターゲットとして仮想永続メモリー (vPMEM) 名前空間を使用すると、papr_scm モジュールが vPMEM がサポートするメモリーのマッピングを解除し、メモリーをリニアマップに再追加していました。

その結果、この動作により、ハイパーバイザーコール (HCall) がトリガーされ、POWER Hypervisor がトリガーされます。その結果、キャプチャーカーネルブートが大幅に遅くなり、ダンプファイルを保存するのに時間がかかります。今回の更新で問題が修正され、上記のシナリオで起動プロセスが期待どおりに動作するようになりました。

(BZ#1792125)

ICE ドライバーの NIC ポートをモード 5 ボンディングマスターインターフェイスに追加しようとしても失敗しなくなりました。

以前のバージョンでは、ICE ドライバー NIC ポートをモード 5 (balance-tlb) ボンディングマスターインターフェイスに追加しようとすると、Master 'bond0', Slave 'ens1f0': Error: Enslave failed のエラーで失敗する可能性があります。そのため、NIC ポートをボンディングマスターインターフェイスに NICE ポートを追加するときに断続的に問題が発生していました。今回の更新で問題が修正され、インターフェイスの追加は失敗しなくなりました。

(BZ#1791664)

cxgb4 ドライバーにより、kdump カーネルでクラッシュが発生しなくなる

以前のリリースでは、vmcore ファイルに情報を保存しようとすると、kdump カーネルがクラッシュしていました。そのため、cxgb4 ドライバーにより、kdump カーネルが、後で分析するためにコアを保存できなくなります。この問題を回避するには、kdump カーネルコマンドラインに novmcoredd パラメーターを追加して、コアファイルを保存できるようにします。

RHSA-2020:1769 アドバイザリーのリリースにより、kdump カーネルがこの状況を適切に処理し、クラッシュしなくなりました。

(BZ#1708456)

5.4.7. 高可用性およびクラスター

ファイルシステムエージェントで GFS2 ファイルシステムを使用する場合は、fast_stop オプションがデフォルトで no に設定されます。

以前は、ファイルシステムエージェントで GFS2 ファイルシステムを使用すると、fast_stop オプションがデフォルトで yes に設定されます。この値により、GFS2 ファイルシステムのマウント解除にかかる時間が原因で、不要なフェンスイベントが発生する可能性がありました。今回の更新で、このオプションはデフォルトで no に設定されます。他のすべてのファイルシステムでは、デフォルトで yes に設定されます。

(BZ#1814896)

fence_compute および fence_evacuate エージェントは、より標準的な方法で insecure オプションを解釈するようになりました。

以前は、fence_compute および fence_evacuate エージェントは、--insecure がデフォルトで指定されたかのように動作していました。今回の更新により、コンピュートまたは退避サービスに有効な証明書を使用しないお客様は、insecure=true を設定し、CLI から手動で実行する場合に --insecure オプションを使用する必要がありました。これは、他のすべてのエージェントの動作に一貫性があります。

(BZ#1830776)

5.4.8. 動的プログラミング言語、Web サーバー、およびデータベースサーバー

libdb による CPU 消費の最適化

以前の libdb データベースの更新により、trickle スレッドにおける CPU 消費が過剰になっていました。今回の更新で、CPU 使用率が最適化されました。

(BZ#1670768)

did_you_mean Ruby gem には、重要なライセンスを持つファイルが含まれなくなりました。

以前は、ruby:2.5 モジュールストリームで利用可能な did_you_mean gem には、自分以外のライセンスを持つファイルが含まれていました。今回の更新で、影響を受けるファイルが削除されます。

(BZ#1846113)

nginx が PKCS#11 URI を使用して、ハードウェアセキュリティートークンからサーバー証明書をロードできるようになりました。

nginx Web サーバーの ssl_certificate ディレクティブは、PKCS#11 モジュールを利用してハードウェアセキュリティートークンから直接 TLS サーバー証明書を読み込むことをサポートします。以前は、PKCS#11 URI を使用して、ハードウェアセキュリティートークンからサーバー証明書を読み込むことができませんでした。

(BZ#1668717)

5.4.9. コンパイラーおよび開発ツール

DT_FILTER を使用する共有ライブラリーの読み込み中に glibc 動的ローダーが失敗しなくなりました。

この更新以前は、共有オブジェクトの動的ローダー実装にフィルターとして不具合があると、フィルターを使用する共有ライブラリーがロードされ、コンストラクターを持つ際に動的ローダーが失敗していました。今回のリリースにより、フィルターの動的ローダー実装 (DT_FILTER) が修正され、このような共有ライブラリーを正しく処理できるようになりました。その結果、上述のシナリオで動的ローダーが想定どおりに機能するようになりました。

(BZ#1812756)

glibc が、getmntent() リストから擬似マウントを削除可能

カーネルには、ユーザー空間に公開されるテーブルの automount 疑似エントリーが含まれます。そのため、getmntent() API を使用するプログラムは、通常のマウントとこの擬似マウントの両方をリストに表示されるようになりました。擬似マウントは、実際のマウントには対応せず、有効な情報も含まれます。

今回の更新で、mount エントリーに automount(8) 設定にある ignore マウントオプションがあると、glibc ライブラリーでこの擬似マウントが getmntent() リストから削除されるようになりました。以前の動作を想定するプログラムでは、異なる API を使用する必要があります。

(BZ#1743445)

movv1qi パターンにより、IBM Z の自動ベクターコードに誤コンパイルが発生しなくなりました。

この更新以前は、movv1qi パターンに対して誤った負荷命令が生成されていました。これにより、自動アクターのフィルターが有効になっていると、IBM Z システムで不適切なコンパイルが実行される可能性がありました。今回の更新で movv1qi パターンが修正され、コードコンパイルおよび実行が正常に実行されるようになりました。

(BZ#1784758)

PAPI_event_name_to_code() が複数のスレッドで適切に動作するようになりました。

この更新以前は、PAPI 内部コードがスレッドの調整を正しく処理しませんでした。したがって、複数のスレッドが PAPI_event_name_to_code() 操作を使用すると、競合状態が発生し、操作に失敗していました。今回の更新で、PAPI 内部コードで複数のスレッドの処理が強化されます。その結果、PAPI_event_name_to_code() 操作を使用したマルチスレッドコードが正しく機能するようになりました。

(BZ#1807346)

IBM Power Systems の glibc math 関数のパフォーマンスを改善

以前は、glibc math 関数は、IBM Power Systems で不要な浮動小数点のステータスの更新とシステムコールを実行していたため、パフォーマンスに悪影響を及ぼしていました。今回の更新で、不要な浮動小数点ステータスの更新が削除され、ceil()ceilf()fegetmode()fesetmode()fesetenv()fegetexcept()feenableexcept()fedisablexcept()fegetround()fesetround() の実装が改善されました。その結果、IBM Power Systems では、math ライブラリーのパフォーマンスが向上しました。

(BZ#1783303)

メモリー保護鍵が IBM Power で対応

IBM Power Systems では、メモリー保護キーインターフェイス pkey_set および pkey_get は、以前はスタブ機能でした。そのため、常に失敗していました。今回の更新でインターフェイスが実装され、GNU C ライブラリー (glibc) が IBM Power Systems でのメモリー保護キーをサポートするようになりました。

現在、メモリー保護キーにはハッシュベースのメモリー管理ユニット (MMU) が必要なため、カーネルパラメーター disable_radix で特定のシステムを起動する必要があるかもしれません。

(BZ#1642150)

papi-testsuite および papi-devel が、必要な papi-libs パッケージをインストールするようになりました。

以前は、papi-testsuite および papi-devel RPM パッケージは、一致する papi-libs パッケージの依存関係を宣言しませんでした。そのため、テストは実行に失敗し、開発者はアプリケーションで利用可能な papi 共有ライブラリーの必要なバージョンがありませんでした。

今回の更新で、papi-testsuite パッケージまたは papi-devel パッケージのいずれかをインストールすると、papi-libs パッケージもインストールされます。そのため、papi-testsuite に、テストを実行できるように正しいライブラリーが設定され、papi-devel を使用する開発者では、適切なバージョンの papi 共有ライブラリーに実行ファイルがリンクされるようになりました。

(BZ#1664056)

複数のアーキテクチャー用の lldb パッケージのインストールでファイルの競合が発生しなくなる

以前では、lldb パッケージは、アーキテクチャーに依存しない場所にアーキテクチャー依存ファイルをインストールしていました。そのため、パッケージの 32 ビットバージョンと 64 ビットバージョンの両方をインストールすると、ファイルの競合が発生していました。今回の更新で、アーキテクチャー依存の場所のファイルがパッケージ化されるようになりました。これにより、上記のシナリオでの lldb のインストールが正常に完了します。

(BZ#1841073)

getaddrinfo がメモリー割り当てエラーを適切に処理

以前は、メモリー割り当てに失敗すると、GNU C ライブラリー glibcgetaddrinfo 関数は、内部リゾルバーコンテキストをリリースしませんでした。したがって、getaddrinfo は、呼び出しスレッドの残りのライフタイム中は /etc/resolv.conf ファイルを再読み込みできず、メモリーリークが発生していました。

今回の更新により、リゾルバーコンテキストの追加リリース操作でエラー処理パスが変更されました。その結果、getaddrinfo は、断続的なメモリー割り当ての失敗後も新しい設定値で /etc/resolv.conf を再読み込みします。

(BZ#1810146)

glibc が、IFUNC リゾルバーの順序によって発生する特定の障害を回避

以前は、GNU C ライブラリー glibclibrt および libpthread ライブラリーの実装には、以下の関数の間接関数 (IFUNC) リゾルバーが含まれていました。time_gettimeclock_getcpuclockidclock_nanosleeptime_settimevfork。場合によっては、IFUNC リゾルバーは、librt ライブラリーおよび libpthread ライブラリーが再配置される前に実行できることがあります。その結果、早いプログラムの起動時にアプリケーションが glibc 動的ローダーで失敗していました。

今回のリリースにより、これらの関数の実装が glibclibc コンポーネントに移動し、上記の問題が発生しなくなりました。

(BZ#1748197)

アサーションの失敗が pthread_create の実行中に発生しない

以前のバージョンでは、glibc 動的ローダーは内部 Thread Local Storage (TLS) モジュール ID カウンターへの変更をロールバックしませんでした。これにより、pthread_create 関数のアサーションエラーが生じ、特定の方法で dlopen 関数が失敗していました。今回の修正により、glibc 動的ローダーは、特定の障害が発生しなくなった後に、後で TLS モジュール ID カウンターを更新するようになりました。その結果、アサーションエラーが生じなくなりました。

(BZ#1774115)

glibcnss_db を使用して 32 ビットアプリケーションに正しい依存関係をインストールするようになりました。

以前は、nss_db.x86_64 パッケージは nss_db.i686 パッケージで依存関係を宣言しませんでした。したがって、32 ビット環境 glibc.i686 がインストールされている場合でも、自動インストールでは nss_db.i686 をシステムにインストールしませんでした。そのため、nss_db を使用する 32 ビットアプリケーションは、正確なユーザーデータベースルックアップを実行しなくなり、同じ設定の 64 ビットアプリケーションが正常に機能します。

今回の更新で、glibc パッケージの弱い依存関係が、glibc.i686 および nss_db の両方がシステムにインストールされていると、nss_db.i686 パッケージのインストールがトリガーされます。これにより、システム管理者が nss_db.i686 パッケージを明示的にインストールしていない場合でも、nss_db を使用する 32 ビットアプリケーションが正しく機能するようになりました。

(BZ#1807824)

Odia 言語で更新された glibc ロケール情報

以前 Orissa と呼ばれる Indian 状態の名前が Odisha に変更され、公式の言語の名前が Oriya から Odia に変更になりました。今回の更新で、glibc ロケール情報に言語の新しい名前が反映されるようになりました。

(BZ#1757354)

LLVM サブパッケージが、アーキテクチャーに依存しない場所に arch 依存ファイルをインストールするようになりました。

以前では、LLVM サブパッケージは、アーキテクチャーに依存しない場所に arch 依存ファイルをインストールしていました。これにより、32 ビットおよび 64 ビットバージョンの LLVM のインストール時に競合が生じました。今回の更新で、パッケージファイルがアーキテクチャー依存の場所に正しくインストールされるようになり、バージョンの競合を避けるようになりました。

(BZ#1820319)

glibc でパスワードおよびグループ検索が失敗しなくなりました。

以前は、glibc ライブラリーの nss_compat モジュールが、パスワードおよびグループエントリーの処理中に誤ったエラーコードで errno 状態を上書きしていました。その結果、アプリケーションはバッファーを予想通りにサイズ変更せず、パスワードおよびグループの検索に失敗していました。今回の更新で問題が修正され、ルックアップが期待どおりに完了するようになりました。

(BZ#1836867)

5.4.10. ID 管理

SSSD がデフォルトでワイルドカード文字が含まれるすべてのルールをダウンロードしない

以前は、ldap_sudo_include_regexp オプションがデフォルトで誤って true に設定されていました。これにより、SSSD が SSSD ルールの実行または更新を開始した場合、SSSD は sudoHost 属性にワイルドカード文字 (*) が含まれるすべてのルールをダウンロードしていました。今回の更新でバグが修正され、ldap_sudo_include_regexp オプションがデフォルトで false に設定されるようになりました。その結果、上記の問題が発生しなくなりました。

(BZ#1827615)

krb5 が、許可された暗号化タイプのみを要求する

以前のバージョンでは、default_tgs_enctypes 属性または default_tkt_enctypes 属性が設定されていない場合、/etc/krb5.conf ファイルの permitted_enctypes 変数で指定された暗号化タイプは、デフォルトの暗号化タイプに適用されませんでした。そのため、Kerberos クライアントは RC4 などの非推奨の暗号スイートを要求することができ、これにより、他のプロセスが失敗する可能性があります。今回の更新で、allow_enctypes 変数で指定した暗号化タイプもデフォルトの暗号化タイプに適用され、許可される暗号化タイプのみが要求されるようになりました。

RHEL 8 で非推奨となった RC4 暗号スイートは、ユーザー、サービス、および AD フォレスト内の Active Directory (AD) ドメインとの間の信頼のデフォルト暗号化タイプです。

(BZ#1791062)

KDC で LDAP バックエンドからパスワード有効期間のポリシーを正常に適用されるようになりました

以前のバージョンは、Kerberos LDAP バックエンドにより、パスワードポリシーが正しく適用されていなかったため、IPA 以外の Kerberos Distribution Center (KDC) ではパスワードの最大有効期間を保証できませんでした。今回の更新で、Kerberos LDAP バックエンドが修正され、パスワードの有効期間が期待どおりに機能するようになりました。

(BZ#1784655)

SSSD を使用する AD クライアントにパスワード有効期限の通知が送信されます

以前のバージョンでは、SSSD を使用する Active Directory クライアント (IdM 以外) には、パスワード有効期限の通知が送信されませんでした。これは Kerberos 認証情報を取得するために、SSSD インターフェイスに最近変更が加えられたためです。

Kerberos インターフェイスが更新され、有効期限の通知が正しく送信されるようになりました。

(BZ#1820311)

間接的な CoS 定義を使用時の、Directory Server でのメモリーリークを修正

以前のバージョンでは、間接的な CoS (Class of Service) 定義を処理すると、Directory Server では、間接 CoS 定義を使用する検索操作ごとにメモリーリークが発生していました。今回の更新で、Directory Server は、処理後にデータベースエントリーに関連する CoS 内部構造をすべて解放するようになりました。その結果、間接的な CoS 定義の使用時にサーバーでのメモリーリークがなくなりました。

(BZ#1816862)

AD ユーザーの ID オーバーライドの追加が IdM Web UI で機能するようになりました。

以前は、IdM Web UI の使用時に、管理ロールへのアクセスを付与する目的で、Default Trust View の Active Directory (AD) ユーザーの ID オーバーライドを Identity Management (IdM) グループに追加していました。今回の更新でバグが修正されました。これにより、このシナリオで Web UI と IdM コマンドラインインターフェイス (CLI) の両方を使用できるようになりました。

(BZ#1651577)

FreeRADIUS がパッケージのインストール時に証明書を生成しなくなりました

以前のバージョンでは、FreeRADIUS がパッケージのインストール時に証明書を生成していたため、以下の問題が発生することがありました。

  • キックスタートを使用して FreeRADIUS がインストールされている場合には、システムのエントロピーが十分ではない場合に証明書が生成される可能性があり、インストールに失敗したり、セキュアな証明書が少なくなることがありました。
  • パッケージは、ターゲットマシンではなくビルダーマシンでパッケージインストールが行われるため、コンテナーなどのイメージの一部としてビルドすることは容易ではありませんでした。イメージから起動するすべてのインスタンスに同じ証明書情報があります。
  • 証明書を手動で削除し、再生成する必要があるため、エンドユーザーが環境で簡単な仮想マシンを生成することは容易ではありませんでした。

今回の更新で、FreeRADIUS インストールで、デフォルトの自己署名 CA 証明書または下位 CA 証明書が生成されなくなりました。FreeRADIUS が systemd から起動されると、以下を行います。

  • 必要な証明書がすべて見つからない場合は、デフォルト証明書のセットが生成されます。
  • 予想される証明書の 1 つまたは複数が存在する場合は、新しい証明書を生成しません。

(BZ#1672285)

FreeRADIUS が FIPS 準拠の Diffie-Hellman パラメーターを生成するようになりました。

openssldhparam を介して Diffie-Hellman (dh) パラメーターを生成できない新しい FIPS 要件により、dh パラメーターの生成は FreeRADIUS ブートストラップスクリプトから削除され、rfc3526-group-18-8192.dhparam ファイルはすべてのシステムの FreeRADIUS パッケージに含まれており、FreeRADIUS が FIPS モードで起動するようになっています。

/etc/raddb/certs/bootstrap および /etc/raddb/certs/Makefile をカスタマイズして、必要に応じて DH パラメーターの生成を復元できることに注意してください。

(BZ#1859527)

Healthcheck の更新により ipa-healthcheck-core および ipa-healthcheck の両方が適切に更新されるようになりました。

以前では、yum update healthcheck を入力すると、ipa-healthcheck パッケージが更新されず、ipa-healthcheck-core パッケージに置き換えられました。そのため、更新後に ipa-healthcheck コマンドが機能しませんでした。

今回の更新でバグが修正され、ipa-healthcheck を更新すると、ipa-healthcheck パッケージと ipa-healthcheck-core パッケージの両方が正しく更新されるようになりました。これにより、更新後に Healthcheck ツールが正しく動作します。

(BZ#1852244)

5.4.11. グラフィックインフラストラクチャー

ハイブリッド Nvidia GPU を備えたラップトップがサスペンドから正常に再開できるようになりました。

以前では、nouveau グラフィックスドライバーが、省電力モードからの特定のラップトップでハイブリッド Nvidia GPU の電源をオンにできないことがありました。その結果、ラップトップはサスペンドから再開できませんでした。

今回の更新で、Runtime Power Management (runpm) システムの複数の問題が修正されました。その結果、ハイブリッドグラフィックスを備えたラップトップがサスペンドから正常に再開できるようになりました。

(JIRA:RHELPLAN-57572)

5.4.12. 仮想化

デフォルトの CPU モデルを使用する仮想マシンの移行がより確実に機能するようになりました。

以前は、特定の CPU モデルなしで仮想マシン (VM) が作成された場合、QEMU が libvirt サービスに見えないデフォルトモデルを使用していました。したがって、仮想マシンのデフォルトの CPU モデルをサポートしないホストに仮想マシンを移行する可能性がありました。これにより、移行後にゲスト OS でクラッシュおよび誤った動作が生じることがありました。

今回の更新で、libvirt が、仮想マシンの XML 設定でデフォルトとして qemu64 モデルを明示的に使用するようになりました。その結果、ユーザーがデフォルトの CPU モデルを持つ仮想マシンをそのモデルをサポートしないホストに移行しようとすると、libvirt がエラーメッセージを正しく生成します。

ただし、Red Hat は、仮想マシンに特定の CPU モデルを使用することを強く推奨します。

(JIRA:RHELPLAN-45906)

5.4.13. コンテナー

Podman での FIPS サポートに関する注意事項

Federal Information Processing Standard (FIPS) を使用するには、認定済みモジュールを使用する必要があります。以前のバージョンでは、Podman は起動時に適切なフラグを有効にして、コンテナーに認定モジュールを正しくインストールしていました。ただし、本リリースでは、Podman は FIPS システム全体の crypto-policy の形式でシステムによって提供される追加アプリケーションヘルパーを適切に設定しません。認定モジュールでは、システム全体の crypto-policy を設定する必要はありませんが、適切な方法で暗号化モジュールを使用するアプリケーションが強化されます。この問題を回避するには、他のアプリケーションコードを実行する前に、コンテナーを変更して update-crypto-policies --set FIPS コマンドを実行します。今回の修正では、update-crypto-policies --set FIPS コマンドが不要になりました。

(BZ#1804193)