Linuxのfindコマンドの動作がおかしい


14

最近の脆弱性の公開に続いてシステムで解決されたサービスを検索すると、findコマンドから非常に奇妙な動作が見られるようになりました。

 root@localhost:/# find . -name "*systemd-resolved*"
./usr/share/man/man8/systemd-resolved.service.8.gz
./usr/share/man/man8/systemd-resolved.8.gz

このコマンドは、最初の実行の出力として0または2行を返します。しかし、2回目にコマンドを実行すると、次のようになります。

root@localhost:/# find . -name "*systemd-resolved*"
./usr/share/man/man8/systemd-resolved.service.8.gz
./usr/share/man/man8/systemd-resolved.8.gz
./lib/systemd/systemd-resolved
./lib/systemd/system/systemd-resolved.service.d
./lib/systemd/system/systemd-resolved.service

これは、初めて「find」が実際にすべてを見つけるわけではないことを意味します。また、これは一度だけ発生します。次にコマンドを実行すると、正しい出力が表示されます。Debian 8(jessie)がインストールされている他のシステムでこれをチェックしました。カーネル4.9+を使用している場合、この正確な問題は常に発生しますが、カーネル3.16を使用するシステムでは発生しません。
システムの再起動後、このすべてが再び起こります。ただし、個々のシステムの動作は同じです。つまり、特定のシステムでのテストが最初の実行で2行の出力を返し、2回目の実行で正しい出力を返す場合、システムの再起動後のコマンドの最初の実行は2行を出力します。そのため、システムは各リブート後に同じ動作を示します(私のテストによると)。ファイルの詳細は次のとおりです。

-rw-r--r-- 1 root root  ./usr/share/man/man8/systemd-resolved.service.8.gz
lrwxrwxrwx 1 root root  ./usr/share/man/man8/systemd-resolved.8.gz -> systemd-resolved.service.8.gz
-rwxr-xr-x 1 root root  ./lib/systemd/systemd-resolved
drwxr-xr-x 2 root root  ./lib/systemd/system/systemd-resolved.service.d
-rw-r--r-- 1 root root  ./lib/systemd/system/systemd-resolved.service

編集:これらの特定のファイルのこの特定のケースにおそらく関連する問題を提案するすべての人々に:「システム解決」はちょうど例です。これは、他のキーワードも検索するときに発生します。これは、最初の実行で間違った結果を与える別の例です。

root@localhost:/# find . -name "*apache*"

バックポートリポジトリから最新のカーネルを搭載したDebian 8でこの問題を確認できる人はいませんか?


2
たとえばを使用して、2つの呼び出しのトレースを比較できますstraceか?どのOSで障害のある動作を観察しましたか?「上記のような0または2つの結果を返す」とはどういう意味ですか?ゼロまたは2行の出力、または終了コード0 + 2行?新しいシェルを起動した後、または再起動した後に再び発生しますか?最初の呼び出しはファイルのみを返し、2番目の呼び出しはファイルとディレクトリを返すことに関連する場合があります。
l0b0

1
@ l0b0私が言ったように、複数のシステムでカーネル4.9を使用したDebianで起こります。他のディストリビューションはチェックしませんでした。0または2は、0または2行の出力を意味します。再起動するたびに発生します。あなたの最後の声明はここには適用されません。すべてを返そうとします。ディレクトリとファイルの両方。
user2808671

1
@ l0b0まあ、私はあなたが何を探しているのかわかりませんが、あなたが見ることができるように、私は1つが問題を再現できるようにコマンドを言及しました。そのコマンドは、「systemd-resolved」を含むすべてのパスを返す必要がありますが、返されません。この条件を満たすパスは合計5つありますが、「検索」プログラムはそれらのうち2つまたは1つまたは0のみを返します。ここで重要なのは、ツールが間違った出力を提供し、いくつかの正しいパスを見逃していることです。そして、私が述べたように、Debianを備えた他のシステムでこれをチェックしましたが、カーネル4.9を備えたシステムにはこの問題があります。これは、ユーザー空間を超えた重大な問題になる可能性があります。
user2808671

2
@MarkWagnerいいえ。gnufi​​ndutilsとDebian backportsメーリングリストの両方にバグレポートを記入しました。この問題の原因は他の多くのことに影響を与える可能性があるため、これは私にとって非常に深刻なようです。とにかく「見つける」は非常に人気のあるツールであり、その出力は信頼できるものでなければなりません。
user2808671

2
/lib/systemdマウント方法 どのようなファイルシステムですか?それは別のマウントポイントの場合は、何時間それがマウントされたのですか?
アンドリューヘンレ

回答:


4

Debian 8にインストールされているfindutilsのデフォルトバージョンは4.4.2であり、これはjessieリポジトリの最新バージョンです。findutilsソースコードの最新バージョン(4.6.0)をダウンロードし、ソースからバイナリをビルドしました。次に、同じテストを行い、「find」コマンドで最初の実行の正しい出力を示しました。

次に、gnuアーカイブからfindutilsバージョン4.4.2ソースコードをダウンロードしてコンパイルしました。コンパイルされたfindコマンドでも同じ問題が発生しました。したがって、この問題はfindutils 4.6.0では発生していません。

ただし、findutils 4.4.2(Debianにインストールされているユーティリティのデフォルトバージョン)を使用して同じ結果が得られないユーザーがいる理由はまだわかりません。他のLinuxユーティリティが原因で、この問題のある状況が発生します。そして最後に、奇妙なことに何が起こったのかという正確な技術的理由はまだ不明であり、望ましくないということです。私のOS環境に気になるものがあるかどうかわからないからです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.