私が普通のユーザーとしてコマンドを発行する権利を持っているかどうかを識別する方法はありますか。
例えば; シャットダウンコマンドを実際に発行する前に、発行する権利があるかどうかを確認したい。
次のコマンドのようなもの
-> doIhaveRightToIssue shutdown
-> Yes/No
私が普通のユーザーとしてコマンドを発行する権利を持っているかどうかを識別する方法はありますか。
例えば; シャットダウンコマンドを実際に発行する前に、発行する権利があるかどうかを確認したい。
次のコマンドのようなもの
-> 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
(second root
)および他の人によってそれぞれ実行される可能性があることを示しています。そのため、ユーザーはプログラムを実行できます。
ただし、実行可能ファイルは、内部の他の実行可能ファイルを呼び出すスクリプトファイルである場合があります。スクリプトを実行できても、その内部で呼び出されたプログラムは実行できない場合があります。実際に試してみる以外に、ユーザーがそれを許可されているかどうかを判断する方法はありません。
次に、次のような特殊なケースがありますshutdown
-これは実際にはを呼び出すコアユーティリティへのシンボリックリンクsystemctl
です。 。
(which
コマンドについて:これは、実行が許可されている$ PATH内の実行可能ファイルを検索し、$ PATHに同じ名前の複数の実行可能ファイルがある場合に使用する実行可能ファイルを示します。実行可能ファイルだけを検索するわけではありません。ここで、許可を探す場所の例として使用します。which
実行可能ファイルを見つけるという事実は、実行する許可があることをすでに示しています。
which
コマンドは、$PATH
変数に追加されたディレクトリのいずれかに存在するファイルに対して十分でなければなりません。たとえば、やっsudo chmod 700 /bin/nano
たりsudo chmod 744 nano
原因which
は何も出力を生成しないように。地元の1以外の場所に存在するスクリプトについては、PATH
ディレクトリ、ls -l
またはstat
通話トリックを行います。良い答えですが、この情報を投稿に追加してください
stat -c '%a' /bin/gzip
取得するようなものを使用してください755
。
で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
関連するアクションを見つけることは別の質問です。
sudo -l
できます-それが全体のポイントです-sudoで-l
コマンドを実行できるかどうかを教えてくれます。
次を使用できます。
test -x $(command -v shutdown) && echo yes || echo no
command -v shutdown
shutdown
コマンドへのパスを返します。test -x
そのパスが実行可能であるかどうかを確認します。
コマンドを実行できる場合もありますが、タスクを実行するための権限が不十分なため、コマンドが失敗する可能性があることに注意してください。これは、コマンドを実行するためのアクセスを制限するのではなく、プログラムが実際に実行できる操作へのアクセスを制限するUnixタイプのシステムでの一般的なケースです。
alias shutdown="shutdown now"
どうですか?
$(which shutdown)
またはを使用します$(shopt -u expand_aliases && command -v shutdown)
。ただし、この問題は対話モードでのみ発生します。
まあ、それは時々難しいかもしれません...
まず第一に、権限を見てls -l
...
owngrpotrユーザーグループコマンド -rwxr-xr-xルートビンvim
最後/ 3つめのトリプレットにx(「実行可能」)が含まれている場合、他のユーザー(つまり、実行可能)が実行できます。シェルスクリプトなどの場合は、r( "読むこともできます」)。
場合は他の人が実行許可が、持っていないグループ(第2トリプレットを)あなたがメンバーなら、あなたはそれを実行することができないグループ - 、以上の例では、ビン。たとえば、wheel -groupは、多くの場合、実行できるsu
ユーザーを制限するために使用されるため、このグループに属するユーザーのみが実行できます。別の例としては、開発者向けのグループを作成し、Cコンパイラとそのようなツールの実行をこのグループに制限することがあります。
最後のトリプレットの後に末尾の+がある場合は、AccessControllListsが使用されていることを意味します。これにより、追加のユーザーおよびグループに実行権が追加される場合があります。
+++
コマンドを実行できる場合でも、アクセスできないファイル、ディレクトリ、および/またはデバイスへのアクセスに依存する可能性があります-これにより、実行できることが制限される場合があります(できない場合があります何をするにも)。
最後に、コマンドの実行が許可されている場合でも、コマンド自体がIDを確認し、config-fileにリストされていないか特定のユーザー(たとえば、root)でない限り、コマンドの使用を拒否できます。たとえば、mount
コマンドはrootにのみデバイスのマウントを許可します-通常のユーザーは、/ etc / fstab ...にリストされているデバイスのみをマウントできます。あなたがいないのであればルートや何かをマウントしようと、mount
文句を言うと、デバイスをマウントすることを拒否します。別の例はsudo
、誰に対しても実行されますが、実際には/ etc / sudoersにリストされているユーザーのみがrootとして実行できます。
使用してwhich
、type
、command
など例99%で動作しますが、100%必ず手動でリストされているすべての実行可能ディレクトリを検査する必要がありますように実用的なソリューションです$PATH
。多くのシェル(を含むbash
)は、コマンドの先頭にentresを付けて$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
。繰り返しますが、手動で検査したり、コマンドを発行して結果を観察したりしなければ、それを知る一般的な方法はありません。
sudo
)試して調べることです。テキストモードコマンドが必要sudo
な場合があり、グラフィカルコマンドが必要な場合がありgksudo
ます。を使用して、コマンドがインストールされてwhich command
いる場所を確認することもできます。場合/sbin
または/usr/sbin
-あなたは、コマンドが必要であることを期待することができますsudo
かgksudo
。