私が普通のユーザーとしてコマンドを発行する権利を持っているかどうかを識別する方法はありますか。
例えば;実際に発行する前にshutdownコマンドを発行する権利があるかどうかを確認したい。
次のコマンドのようなもの
-> doIhaveRightToIssue shutdown
-> Yes/No
最も単純なケースは、gzip
のようなバイナリ実行可能ファイルの場合です。まず、実行可能ファイルを見つけます。
$ which gzip
/bin/gzip
次に、このファイルの属性を確認します。
$ ls -l /bin/gzip
-rwxr-xr-x 1 root root 98240 oct 27 2014 /bin/gzip
3つのxは、ファイルが所有者(最初のroot
)、またはグループroot
(2番目のroot
)のだれかによって実行される可能性があることを示しています。そのため、ユーザーはプログラムを実行できます。
ただし、実行可能ファイルは、内部の他の実行可能ファイルを呼び出すスクリプトファイルである場合があります。スクリプトを実行できても、その内部で呼び出されたプログラムは実行できない場合があります。実際に試してみる以外に、ユーザーがそれを許可されているかどうかを判断する方法はありません。
次に、shutdown
のような特殊なケースがあります。これは、実際にはsystemctl
というコアユーティリティへのシンボリックリンクです。これには、呼び出しを許可するかどうかを決定する独自のメカニズムがあります。例えば。
(which
コマンドについて:これは、実行が許可されている$ PATH内の実行可能ファイルを検索し、$ PATHに同じ名前の複数の実行可能ファイルがある場合に使用する実行可能ファイルを示します。実行可能ファイルのみを検索しません。ここで、許可を探す場所の例として使用します。which
が実行可能ファイルを見つけるという事実は、実行許可があることを示しています。)
Sudo
の場合:
$ Sudo -l shutdown
/sbin/shutdown
許可がなかった場合、Sudo
はコマンドを表示する代わりに文句を言います。
Polkitを使用して、実行するアクションを確認します。
$ pkcheck --action-id org.freedesktop.login1.power-off --process $$ -u --enable-internal-agent && echo yes
polkit\56temporary_authorization_id=tmpauthz1
yes
関連するアクションを見つけることは別の質問です。
次を使用できます。
test -x $(command -v shutdown) && echo yes || echo no
command -v shutdown
は、shutdown
コマンドへのパスを返します。 test -x
は、そのパスが実行可能であるかどうかを確認します。
コマンドを実行できる場合でも、タスクを実行するための権限が不十分なため、コマンドが失敗する場合があります。これは、コマンドを実行するためのアクセスを制限するのではなく、プログラムが実際に実行できる操作へのアクセスを制限するUnixタイプのシステムでの一般的なケースです。
まあ、それは時々難しいかもしれません...
まず、ls -l
...で権限を確認します.
owngrpotrユーザーグループコマンド -rwxr-xr-xルートビンvim
最後/ 3番目のトリプレットにx(「実行可能」)が含まれている場合、others-つまり、-を実行できます。 。それがシェルスクリプトまたはそのようなものである場合、othersにはr( "can read")も必要です。
othersが実行許可を得ていないが、group(2番目のトリプレット)がある場合、次のように実行できます。 groupのメンバー-reの例では、bin。たとえば、wheel-groupは、su
を実行できるユーザーを制限するためによく使用されるため、このグループに属するユーザーのみが実行できます。もう1つの例は、developersのグループを作成し、Cコンパイラおよびそのようなツールの実行をこのグループに制限することです。
末尾の+が最後のトリプレットの後にある場合、それはAccessControllListsが使用されることを意味します-これにより、追加のユーザーおよびグループに実行権が追加される場合があります。
+++
コマンドを実行できる場合でも、アクセスできないファイル、ディレクトリ、および/またはデバイスへのアクセスに依存する可能性があります-これにより、実行できることを制限できます(できない場合があります何をするにも)。
最後に、コマンドの実行が許可されている場合でも、コマンド自体がIDをチェックし、config-fileにリストされていないか、特定のユーザー(例:ルート)。たとえば、mount
コマンドでは、rootのみがデバイスをマウントできます-通常のユーザーは、/ etc/fstab ...にリストされているデバイスのみをマウントできます。なしかもしれません。あなたがrootではなく、何かをマウントしようとすると、mount
は文句を言い、デバイスのマウントを拒否します。別の例はSudo
で、これはすべてのユーザーに対して実行されますが、/ etc/sudoersにリストされているユーザーのみがrootとして実際に実行を許可されます。
which
、type
、command
などを使用することは、99%のケースで機能する実用的なソリューションですが、100%確実にすべての実行可能ディレクトリを手動で検査する必要があります$PATH
にリストされています。多くのシェル(bash
を含む)は、コマンドの前に$PATH
のエントリを追加し、成功するまでこれらのファイルを繰り返し実行しようとします。 which
は実際にコマンドを実行できないため、シェルが実際に選択するファイルを予測することはできません。
たとえば、PATH=/opt/arm/bin:/bin
があり、両方のディレクトリに実行可能ファイルが含まれているが、アーキテクチャが異なる場合を想像してください。 which dd
を実行すると、/opt/arm/bin/dd
が返されます(実行する権限がある場合)。そのエントリが最初に来るからです。ただし、シェルでdd
を実行すると、/bin/dd
の実行に失敗するため、/opt/arm/bin/dd
が実行されます。同じ状況は、バイナリの破損、ライブラリの欠落などの場合にも発生する可能性があります。最終的に、試行する以外にコマンドを実行できるかどうかを確認する方法はありません。
別の側面は、「許可を持っている」とみなすものです。ユーザーとして、rm ~/file
ではなくrm /root/file
を実行する権限があります。繰り返しますが、手動で検査したり、コマンドを発行して結果を観察したりすることなく、それを知る一般的な方法はありません。