常に存在し、「通常の」ユーザーがlstatできないファイルがありますか？

これは単体テストに必要です。パラメーターとして渡されたファイルパスでlstatを実行する関数があります。lstat失敗したコードパスをトリガーする必要があります（コードカバレッジが90％に達する必要があるため）

テストは1人のユーザーでのみ実行できるため、Ubuntuに常に存在するファイルがあるのではないかと思っていましたが、通常のユーザーにはそのファイルまたはそのフォルダーへの読み取りアクセス権がありません。（lstatrootとして実行されない限り、失敗します。）

存在しないファイルは解決策ではありません。そのための別のコードパスがあり、既にそれをトリガーしています。

編集：ファイルのみへの読み取りアクセスの不足は十分ではありません。それでlstatまだ実行できます。/ rootにフォルダーを作成し、その中にファイルを作成することで、（ルートアクセス権を持つローカルマシンで）トリガーできました。そして、フォルダにパーミッション700を設定します。そのため、ルートでのみアクセス可能なフォルダーにあるファイルを検索しています。

最新のLinuxシステムでは、/proc/1/fdinfo/0（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システムのみを検討する必要がある場合は、別の潜在的な候補です。これは、GNU libcに付属/var/cache/ldconfigするldconfigコマンドによってのみrootに読み取り+書き込み+検索可能に作成されるため、ほとんどのGNUシステムで動作するはずです。

lstat（2）のマニュアルページを見ると、ENOENT（ファイルが存在しない）以外のエラーで失敗する可能性がある場合のヒントが得られます。

最も明白なものは次のとおりです。

EACCES 検索許可がパスの接頭辞でのディレクトリのいずれかのために拒否されたパス。

したがって、検索できないディレクトリが必要です。

はい、システムにすでにあるものを探すことができます（おそらく/var/lib/private存在するのでしょうか？）しかし、次のものと同等の、自分で作成することもできます。

$ mkdir myprivatedir
$ touch myprivatedir/myunreachablefile
$ chmod 0 myprivatedir
$ ls -l myprivatedir/myunreachablefile

ここでは、lstat（2）操作はEACCESで失敗します。（ディレクトリからすべてのアクセス許可をchmod -x削除すると、ディレクトリの実行アクセス許可がその下にあるファイルにアクセスするために必要になるため、それほど多くの必要はなく、実行アクセス許可を削除するだけで十分かもしれません。）

manページを見て、lstat（2）を失敗させる別の創造的な方法があります。

ENOTDIR のパス接頭辞のAコンポーネントのパスはディレクトリではありません。

したがって、/etc/passwd/nonexistentこのエラーを引き起こすはずのようなファイルにアクセスしようとすると、ENOENT（ "No such file or directory"）とは異なり、ニーズに合うかもしれません。

もう一つは：

ENAMETOOLONG パスが長すぎます。

しかし、これには本当に長い名前が必要な場合があります（4,096バイトが典型的な制限であると信じていますが、システム/ファイルシステムにはもっと長い名前があるかもしれません）。

最後に、これらのどれが実際に役立つかを判断するのは困難です。「ファイルが存在しない」シナリオを引き起こさない何かが欲しいと言います。通常これはENOENTエラーを意味しますが、実際には多くの高レベルのチェックは単にlstat（2）からのエラーを「存在しない」と解釈します。たとえば、シェルからtest -eの同等のもの[ -e ...]は、上記のすべてを単に「存在しない」と解釈するだけです。特に、異なるエラーメッセージを返す良い方法がなく、エラーを返さないとファイルが存在することを意味します。確かにそうではありません。

find自分でできます。

使用/etc-構成ファイルディレクトリを開始点として：

sudo find /etc -type f -perm 0400 -user root

私のシステムでは、これは何も返しません。

制限を緩和してグループを許可することができroot（ユーザーのみrootがgroupのメンバーになる必要があります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ます。

技術的には、execute（x）ビットの不在だけで、ディレクトリのリスト（lstat(2)）ができなくなります。

/run/systemd/inaccessible/Systemd initベースのシステムで見つけた出力で。

内のファイルについては/proc、/sys、/dev：

• これらのファイルシステムは仮想FSです。つまり、ディスク上ではなくメモリ上に存在します。

• に依存する場合は/proc、/proc/1/PID 1の下にあるものを使用します。つまり、後のPID（プロセス）の存在が保証されないため、信頼性/一貫性を持たせるために後のPIDに依存しません。