「nobody」ユーザーの目的は何ですか？
すべての人間のユーザーをリストする を読んだ後、Ubuntuシステムに「nobody」という名前のユーザーアカウントがあることに気付きました。
また、次のコマンドとパスワードを使用して、ターミナルからこのアカウントにログインできることに気付きました。
Sudo su nobody
私はまったく気にしませんが、このユーザーの目的は何ですか？ Ubuntuの新規インストールでデフォルトで作成されますか、それとも特定のパッケージをインストールすることで作成されますか？
特別な権限を必要としないものを実行するためにあります。通常、脆弱なサービス（httpdなど）のために予約されているため、ハッキングされた場合に、システムの残りの部分へのダメージを最小限に抑えることができます。
これとは対照的に、何かを実行する実際のユーザー、そのサービスが侵害された場合（Webサーバーが時々任意のコードを実行するために悪用される）、それはそのユーザーとして実行され、すべてにアクセスできますそのユーザーが持っていた。ほとんどの場合、これはルートを取得するのと同じくらい悪いです。
Ubuntu Wikiでnobodyユーザーについてもう少し読むことができます。
フォローアップに回答するには：
su nobodyでこのアカウントにアクセスできないのはなぜですか？
Sudo grep nobody /etc/shadowは、誰もパスワードを持っていないことを示し、アカウントパスワードなしではsuできないことを示します。最もクリーンな方法は、代わりにSudo su nobodyにすることです。それはあなたをかなり荒涼としたsh Shellのままにします。
このアカウントを使用することが示されている場合、特定の例を教えてもらえますか？
プログラムの操作にアクセス許可が必要でない場合。これは、ディスクアクティビティが発生しない場合に最も顕著です。
現実の世界の例は、memcached（キー値のメモリ内キャッシュ/データベース/もの）であり、私のコンピューターとサーバーの下で誰もが実行していないアカウント。どうして？許可を必要としないだけで、ファイルへの書き込みアクセス権を持つアカウントを与えることは、不必要なリスクになります。
多くのUnixバリアントでは、「nobody」は、ファイルを所有せず、特権グループも持たず、他のすべてのユーザーが持っているもの以外の能力を持たないユーザーアカウントの従来の名前です。
デーモンを制御する悪意のあるユーザーが受ける可能性のある損害を制限するために、デーモンを誰も、特にサーバーとして実行することは一般的です。ただし、このように複数のデーモンを実行すると、この手法の有用性が低下します。1つのデーモンの制御を取得すると、すべてのデーモンが制御されるためです。その理由は、誰もが所有するプロセスは、互いにシグナルを送信したり、お互いをデバッグしたりすることができず、互いのメモリを読み取ったり変更したりすることさえできないためです。
ユーザーnobodyはNFS専用です。
上記の回答は、nobodyが「一般的な」匿名/ゲストスタイルのユーザーIDであると想定しているため、かなり間違っています。
UNIX/Linuxアクセス制御モデルでは、匿名/ゲストスタイルのユーザーIDは存在せず、これらは悪い提案です。
- "デーモンを
nobodyとして実行するのが一般的です。特にサーバーは、デーモンを制御した悪意のあるユーザーが受ける可能性のある損害を制限します。 "次の理由により："ただし、この方法で複数のデーモンを実行すると、この手法の有用性が低下します。それらすべて」。 - 「これの実世界の例は、
memcached（キーと値のメモリ内キャッシュ/データベース/物）であり、nobodyアカウント。その理由は、アクセス許可がまったく必要ないため、ファイルへの書き込みアクセス権を持つアカウントをアカウントに付与するだけで、不必要なリスクになります。 "
ユーザーID 65534のnobodyユーザー名は、特定の目的のために作成および予約されており、NFSツリーエクスポートの「マップされていない」ユーザーおよびユーザーIDのプレースホルダーとしてのみ使用する必要があります。
つまり、NFSツリーエクスポート用にユーザー/ IDマッピングが設定されていない限り、エクスポート内のallファイルはnobodyが所有しているように見えます。これの目的は、インポートシステム上のすべてのユーザーがそれらのファイルにアクセスできないようにすることです（「他の」アクセス許可がない限り）。これらのファイルは（rootを除く）nobody.
したがって、nobodyをany他の目的に使用することは非常に悪い考えです。なぜなら、その目的は、誰にもアクセスしてはならないファイルのユーザー名/ユーザーIDになるからです。
Wikiエントリも非常に間違っています。
UNIX/Linuxのプラクティスでは、個別のアクセス制御ドメインを必要とする「アプリケーション」またはアプリケーション領域ごとに新しいアカウントを作成し、NFSの外でnobodyを再利用しないを作成します。
nobodyユーザーは、新規インストール時にデフォルトで作成されます（Ubuntu Desktop 13.04でチェックされます）。
多くの* nixバリアントでは、
nobodyは、ファイルを所有せず、特権グループも持たず、それら以外の能力を持たないユーザーアカウントの従来の名前ですこれは、他のすべてのユーザーが持っています（nobodyユーザーとグループは、/etc/sudoersファイルにエントリを持ちません）。daemonsを
nobodyとして実行するのが一般的です。特にサーバーは、それらを制御した悪意のあるユーザーが受ける可能性のある損害を制限します。ただし、このように複数のデーモンを実行すると、この手法の有用性が低下します。1つのデーモンの制御を取得すると、すべてのデーモンが制御されるためです。その理由は、nobodyが所有するプロセスは、互いにシグナルを送信したり、お互いをデバッグしたりすることができ、お互いのメモリを読み取ったり、変更したりすることさえできるからです。
nobody- ownedプロセスは、互いにシグナルを送信したり、Linuxでptraceを実行したりすることもできます。つまり、誰も所有していないプロセスは、他の誰も所有していないプロセスのメモリを読み書きできます。これは、
/etc/passwdファイルのnobodyユーザーのサンプルエントリです。alaa@aa-lu:~$ grep nobody /etc/passwd nobody:x:65534:65534:nobody:/nonexistent:/bin/shお気づきかもしれませんが、
nobodyユーザーはログインシェルとして/bin/shを持ち、ホームディレクトリとして/nonexistentを持っています。名前が示すように、/nonexistentディレクトリはデフォルトでは存在しません。偏執病の場合は、
nobodyのデフォルトシェルを/usr/sbin/nologinとして設定できるため、nobodyユーザーのsshログインを拒否できます。
誰も特別なユーザーおよびグループアカウントではありません。これは実際のユーザー名（およびグループ名）であり、プロセスやユーザーでも使用できるため、文字通りnobodyではありません。たとえば、一部のApache構成には、Webサイトのファイルとディレクトリを所有するユーザー/グループとして誰もありません。問題は、NFSディレクトリやWebサーバーなど、複数のプロセスがnobodyユーザーを使用する場合に発生します。
「ユーザーnobodyはNFSのみに予約されています。」の回答に対する若干の修正。 nobodyユーザーは、現時点では、バインドマウントのある非特権コンテナにも使用されます。
これはsystemd-nspawn、特に--bindマウントオプションから取得されます。
このオプションを--private-usersと組み合わせて使用すると、結果のマウントポイントはnobodyユーザーが所有することに注意してください。これは、マウントおよびそのファイルとディレクトリが、コンテナに存在しない関連するホストユーザーとグループによって引き続き所有され、ワイルドカードUID 65534（nobody）の下に表示されるためです。このようなバインドマウントが作成される場合、-bind-ro =を使用して読み取り専用にすることをお勧めします。