web-dev-qa-db-ja.com

特定のコマンドを実行する権限があるかどうかを確認するにはどうすればよいですか?

私が普通のユーザーとしてコマンドを発行する権利を持っているかどうかを識別する方法はありますか。

例えば;実際に発行する前にshutdownコマンドを発行する権利があるかどうかを確認したい。

次のコマンドのようなもの

-> doIhaveRightToIssue shutdown
-> Yes/No
18
Bernhard Colby

最も単純なケースは、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が実行可能ファイルを見つけるという事実は、実行許可があることを示しています。)

26
Jos

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

関連するアクションを見つけることは別の質問です。

21
muru

次を使用できます。

test -x $(command -v shutdown) && echo yes || echo no

command -v shutdownは、shutdownコマンドへのパスを返します。 test -xは、そのパスが実行可能であるかどうかを確認します。

コマンドを実行できる場合でも、タスクを実行するための権限が不十分なため、コマンドが失敗する場合があります。これは、コマンドを実行するためのアクセスを制限するのではなく、プログラムが実際に実行できる操作へのアクセスを制限するUnixタイプのシステムでの一般的なケースです。

8
Robie Basak

まあ、それは時々難しいかもしれません...

まず、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として実際に実行を許可されます。

5
Baard Kopperud

whichtypecommandなどを使用することは、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を実行する権限があります。繰り返しますが、手動で検査したり、コマンドを発行して結果を観察したりすることなく、それを知る一般的な方法はありません。

3