2 sudo
の基本 #
特定のコマンドを実行するには、root特権が必要です。ただし、セキュリティ上の理由のため、また間違いを避けるため、root
としてログインすることは推奨されません。より安全な方法は、通常のユーザとしてログインしてから、sudo
を使用して昇格された特権でコマンドを実行することです。
SUSE Linux Enterprise Serverでは、sudo
はsu
と同様に機能するように設定されています。ただし、sudo
には、ユーザが他のユーザの特権でコマンドを実行できるようにする柔軟なメカニズムがあります。このコマンドを使用して、指定の特権を持つ役割を特定のユーザとグループに割り当てることができます。たとえば、users
グループのメンバーが、wilber
ユーザの特権でコマンドを実行できるようにすることができます。コマンドへのアクセスは、コマンドオプションを禁止することにより、さらに制限できます。suでは、PAMを使用した認証で常にroot
パスワードを必要としますが、sudo
では、ユーザの資格情報を使用して認証するように設定できます。すなわち、ユーザはroot
パスワードを共有する必要がなく、セキュリティが向上します。
2.1 sudo
の基本的な使用方法 #
次の章では、sudo
の基本的な使用方法の概要について説明します。
2.1.1 単一コマンドの実行 #
標準ユーザは、コマンドの前にsudo
を追加することで、任意のコマンドをroot
として実行できます。これにより、rootパスワードを入力するように求められます。正常に認証されたら、root
としてコマンドが実行されます。
>
id -un
1 tux>
sudo
id -un
root's password:2 root>
id -un
tux3>
sudo
id -un
4 root
| |
入力時には、パスワードは表示されません(クリアテキストとしてだけでなく、マスク文字としても表示されません)。 | |
| |
昇格された特権は特定の期間保持されるため、再び |
sudo
の使用時に、I/Oリダイレクトは機能しません。
>
sudo
echo s > /proc/sysrq-trigger bash: /proc/sysrq-trigger: Permission denied>
sudo
cat < /proc/1/maps bash: /proc/1/maps: Permission denied
上記の例では、echo
およびcat
コマンドのみが昇格された特権で実行されます。リダイレクトはユーザの特権を使用してユーザのシェルで実行されます。昇格された権限でリダイレクトを実行するには、2.1.2項 「シェルの起動」に記載されているようにシェルを起動するか、dd
ユーティリティを使用します。
echo s | sudo dd of=/proc/sysrq-trigger sudo dd if=/proc/1/maps | cat
2.1.2 シェルの起動 #
昇格された特権でコマンドを実行するたびにsudo
を使用することは、必ずしも実用的ではありません。sudo
bash
コマンドを使用できますが、組み込みメカニズムのいずれかを使用してシェルを起動することをお勧めします。
sudo -s (<command>)
SHELL
環境変数で指定したシェル、またはターゲットユーザのデフォルトのシェルを起動します。コマンドが指定される場合は、シェルに渡されます(-c
オプションを使用)。そうでない場合、シェルは対話的モードで実行されます。tux:~ >
sudo -s root's password:root:/home/tux #
exittux:~ >
sudo -i (<command>)
-s
と同様ですが、シェルはログインシェルとして起動します。これは、シェルの起動ファイル(.profile
など)が処理され、現在の作業ディレクトリがターゲットユーザのホームディレクトリに設定されることを意味します。tux:~ >
sudo -i root's password:root:~ #
exittux:~ >
デフォルトでは、sudo
は環境変数を伝達しません。この動作は、env_reset
オプションを使用して変更できます(有用なフラグとオプションを参照してください)。
2.2 sudo
の構成 #
sudo
は、設定可能なオプションの幅広い範囲を提供します。
誤ってsudo
からロックアウトした場合は、su
-
とroot
パスワードを使用してルートシェルを起動してください。エラーを修正するには、visudo
を実行します。
以下で紹介するルールの例はデモンストレーションのみを目的としています。これらのルール例を利用して、sudo
設定ファイルの一般的な構文を理解してください。実際の環境では、このルール例をそのまま使用しないでください。環境の複雑さを反映していないからです。
2.2.1 sudo
の設定でのベストプラクティス #
まず、sudo
設定を維持するための基本ルールについて説明します。
sudo
の設定ファイルの編集には必ずvisudo
を使用するsudo
の設定の変更では、どの場合もvisudo
コマンドを使用する必要があります。visudo
は、sudo
設定ファイルを編集することができ、基本的な構文チェックを実行して、設定がそのまま機能できるようにする、オーダーメイドツールです。sudo
の設定に不備があると、ユーザが自身のシステムからロックアウトされることがあります。- 必ず
/etc/sudoers.d/
にカスタム設定を作成する カスタム設定は、
sudo
によって取得できるように、/etc/sudoers.d/
に置く必要があります。カスタム設定ファイルに記述した設定は、/etc/sudoers
のデフォルト設定よりも優先されます。- 設定が読み取られる順序にいつでも注意する
カスタム設定が確実に正しい順序で読み取られるように数字のプレフィクスを付加します。先頭に0を付加してファイルの読み取り順序を指定します。これにより、たとえば
01_myfirstconfig
は10_myotherconfig
よりも前に解析されます。順番に読み取られる複数のディレクティブを設定したファイルで、これらの各ディレクティブに記述された情報が互いに矛盾していると、最後に読み込まれたディレクティブが適用されます。- 必ずわかりやすいファイル名を使用する
設定ファイルの機能がわかるようなファイル名を使用します。
sudo
のセットアップで想定している動作を追跡する際に、この措置が効果的です。
2.2.2 ユーザ固有の設定ファイルの作成 #
通常のユーザ(tux
)が、root
パスワードではなく自身のパスワードを使用して、useradd
コマンドを使用できるように、sudo
の設定ファイルを作成します。
新しいユーザ固有のディレクティブを保持するカスタム設定ファイルを作成します。そのためには、システム管理者(
root
)としてvisudo
を起動します。番号付けと説明的な名前の両方を使用します。#
visudo -f /etc/sudoers.d/02_usermanagement
この
sudo
設定を適用する環境全体でtux
が/usr/sbin/useradd
バイナリを実行できるようにするルールを作成します。tux1 ALL2 = /usr/sbin/useradd3
ユーザまたはグループを指定します。ユーザは、名前または
#UID
で一覧にし、グループは、%GROUPNAME
で一覧にします。複数の項目はコンマで区切ります。エントリを無効にするには!
を使用します。ホストを1つまたはコンマで区切って複数指定します。完全修飾ホスト名またはIPアドレスを使用します。すべてのホストにこの設定をグローバルに適用するには
ALL
を追記します。適用しない場合は!
を使用します。実行可能ファイルを1つまたはコンマで区切って複数指定します。各ファイルの指定では次のルールに留意します。
/usr/sbin/useradd
追加オプションを追記しない場合は、実行可能なすべての
useradd
コマンドを実行できます。/usr/sbin/useradd -c
明示的にオプションを指定すると、そのオプションのみが適用されます。上記で指定したユーザは、これ以外のオプションを利用できません。
/usr/sbin/useradd ""
オプションを指定せずに
useradd
の呼び出しのみができるようにします。
上記の例では、すべてのオプションおよびサブコマンドを許可したり、セキュリティ上の理由からいくつかに制限したりできますが、ユーザがオプションを指定できないようにすることは、このコンテキストでは意味がありません。
ユーザが
root
パスワードの代わりに、自分のパスワードを使用できるようにするには、次の行を追加します。Defaults:tux !targetpw
このフラグがアクティブな場合、目的のユーザ(
root
)のパスワードの入力が求められます。SUSE Linux Enterprise Serverシステムでは、このフラグがデフォルトで有効になっています。!
を使用してこのフラグを無効にすると、ユーザはroot
パスワードの代わりに自分のパスワードの入力を求められます。設定を保存し、エディタを終了して、2番目のシェルを開き、
sudo
が新しい設定に従うかどうかをテストします。
2.2.3 項目のグループ化によるカスタム設定の作成 #
指定したユーザのグループがroot
パスワードを必要とせずにuseradd
コマンドを実行できるように、例2.1「ユーザ固有の設定ファイルの作成」の設定を変更します。また、このグループで使用できるコマンドのリストにusermod
とuserdel
を追加します。
この設定例を変更するには、
visudo
を使用してシステム管理者として設定を開きます。#
visudo /etc/sudoers.d/02_usermanagement
コンマ区切りで記述した複数のユーザをルールに追加します。
tux, wilber ALL = /usr/sbin/useradd
ここで記述したユーザが複数のコマンドを実行できるようにするには、それらのコマンドをコンマ区切りで指定します。
tux, wilber ALL = /usr/sbin/useradd, /usr/sbin/usermod, /usr/sbin/userdel
ここで記述したユーザが
root
パスワードの代わりに、自分のパスワードを使用できるようにするには、次の行を追加します。Defaults:tux, wilber !targetpw
このフラグがアクティブな場合、ここで記述したユーザは目的のユーザ(
root
)のパスワードの入力が求められます。SUSE Linux Enterprise Serverシステムでは、このフラグがデフォルトで有効になっています。!
を使用してこのフラグを無効にすると、ここで記述したユーザはroot
パスワードの代わりに自分のパスワードの入力を求められます。設定を保存し、エディタを終了して、2番目のシェルを開き、
sudo
が新しい設定に従うかどうかをテストします。
2.2.4 エイリアスの適用による設定の簡潔化 #
エイリアスを使用して、例2.2「項目のグループ化によるカスタム設定の作成」のカスタム設定の簡素化を進めます。項目をグループ化することはある程度役立ちますが、ユーザ、コマンド、およびホストのグローバルエイリアスを使用することが、クリーンで無駄のないsudo
設定を保つための最も効率的な方法です。
リストの代わりにエイリアスやグループを使用する方が、セットアップの変更に対処する上ではるかに良い方法です。グループからユーザが離れる場合は、独立したカスタム設定ファイルをすべて調べるのではなく、エイリアス宣言ファイル内のグローバルUser_Alias
宣言からそのユーザを削除するだけですみます。他のタイプのエイリアス(Host_Alias
、Cmnd_Alias
、およびRunas_Alias
)についても、同じ手順が適用されます。
グローバルエイリアス定義を保持する新しいファイルを作成します。
#
visudo /etc/sudoers.d/01_aliases
次の行を追加して、
TEAMLEADERS
エイリアスを作成します。User_Alias TEAMLEADERS = tux, wilber
次の行を追加して、
USERMANAGEMENT
エイリアスを作成します。Cmnd_Alias USERMANAGEMENT = /usr/sbin/useradd, /usr/sbin/usermod, /usr/sbin/userdel
変更を保存し、
visudo
を終了します。システム管理者として
visudo
を起動して、設定ファイル例を次のように編集します。#
visudo -f /etc/sudoers.d/02_usermanagement
前のルールを削除し、上記で定義したエイリアスを使用する次のルールに置き換えます。
TEAMLEADERS ALL = USERMANAGEMENT
User_Alias
で定義されたすべてのユーザがroot
パスワードの代わりに、自分のパスワードを使用できるようにするには、次の行を追加します。Defaults:TEAMLEADERS !targetpw
設定を保存し、エディタを終了して、2番目のシェルを開き、
sudo
が新しい設定に従うかどうかをテストします。
2.2.5 基本的なsudoersの設定構文 #
sudoersの設定ファイルには、2種類のオプション(文字列とフラグ)があります。文字列には任意の値を含めることができますが、フラグはONかOFFのいずれかのみです。sudoersの設定ファイルの最も重要な構文構造は次のとおりです。
# Everything on a line after # is ignored 1 Defaults !insults # Disable the insults flag 2 Defaults env_keep += "DISPLAY HOME" # Add DISPLAY and HOME to env_keep tux ALL = NOPASSWD: /usr/bin/frobnicate, PASSWD: /usr/bin/journalctl 3
例外が2つあります。 | |
| |
2.2.6項 「基本的なsudoersのルール」を参照してください。 |
targetpw
このフラグは、呼び出し元のユーザが、ターゲットユーザのパスワード(ON)(
root
など)と、呼び出し元のユーザのパスワード(OFF)のいずれを要求されるかを決定します。Defaults targetpw # Turn targetpw flag ON
rootpw
設定すると、
sudo
は、root
パスワードを要求します。デフォルトはOFFです。Defaults !rootpw # Turn rootpw flag OFF
env_reset
設定すると、
sudo
はTERM
、PATH
、HOME
、MAIL
、SHELL
、LOGNAME
、USER
、USERNAME
、およびSUDO_*
で最小限の環境を構築します。また、env_keep
に列挙されている変数は、呼び出し元の環境からインポートされます。デフォルトは[ON]です。Defaults env_reset # Turn env_reset flag ON
env_keep
env_reset
フラグがONの場合に保持する環境変数の一覧。# Set env_keep to contain EDITOR and PROMPT Defaults env_keep = "EDITOR PROMPT" Defaults env_keep += "JRE_HOME" # Add JRE_HOME Defaults env_keep -= "JRE_HOME" # Remove JRE_HOME
env_delete
env_reset
フラグがOFFの場合に削除する環境変数の一覧。# Set env_delete to contain EDITOR and PROMPT Defaults env_delete = "EDITOR PROMPT" Defaults env_delete += "JRE_HOME" # Add JRE_HOME Defaults env_delete -= "JRE_HOME" # Remove JRE_HOME
Defaults
トークンを使用することで、ユーザ、ホスト、およびコマンドのコレクションのエイリアスを作成することもできます。さらに、一連のユーザのみを対象としてオプションを適用することができます。
sudoers設定ファイルの詳細については、man 5
sudoers
を参照してください。
2.2.6 基本的なsudoersのルール #
各ルールは、次のスキームに従います([]
はオプション部分を示しています)。
#Who Where As whom Tag What User_List Host_List = [(User_List)] [NOPASSWD:|PASSWD:] Cmnd_List
User_List
1つ以上の(コンマで区切られた)識別子。ユーザ名、
%GROUPNAME
形式のグループ、または#UID
形式のユーザIDを指定します。否定は!
プレフィクスで指定できます。Host_List
1つ以上の(コンマで区切られた)識別子。(完全修飾された)ホスト名またはIPアドレスのいずれかを指定します。否定は
!
プレフィクスで指定できます。通常、Host_List
にはALL
を選択します。NOPASSWD:|PASSWD:
NOPASSWD:
の後に記述した、Cmd_List
と一致するコマンドを実行する場合は、パスワードが要求されません。PASSWD
はデフォルトです。PASSWD
とNOPASSWD
の両方が同じ行に存在する場合にのみ指定する必要があります。tux ALL = PASSWD: /usr/bin/foo, NOPASSWD: /usr/bin/bar
Cmnd_List
1つまたは複数の(コンマで区切られた)指定子。実行可能ファイルへのパスの後に、オプションで使用可能な引数を指定します。
/usr/bin/foo # Anything allowed /usr/bin/foo bar # Only "/usr/bin/foo bar" allowed /usr/bin/foo "" # No arguments allowed
ALL
は、User_List
、Host_List
、およびCmnd_List
として使用できます。
パスワードを入力しなくても、tux
がすべてのコマンドをrootとして実行できるようにするルールは次のとおりです。
tux ALL = NOPASSWD: ALL
tux
がsystemctl restart
apache2
を実行できるようにするルールは次のとおりです。
tux ALL = /usr/bin/systemctl restart apache2
tux
がwall
をadmin
として引数なしで実行できるようにするルールは次のとおりです。
tux ALL = (admin) /usr/bin/wall ""
Defaults targetpw
なしで、ALL ALL =
ALL
のようなルールを使用「しないでください」。そうしないと、だれでもroot
としてコマンドを実行できるようになります。
sudoers
ファイルでグループ名を指定する場合は、レルムの代わりにNetBIOSドメイン名を使用するようにしてください。次に例を示します。
%DOMAIN\\GROUP_NAME ALL = (ALL) ALL
winbinddを使用する場合、この形式は、smb.conf
ファイルのwinbind separator
オプションによっても異なることに注意してください。デフォルトでは、\
です。たとえば、+
に変更された場合、sudoers
ファイルのアカウント形式はDOMAIN+GROUP_NAME
である必要があります。
2.3 X.Orgアプリケーションでのsudo
の使用 #
グラフィカルアプリケーションをsudo
で起動すると、通常、次のエラーが発生します。
>
sudo
xterm xterm: Xt error: Can't open display: %s xterm: DISPLAY is not set
簡単な回避策は、xhostを使用して、ルートユーザがローカルユーザのXセッションに一時的にアクセスできるようにすることです。これは、次のコマンドを使用して実行されます。
xhost si:localuser:root
次のコマンドは許可されたアクセスを削除します。
xhost -si:localuser:root
ルート特権でグラフィカルアプリケーションを実行すると、セキュリティに影響を与えます。例外としてのみグラフィカルアプリケーションのルートアクセスを有効にすることをお勧めします。グラフィカルアプリケーションが閉じられたらすぐに、許可されたルートアクセスを取り消すことも推奨されます。
2.4 詳細情報 #
sudo --help
コマンドは、使用可能なコマンドラインオプションの簡単な概要を提供し、man sudoers
コマンドは、sudoers
とその設定に関する詳細情報を提供します。