ブロックデバイス権限が実際に何を意味するかについての情報が見つかりません。ブロックデバイスに対する読み取り権限はどういう意味ですか?これはhexdumpのようなことができないという意味ですか?書き込み権限はどうですか?または処刑?
また、デバイスに対するr、w、またはx権限ではなく、特定のデバイスのみをマウントできるsudo権限をユーザーに付与して、デバイスに対するマウント権限がある場合はどうなりますか?どうしたの?
ベストアンサー1
単純な場合(ファイルのようにデバイスにアクセスする場合)@Jasenは、次のように書きました。
- 読み取り権限を使用すると、デバイスから読み取ることができます(ダンプ、
fsck
読み取り専用モードで実行など)。 - 書き込み権限を使用すると、デバイスに書き込むことができます(画像の上書きなど)。
- 実行、読み取りなど、読み取りに必要な
fsck
すべての権限がtune2fs
必要です。そしてファイルシステムを変更します。 - 実行権限は無視されます。デバイスファイルを実行しようとすると、ブロックデバイスに有効な実行コードが含まれていても、「許可拒否」というメッセージが表示されます。
rootユーザーの場合、通常は次のようになりますCAP_DAC_READ_SEARCH
。CAP_DAC_OVERRIDE
能力、これは権限フラグが完全に無視されることを意味します。
~のためI/W制御より複雑なのは次のとおりです。
ioctlを実行するには、次のことができる必要があります。開いているつまり、少なくとも読み取りまたは書き込み権限が必要であることを意味します。
他のすべてはドライバーによって異なります。一部のデバイスドライバは、CAP_SYS_RAWIO
または同じ機能のみをチェックし、CAP_SYS_ADMIN
一部は読み取り権限に「無害な」ioctlを使用し、情報および他のioctlに対する読み取り+書き込み権限のみを提供します。デバイスドライバがioctl権限を確認するために実行権限を使用することは可能ですが、これを実行するドライバはありません。
~のため山より簡単:
システムmount
コールは次の2つですが確認してください。
- できなければならない到着デバイスファイル。つまり、デバイスファイルパスのすべてのディレクトリには少なくとも実行許可ビットが設定されている必要があります(またはその機能が必要です
CAP_DAC_READ_SEARCH
)。 - この機能が必要です
CAP_SYS_ADMIN
(通常はルートの場合に取得できます)。
デバイスファイル自体の許可ビットはマウント時に完全に無視され、マウントされたファイルシステムへのアクセスには何の影響もありません。
使用Sudo利用可能なすべての機能を使用して、実行されたプログラムをrootとして実行します。これは、すべての権限チェックが無視されることを意味し、@Jasenがコメントに書いたように、通常は/bin/mount
setuid-rootであるため、常に利用可能なすべての機能を取得するため、権限ビットはありません。mount
ほとんどのLinuxディストリビューションへの影響その他のUNIXオペレーティングシステム。
編集する:機能のセクションはLinuxにのみ適用されます。他のUnixoidオペレーティングシステム(BSDやOSXなど)は、ルートの特別な機能を機能に分離しないため、その機能に関してはルートのみが必要です。利用可能なマンページによると、検査はmount
私が説明したLinux関連の検査と似ています。どのオペレーティングシステムもインストール時に許可ビットをチェックしないようです。