単体テストにはこれが必要です。できる機能があります。統計資料引数として渡されたファイルパス。失敗したコードパスをトリガーする必要がありますlstat（コードカバレッジが90％である必要があるため）。
このテストは単一のユーザーとしてのみ実行できるため、Ubuntuに常に存在するファイルがあるかどうか疑問に思います。一般ユーザーは、そのファイルまたはそのフォルダに対する読み取り権限を持っていません。 （したがってlstatルートとして実行しないと失敗します。）
存在しないファイルには、私がトリガーした別のコードパスがあるため、ソリューションではありません。
編集：ファイルへの読み取りアクセス権が不足しているだけでは不十分です。これはlstatまだ動作します。 /rootにフォルダを作成し、その中にファイルを作成して（rootアクセス権を持つローカルコンピュータで）それをトリガーすることができました。そして、そのフォルダの権限を700に設定してください。そのため、rootとしてのみアクセスできるフォルダからファイルを検索しています。
答え1
/proc/1/fdinfo/0最新のLinuxシステムでは、（プロセスID 1のファイル記述子1（stdout）に関する情報（init実行する必要があるルートpidネームスペースにありますroot））を使用できる必要があります。
一般ユーザーとしてリストを見つけることができます：
sudo find /etc /dev /sys /proc -type f -print0 |
perl -l -0ne 'print unless lstat'
（-type f通常のファイルに制限したくない場合は削除してください）。
/var/cache/ldconfig/aux-cacheUbuntuシステムのみを考えると、これは別の潜在的な候補です。/var/cache/ldconfigルートの読み取り+書き込み+検索は、GNU libcに付属のコマンドを介してのみ生成できるため、ほとんどのGNUシステムで機能します。ldconfig
答え2
見ている統計(2)マニュアルページは、ENOENT（ファイルが存在しない）以外のエラーによって失敗する可能性がある状況に触発されています。
最も明白なものは次のとおりです。
ヨーロッパ航空宇宙センター パスプレフィックスのディレクトリの1つに対する検索権限が拒否されました。道。
したがって、検索できないディレクトリが必要です。
はい、システムにすでに存在するものを見つけることができますが（おそらく/var/lib/private存在しますか？）、次のように直接作成することもできます。
$ mkdir myprivatedir
$ touch myprivatedir/myunreachablefile
$ chmod 0 myprivatedir
$ ls -l myprivatedir/myunreachablefile
lstat(2) ジョブは EACCES によって失敗します。 （ディレクトリからすべての権限を削除すると、これを保証できます。それほど多くの権限が必要ない場合があります。chmod -x実行権限を削除するだけで十分です。ディレクトリの下にあるファイルにアクセスするには、ディレクトリに実行権限が必要です。だからです。）
lstat(2) を失敗させる別の創造的な方法があります。マニュアルページを確認してください。
エノディル パスプレフィックスのコンポーネント道ディレクトリではありません。
したがって、このようなファイルにアクセスしようとすると、/etc/passwd/nonexistentこのエラーが発生します。このエラーはENOENT（「該当するファイルやディレクトリはありません」）とは異なり、ユーザーのニーズに適している可能性があります。
もう一つは次のとおりです。
エナツロン 道長すぎます。
しかし、非常に長い名前が欲しいかもしれません。 （4,096バイトが一般的な制限だと思いますが、システム/ファイルシステムの名前が長くなる可能性があります。）
最終的にこれになるかどうかを言うのは難しいです。実際にそれはあなたのために働きます。 「ファイルが存在しません」シナリオを引き起こさないことを望んでいると言われました。これは通常 ENOENT エラーを意味しますが、実際には多くの上位レベルの検査では lstat(2) のすべてのエラーを「存在しない」と解釈します。たとえば、test -eシェルのそれに対応する項目は、上記[ -e ...]のすべての内容を「存在しない」と解釈できます。特に、他のエラーメッセージを返す良い方法がなく、エラーを返さないファイルは存在しますが、これは明らかに真ではありません。
答え3
自分で行うことができfindます。
/etc--configファイルディレクトリを開始点として使用します。
sudo find /etc -type f -perm 0400 -user root
私のシステムでは何も返しません。
制限が少なく、許可されたグループにすることができますroot（ユーザーのみがrootグループのメンバーである必要がありますroot）、次の権限に注意してください440。
sudo find /etc -perm 0440 -user root -group root
私のシステムでは、以下を返します。
/etc/sudoers.d/README
/etc/sudoers
編集する：
編集内容に応じて、発信者がディレクトリのリストを防ぐのに十分な権限を持たないディレクトリを探しています。
sudo find / -perm o-rwx -type d -user root -group root
-type dここでは、他の人（）の読み取り/書き込み実行権限ビットはありませんo-rwx。root:root（）が所有するディレクトリを探しています。
技術的には、単に実行（）ビットがない場合、ディレクトリxにディレクトリ（）はリストされません。lstat(2)
/run/systemd/inaccessible/出力でSystemd initベースのシステムで見つかりました。
/proc/sys、およびファイル情報/dev：
これらのファイルシステムは仮想ファイルシステムです。つまり、ディスクではなくメモリに常駐します。
に依存する場合は、後続のPID（プロセス）が存在することは保証されていません
/proc。/proc/1/