500未満のUIDで通常のユーザーを作成する危険性は何ですか? UIDが既存のUIDの複製ではないと想定すると、何が問題になるのでしょうか?
これは私がやりたいことではありませんが、私が見たことがあり、なぜそれをすべきでないのかを知りたいのです。この例では、RHEL5にあります。
私は固有のリスクがあるとは信じていません。これは、システムアカウントとユーザーアカウントと見なされるものを分離するためだけに行われるものです。私の経験から、500未満の数値を使用する習慣はRedhat-ismであり、それ以上のものはありません。
Solarisでは、ユーザーに100から始まる番号が割り当てられているのを見たことがありますが、同じUIDを持つ2つの部門に複数のユーザーがいるため、2つの小さな部門のシステムをマージすると、ある種の悪夢が発生することが数年後に判明しました。/GIDが割り当てられています。
これは本当に、UIDを割り当てる際の主なリスク/頭痛の種です。 UIDは、ユーザーの特定のファイル/ディレクトリのiノードに最終的に書き込まれるものであるため、UID 1234が所有するファイルを探して大規模なfind
を実行している必要はありません。それらを5678に変更します。
そのため、UIDの選択に多少の注意を払うことで、管理者は将来の悩みを回避できます。
500以上の使用は、Redhat(および他のUnix)が、作成する必要のあるシステムアカウントがユーザーに割り当てられたUIDと混ざらないように十分なバッファーを提供する試みです。
ちなみに、500という数字は、設定ファイル/etc/login.defs
。
#
# Min/max values for automatic uid selection in useradd
#
UID_MIN 500
UID_MAX 60000
#
# Min/max values for automatic gid selection in groupadd
#
GID_MIN 500
GID_MAX 60000
useradd
/adduser
コマンドでデフォルトの動作を上書きしたい場合は、これを好きなように変更できます。
useradd
のmanページを見ると、GIDのデフォルト値について説明しているこの部分に気づくでしょうが、このコメントはUIDにも適用できます。
抜粋
-g, --gid GROUP
The group name or number of the user´s initial login group. The group name
must exist. A group number must refer to an already existing group.
If not specified, the behavior of useradd will depend on the USERGROUPS_ENAB
variable in /etc/login.defs. If this variable is set to yes
(or -U/--user-group is specified on the command line), a group will be
created for the user, with the same name as her loginname. If the variable
is set to no (or -N/--no-user-group is specified on the command line),
useradd will set the primary group of the new user to the value specified by
the GROUP variable in /etc/default/useradd, or 100 by default.
useradd
のmanページでもう1つ注意すべき点は、システムアカウントの生成に関するこのビットです。
抜粋
-r, --system
Create a system account.
System users will be created with no aging information in /etc/shadow,
and their numeric identifiers are choosen in the SYS_UID_MIN-SYS_UID_MAX
range, defined in /etc/login.defs, instead of UID_MIN-UID_MAX (and their
GID counterparts for the creation of groups).
Note that useradd will not create a home directory for such an user,
regardless of the default setting in /etc/login.defs (CREATE_HOME). You
have to specify the -m options if you want a home directory for a system
account to be created.
これがこのメソッドです(useradd -r ...
)これは、パッケージのインストール時に、RPMなどのさまざまなパッケージマネージャーに組み込まれているスクリプトでよく使用されます。この方法でスクリプトを作成すると、システムは、システムのユーザーに既に割り当てられているUID/GIDを踏むリスクなしに、システムで次に使用可能なUID/GIDを自動的に選択できます。
カーネルの観点からは、特別なユーザーはUID 0のみです。管理上の理由でUIDの範囲を分割すると、作業が簡単になります。一般的な範囲は、ベンダー、システム、ローカル、グローバルです。
ベンダーユーザーは、システムの初期インストール時にインストールされ、ベンダーによって静的に管理されます。システムユーザーは、インストールされているパッケージに応じて、マシンごとにインストールされます。ほとんどのユーザー追加/削除ユーティリティには、これらを個別に処理するための範囲制限があります。ローカルユーザーは通常のユーザーであり、マシンごとに割り当てられます。グローバルユーザーは中央データベースによって割り当てられますが、通常のユーザーです。 UID範囲を使用すると、これらの異なるグループ間の競合を防止できます。これらのカットオフの場所はさまざまですが、通常は構成可能です。
本当の危険はありません。カーネルは0以外のユーザーID値を考慮しません。ほとんどの管理ツールも考慮しません。システムのごく一部がシステムユーザーと人間のユーザーを区別します。
システムユーザーは専用のグループを持つ傾向があるため、必要以上のグループに属するアカウントを作成することはほとんどありません。
一部のディストリビューションでは、専用ユーザーを必要とするシステムサービスを含むパッケージをインストールするときに割り当てられたユーザーを含め、システムユーザー用に1〜499(Red Hatおよび親族)または1〜999(Debianおよび親族)の範囲を予約しています。 Debianの慣習では、1〜99の範囲は静的に割り当てられます(したがって、その範囲で人間のユーザーを作成することは、システムユーザーと衝突する可能性があるため、非常に悪い考えです)一方で、100〜999の範囲は動的に割り当てられます(したがって、人間のユーザーを作成します)新しいシステムユーザーは無料のユーザーIDを選択するため、この範囲内は無害です。
ディスプレイマネージャーがリストのしきい値を下回るUIDをユーザーに提供しないなど、軽微な不都合が発生する可能性があります。
孤立したマシンの主な危険は、システム管理者を混乱させる可能性があることです。ユーザーIDが共有されているネットワーク内のマシンの場合、これらのユーザーがシステムユーザーと同じユーザーIDを持っている他のマシンと競合する可能性があります。ユーザーIDが共有されているネットワークでは、人間のユーザーの場合は1000〜65533の範囲、さらには10000〜65533の範囲を守ることが最善です。
これを行うことに固有の危険はありません。 UID 499のユーザーを作成する場合、ユーザーには特別な特権はありません。推奨されない理由は、単にUIDが通常システムユーザー用に予約されているためです。このようなUIDを作成するときに遭遇する可能性がある問題は、一部のシステムサービスがUIDが使用可能であると想定している場合です。これは、よく知られたポートで実行する新しいサービスを作成するようなものです。必ずしも問題はありませんが、これは良い方法ではなく、sshdやftpdなどを設定しているときに問題が発生する可能性があります。
とはいえ、ユーザーがUID <500で問題なく作成された多くのシステムを見てきました。ただし、ユーザーベースが拡大し、現在は数千のユーザーがいるため、ユーザーアカウントとシステムアカウントを区別することが困難になる可能性があります。 UIDが500未満というルールに従うと、非常に簡単です。そのため、アカウントを整理するのにもいい方法です。