Ubuntu 12.04デスクトップシステムを実行しています。これまでのところ、いくつかのプログラムしかインストールしていません（sudo権限があります）。

1. システム上のユーザーのリストを確認すると、20人以上のユーザーのような長いリストが表示されます。これらのユーザーはいつ作成されましたか（例：デーモン、システム、同期、ゲーム、パルスなど）。これらは、インストールされる新しいプログラムにどのように関連しますか？

2. システムでプログラムを実行する場合、UIDで実行する必要があります。しかし、psを実行すると、他の多くのプログラムが異なるUID（root、daemon、avahi、syslog、colordなど）で実行されています。これらのプログラムは異なるUIDでどのように開始されましたか？

ユーザーアカウントは、実際の人間のユーザーだけでなく、システムサービスの実行やシステムファイルの所有者としても使用されます。これは、人間のユーザーのリソース（プロセス、ファイルなど）の分離とシステムサービスのリソースの分離に同じメカニズムが必要であるためです。

通常実行するプログラムは、ユーザーIDで実行されます。自分のアカウントで実行されるのはシステムデーモンだけです。デーモンをいつ実行するかを示す構成ファイルは、デーモンを実行するユーザーも示すか、デーモンは起動後に非特権アカウントに切り替えます。一部のデーモンは完全な管理特権を必要とするため、rootアカウントで実行されます。多くのデーモンは特定のハードウェアデバイスまたは特定のファイルへのアクセスのみを必要とするため、専用のユーザーアカウントで実行されます。これはセキュリティのために行われます。その方法では、これらのサービスの1つにバグや設定ミスがあっても、完全なシステム攻撃につながることはありません。ファイルの上書き、プロセスのスパイなどが可能

Ubuntuでは、システムのインストール時に0〜99の範囲のユーザーIDが作成されます。0はルートです。1から99の範囲にあるものの多くは、歴史的な理由のためにのみ存在し、それらを使用する一部のローカルインストールとの下位互換性のためにのみ保持されます（いくつかの余分なエントリは損傷しません）。100〜999の範囲のユーザーIDは、専用のユーザーIDを必要とするサービスがインストールまたは削除されるときに動的に作成および削除されます。1000以降の範囲は、人間のユーザーまたはシステム管理者が作成したその他のアカウント用です。グループについても同じことが言えます。

私はあなたがチェックしてこのユーザーのリストを見つけていると思います/etc/passwdか？これはまったく正常です-「ユーザー」は、「実際のユーザー」だけでなく、システムの特定の領域へのプログラムをロックダウンし、彼らが変更したものを追跡するのに役立つ一連の許可を運ぶのに役立ちます（グループと同じ概念）。

/etc/passwd参考のために、Raspberry Pi ファイルの1つを下に挿入しました。ntopこのファイルの下部に、プログラムによって作成されたユーザーが表示されますntop（ネットワーク監視）。同様にsshd、gnatsバグ報告など

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
pi:x:1000:1000:,,,:/home/pi:/bin/bash
sshd:x:101:65534::/var/run/sshd:/usr/sbin/nologin
ntp:x:102:104::/home/ntp:/bin/false
statd:x:103:65534::/var/lib/nfs:/bin/false
messagebus:x:104:106::/var/run/dbus:/bin/false
usbmux:x:105:46:usbmux daemon,,,:/home/usbmux:/bin/false
lightdm:x:106:109:Light Display Manager:/var/lib/lightdm:/bin/false
smmta:x:107:110:Mail Transfer Agent,,,:/var/lib/sendmail:/bin/false
smmsp:x:108:111:Mail Submission Program,,,:/var/lib/sendmail:/bin/false
Debian-exim:x:109:113::/var/spool/exim4:/bin/false
ntop:x:110:115::/var/lib/ntop:/bin/false

これらのユーザーはいつ作成されましたか？

あなたが言及したものの場合、それらはシステムのインストール時に作成されました。これらのユーザーアカウントは従来のもので、数十年前のものもあります。それらも標準化されています。Linux Standard Baseは、それらを以下に分割します。

• 必要に応じ、標準のユーザーアカウントをroot、binとdaemon。そして
• オプションの標準ユーザーアカウントadm、lp、sync、shutdown、halt、mail、news、uucp、operator、man、およびnobody

ここで言及されている他のユーザーアカウントは- 、pulse、avahi、colord及びDebian-exim（py4onのパスワードファイルから1選ぶ） -あなたの次の質問に私たちをもたらします。

これらは、インストールされる新しいプログラムにどのように関連しますか？

非標準のユーザーアカウントは、さまざまなパッケージの「メンテナンススクリプト」によって作成および破棄されます。これらのパッケージはインストールおよびパージされるためです。ユーザーアカウントは、パッケージのいわゆるpostinstメンテナースクリプトによって作成されます。このスクリプトはgetent、ユーザーアカウントが既に存在するかどうかを確認するために実行されますuseradd。理論的には、パッケージのいわゆるpostrmメンテナースクリプト、実行によって削除されますuserdel。

実際には、パッケージのユーザーアカウントは削除されません。Fedora wiki（qv）は、これには困難が伴うと説明しています。参照Debianのバグ＃646175単純に決定されたアクションで、この根拠の例について、いない削除するにはrabbitmq、パッケージが削除されたときに、そのアカウントの庇護の下で実行続けデーモンの問題を解決するために、ユーザーアカウントを。

これらのプログラムは異なるUIDでどのように開始されましたか？

UnixおよびLinuxでは、スーパーユーザーの保護下で実行されているプロセスは、そのユーザーアカウントを別のアカウントに変更し、同じプログラムを実行し続けることができますが、その逆は許可されません。（set-UIDメカニズムを使用する必要があります。）

デーモン管理システムはスーパーユーザーとして実行されます。その構成データは、特定のデーモンが特定のユーザーアカウントの保護下で実行されることを指定します。

• System 5 rcでは、スクリプトは/etc/init.dなどのヘルパーツールstart-stop-daemonとその--chuidオプションを使用します。
• daemontoolsの家族サービスマネージャでは、runスクリプトの呼び出しsetuidgid、s6-setuidgid、chpst、またはrunuidユーザーアカウント名を持ちます。ユーザーアカウントを設定する/unix//a/179798/5132にこの例がありnagiosます。
• upstart setuidでは、ジョブファイルにユーザーアカウントを指定するスタンザがあります。これは特にきめ細かいものではなく、/superuser//a/723333/38062で説明されているものが必要な場合があります。
• systemd User=では、ユーザーアカウントを指定する設定がサービスユニットファイルにあります。

デーモン管理システムがデーモンになるプロセスを生成すると、これらのメカニズムはスーパーユーザー特権をドロップし、デーモンプロセスは特権のないユーザーアカウントの保護下で実行され続けます。

良いデーモン管理がこのように行われる理由はかなり長い説明があります。しかし、あなたは理由を尋ねませんでした。いつ、どのように、どこから。thereforeしたがって、非常に短い説明：

UnixおよびLinuxオペレーティングシステムは、異なるユーザーアカウントの保護下で実行されているプロセスを互いに隔離します。歴史的に、スーパーユーザーとして実行されたデーモンを引き継ぐことができれば、好きなことを何でもすることができました。一方、非特権アカウントの保護下で実行されるデーモンは、その非特権アカウントができるファイル、ディレクトリ、デバイス、およびプロセスにのみアクセスできます。システム相互信頼できないデーモンプログラムは、すべての異なるユーザーアカウントのaegisesの下で実行されていると、お互いのアクセス/コントロールにできない（内部、信頼された）ファイル/ディレクトリ/プロセス/デバイスを、それゆえ、そのはるかに困難クラックすることです。

参考文献

• ジョナサン・ド・ボイン・ポラード（2014）。実行スクリプトとサービスユニットを並べて見る。。よくある回答。
• メンテナースクリプトでのアカウント処理。Debian wiki。
• 包装：UsersAndGroupsを。Fedora Project wiki。
• 「第15章ユーザーとグループ」。 Linuxの標準ベース仕様2.1。2004.フリースタンダードグループ。
• 「9.2ユーザーとグループ」。Debianポリシーマニュアル。2014-11-22。Debianポリシーのメーリングリスト。
• 「37.3。標準ユーザー」。 RHEL導入ガイド。第11版。2013. Red Hat。
• ユーザーとグループ。Arch wiki。
• キャロル・ハーウィッツとスコット・マクピーク（2001-02-12）。 ルートデーモンを廃止！。 DOI 10.1.1.120.3567。

Linuxでは、サービスをインストールすると、そのサービス名またはそれに類似したユーザーが作成され、他のファイルにアクセスできなくなります。