web-dev-qa-db-ja.com

常に存在するファイルがあり、「通常の」ユーザーはそれをlstatできませんか？

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

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

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

編集：ファイルへの読み取りアクセスの欠如だけでは十分ではありません。それでもlstatは実行できます。/rootにフォルダーを作成し、その中にファイルを作成することで、（ローカルコンピューターで、ルートアクセスが可能な）トリガーをかけることができました。フォルダーにアクセス許可700を設定します。ルートでのみアクセスできるフォルダにあるファイルを検索しています。

linuxubuntupermissions
14
Crouching Kitten

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

21
Stéphane Chazelas

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

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

[〜＃〜] eacces [〜＃〜]のパス接頭辞にあるディレクトリの1つに対する検索権限が拒否されました道。

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

はい、システムにすでに存在するものを探すことができます（存在する場合は、おそらく/var/lib/private？）。ただし、次のものと同等のものを使用して、自分で作成することもできます。

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

Lstat（2）操作は、ここではEACCESで失敗します。 （ディレクトリからすべての権限を削除すると確実になります。ディレクトリにあるファイルにアクセスするために実行権限が必要なため、実行権限を削除するだけでも十分であり、chmod -xを削除するだけで十分です。）

Lstat（2）を失敗させる別の創造的な方法があり、そのmanページを見てください：

[〜＃〜] enotdir [〜＃〜]pathのパス接頭辞のコンポーネントはディレクトリではありません。

したがって、/etc/passwd/nonexistentなどのファイルにアクセスしようとすると、このエラーがトリガーされます。これもENOENT（「そのようなファイルまたはディレクトリはありません」）とは異なり、ニーズに合う可能性があります。

もう一つは：

[〜＃〜] enametoolong [〜＃〜]pathが長すぎます。

しかし、これには本当に長い名前が必要になる場合があります（4,096バイトが一般的な制限だと思いますが、システム/ファイルシステムの方が長い場合があります）。

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

12
filbranden

自分でfindできます。

/etcの使用-開始点としての設定ファイルディレクトリ：

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)）が表示されなくなります。

出力では、Systemd initベースのシステムで/run/systemd/inaccessible/が見つかりました。

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

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

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

6
heemayl