What is the purpose of the 'nobody' user?

It's there to run things that don't need any special permissions. It's usually reserved for vulnerable services (httpd, etc) so that if they get hacked, they'll have minimal damage on the rest of the system.

Contrast this with running something as a real user, if that service were compromised (web servers are occasionally exploited to run arbitrary code), it would run as that user and have access to everything that user had. In most cases, this is as bad as getting root.

You can read a little bit more about the nobody user on the Ubuntu Wiki:

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

To answer your follow-ups:

Why I can't access this account with su nobody?

sudo grep nobody /etc/shadow will show you that nobody doesn't have a password and you can't su without an account password. The cleanest way is to sudo su nobody instead. That'll leave you in a pretty desolate sh shell.

Can you give a particular example when is indicated to use this account?

When permissions aren't required for a program's operations. This is most notable when there isn't ever going to be any disk activity.

A real world example of this is memcached (a key-value in-memory cache/database/thing), sitting on my computer and my server running under the nobody account. Why? Because it just doesn't need any permissions and to give it an account that did have write access to files would just be a needless risk.

The user nobody is reserved for NFS only.

The anwers above are rather wrong, because they assume that nobody is a "generic" anonymous/guest style user id.

In the UNIX/Linux access control model anonymous/guest style user ids don't exist and these are bad suggestions:

• "common to run daemons as nobody, especially servers, in order to limit the damage that could be done by a malicious user who gained control of them." because of the that follows: "However, the usefulness of this technique is reduced if more than one daemon is run like this, because then gaining control of one daemon would provide control of them all".
• "A real world example of this is memcached (a key-value in-memory cache/database/thing), sitting on my computer and my server running under the nobody account. Why? Because it just doesn't need any permissions and to give it an account that did have write access to files would just be a needless risk."

The nobody user name with user id 65534 was created and reserved for a specific purpose and should be used only for that purpose: as a placeholder for "unmapped" users and user ids in NFS tree exports.

That is, unless user/id mapping is setup for NFS tree exports, all files in the export will appear owned by nobody. The purpose of this is to prevent all users on the importing system from accessing those files (unless they have "other" permissions), as none of them (except root) can be/become nobody.

Therefore it is a very bad idea to use nobody for any other purpose, because its purpose is to be a user name/user id for files that must not be accessible to anybody.

The Wiki entry is very wrong too.

The UNIX/Linux practice is to create a new account for each "application" or application area that needs a separate access control domain, and to never reuse nobody outside NFS.

In many Unix variants, "nobody" is the conventional name of a user account which owns no files, is in no privileged groups, and has no abilities except those which every other user has.

It is common to run daemons as nobody, especially servers, in order to limit the damage that could be done by a malicious user who gained control of them. However, the usefulness of this technique is reduced if more than one daemon is run like this, because then gaining control of one daemon would provide control of them all. The reason is that nobody-owned processes have the ability to send signals to each other and even debug each other, allowing them to read or even modify each other's memory.

Information taken from http://en.wikipedia.org/wiki/Nobody_(username).

The nobody user is created by default on a fresh install (checked on Ubuntu Desktop 13.04).

In many *nix variants, nobody is the conventional name of a user account which owns no files, is in no privileged groups, and has no abilities except those which every other user has (the nobody user and group do not have any entry in the /etc/sudoers file).

It is common to run daemons as nobody, especially servers, in order to limit the damage that could be done by a malicious user who gained control of them. However, the usefulness of this technique is reduced if more than one daemon is run like this, because then gaining control of one daemon would provide control of them all. The reason is that nobody-owned processes have the ability to send signals to each other and even debug each other, allowing them to read or even modify each other's memory.

_{Source: Wikipedia - Nobody (username)}

The nobody-owned processes are able to send signals to each others and even ptrace each other in Linux, meaning that a nobody-owned process can read and write the memory of another nobody-owned process.

This is a sample entry of the nobody user in the /etc/passwd file:

alaa@aa-lu:~$ grep nobody /etc/passwd
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh

As you may notice, the nobody user has /bin/sh as a login shell and /nonexistent as the home directory. As the name suggests, the /nonexistent directory does not exist, by default.

If you are paranoid, you can set nobody’s default shell as /usr/sbin/nologin and so, deny the ssh login for the nobody user.

_{Source: LinuxG.net - The Linux and Unix Nobody User}

nobody is a special user and group account. Because it is an actual username (and groupname) and can be used by processes and even users, it is not literally nobody. For example, some Apache configurations have nobody as the user/group that owns the website files and directories. The problem comes when multiple processes might use the nobody user, such as NFS directories and the webserver.

Minor correction to the 'The user nobody is reserved for NFS only.' answer. The nobody user is also used for unprivileged containers with bind mounts at this time.

This is taken from systemd-nspawn, specifically the --bind mount option:

Note that when this option is used in combination with --private-users, the resulting mount points will be owned by the nobody user. That's because the mount and its files and directories continue to be owned by the relevant host users and groups, which do not exist in the container, and thus show up under the wildcard UID 65534 (nobody). If such bind mounts are created, it is recommended to make them read-only, using --bind-ro=.

systemd-nspawn