「nobody」ユーザーの目的は何ですか？

すべての人間のユーザーのリストを読んだ後、Ubuntuシステムに「nobody」という名前のユーザーアカウントがあることに気付きました。

また、次のコマンドとパスワードを使用して、ターミナルからこのアカウントにログインできることに気付きました。

sudo su nobody

私はまったく気にしませんが、このユーザーの目的は何ですか？Ubuntuの新規インストールでデフォルトで作成されますか、それとも特定のパッケージをインストールすることで作成されますか？

特別な権限を必要としないものを実行するためにあります。通常、脆弱なサービス（httpdなど）のために予約されているため、ハッキングされた場合に、システムの残りの部分へのダメージを最小限に抑えることができます。

実際のユーザーとして何かを実行するのとは対照的に、そのサービスが危険にさらされると（Webサーバーは任意のコードを実行するために悪用されることがあります）、そのユーザーとして実行され、そのユーザーが持っているすべてにアクセスできます。ほとんどの場合、これはrootになるのと同じくらい悪いです。

Ubuntu Wikiでnobodyユーザーについてもう少し読むことができます。

• https://wiki.ubuntu.com/nobody

フォローアップに回答するには：

でこのアカウントにアクセスできないのはなぜsu nobodyですか？

sudo grep nobody /etc/shadow誰もパスワードを持っていないsuことと、アカウントパスワードなしではできないことを示します。sudo su nobody代わりに最もクリーンな方法です。それはかなり荒涼としたshシェルのままになります。

このアカウントを使用するように指示されている場合、特定の例を挙げることができますか？

プログラムの操作にアクセス許可が必要でない場合。これは、ディスクアクティビティが発生しない場合に最も顕著です。

これの実際の例はmemcached（キーと値のメモリ内キャッシュ/データベース/もの）で、私のコンピューターとサーバーにnobodyアカウントで実行されています。どうして？許可を必要としないだけで、ファイルへの書き込みアクセス権を持つアカウントを与えることは、不必要なリスクになります。

多くのUnixバリアントでは、「nobody」は、ファイルを所有せず、特権グループも持たず、他のすべてのユーザーが持っているもの以外の能力を持たないユーザーアカウントの従来の名前です。

デーモンを制御する悪意のあるユーザーが受ける可能性のある損害を制限するために、デーモンを誰も、特にサーバーとして実行しないのが一般的です。ただし、このように複数のデーモンを実行すると、この手法の有用性が低下します。1つのデーモンの制御を取得すると、すべてのデーモンが制御されるためです。その理由は、誰もが所有するプロセスには、互いにシグナルを送信したり、お互いをデバッグしたりする能力がなく、互いのメモリを読み取ったり、修正したりすることさえできないためです。

http://en.wikipedia.org/wiki/Nobody_(username）から取得した情報。

ユーザーnobodyはNFS専用です。

上記の回答nobodyは、「一般的な」匿名/ゲストスタイルのユーザーID であると想定しているため、かなり間違っています。

UNIX / Linuxアクセス制御モデルでは、匿名/ゲストスタイルのユーザーIDは存在せず、これらは悪い提案です。

• 「デーモンをnobody、特にサーバーとして実行するのが一般的で、悪意のあるユーザーがそれらを制御できた場合の被害を制限するために。」次の理由により：「しかし、この手法の有用性は、 1つのデーモンがこのように実行されます。1つのデーモンの制御を取得すると、すべてのデーモンを制御できるようになるためです。
• 「これの実世界の例はmemcached、キーと値のメモリ内キャッシュ/データベース/もの）であり、私のコンピューターと、そのnobodyアカウントで実行されているサーバーに座っています。なぜでしょうか。ファイルへの書き込みアクセス権を持っていたアカウントは、不必要なリスクになります。」

nobodyユーザーID 65534 のユーザー名は、特定の目的のために作成および予約されており、NFSツリーエクスポートの「マップされていない」ユーザーおよびユーザーIDのプレースホルダーとしてのみ使用する必要があります。

つまり、NFSツリーエクスポート用にユーザー/ IDマッピングが設定されていない限り、エクスポート内のすべてのファイルはが所有してnobodyいるように見えます。この目的は、インポートシステム上のすべてのユーザーがそれらのファイルにアクセスできないようにすることです（「他の」アクセス許可がない限りroot）nobody。

従って、使用することは非常に悪い考えであるnobodyため任意のその目的は、誰にもアクセス可能であってはならないファイルのためのユーザー名/ユーザーIDになることですので、他の目的。

Wikiエントリも非常に間違っています。

UNIX / Linuxのプラクティスでは、個別のアクセス制御ドメインを必要とする「アプリケーション」またはアプリケーション領域ごとに新しいアカウントを作成し、NFSの外部で再利用nobodyすることはありません。

nobodyユーザーは、インストール（Ubuntuのデスクトップ13.04で確認）新鮮にデフォルトで作成されます。

多くの* nixバリアントでnobodyは、ファイルを所有せず、特権nobodyグループも持たず、他のすべてのユーザーが持つもの以外の機能を持たないユーザーアカウントの従来の名前です（ユーザーとグループは/etc/sudoersファイルにエントリを持ちません） 。

デーモンnobodyを制御する悪意のあるユーザーが受ける可能性のある損害を制限するために、デーモンとして、特にサーバーを実行するのが一般的です。ただし、このように複数のデーモンを実行すると、この手法の有用性が低下します。1つのデーモンの制御を取得すると、すべてのデーモンが制御されるためです。その理由は、nobody所有プロセスは相互にシグナルを送信し、相互にデバッグすることもできるため、相互のメモリを読み取ったり、修正することさえできるためです。

_{ソース： ウィキペディア-誰も（ユーザー名）}

nobody出資のプロセスがお互いに信号を送り、さらには誰が所有するプロセスは、他の誰もが所有するプロセスのメモリを読み書きできることを意味し、Linux上でお互いをPTRACEすることができます。

これはnobody、/etc/passwdファイル内のユーザーのサンプルエントリです。

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ログインを拒否します。

_{ソース： LinuxG.net-LinuxおよびUnixの誰もいないユーザー}

誰も特別なユーザーおよびグループアカウントではありません。これは実際のユーザー名（およびグループ名）であり、プロセスやユーザーでさえ使用できるため、文字通りnobodyではありません。たとえば、一部のApache構成には、Webサイトのファイルとディレクトリを所有するユーザー/グループとして誰もいない。問題は、NFSディレクトリやWebサーバーなど、複数のプロセスがnobodyユーザーを使用する場合に発生します。

' の小さな修正' ユーザーnobodyはNFS専用です。'答え。nobodyまた、ユーザーは、この時点でバインドマウントと特権のないコンテナに使用されます。

これは、systemd-nspawn、特に--bindマウントオプションから取得されます。

このオプションを--private-usersと組み合わせて使用​​する場合、結果のマウントポイントはnobodyユーザーが所有することに注意してください。これは、マウントとそのファイルとディレクトリが、コンテナに存在しない関連するホストユーザーとグループによって引き続き所有され、ワイルドカードUID 65534（nobody）の下に表示されるためです。そのようなバインドマウントが作成された場合、-bind-ro =を使用して読み取り専用にすることをお勧めします。

systemd-nspawn