134

After I read List all human users I noticed that there is a user account named 'nobody' in my Ubuntu system.

Also I noticed that I can login in this account from terminal using the following command and my password:

sudo su nobody

su nobody

It doesn't mind me at all, but I want to know what is the purpose of this user? Is it created by default on a fresh install of Ubuntu or is created by installing a particular package?

Community
  • 1
Radu Rădeanu
  • 169,590
  • 11
    Note that when you log in using your password, you're using your password for the sudo step, not for the nobody account (and that the reason it works is because the superuser can su to anyone without needing to enter their password (although as mentioned below, I believe at least on RH-derivatives, if nobody's shell is set to /sbin/nologin, you still wouldn't be able to log in even using superuser (aka root) – Foon Aug 08 '13 at 14:48
  • 2
    That's the case by default now (18.04+?). sudo su nobody return This account is currently not available. because the shell for the user nobody is set to /usr/sbin/nologin (getent passwd nobody). – Pablo Bianchi Jan 06 '19 at 19:00
  • @sarnold - please see my comment on the answer I believe you're alluding at. It's a rather poor answer, as it doesn't reason or cite sources. It furthermore goes counter to all I know about the nobody account and how NFS works: with root_squash on it will map root to nobody on remote systems. This is more or less exactly the opposite of what this answer states – vidarlo May 13 '19 at 19:12
  • Posting images of text causes severe accessibility problems. Especially for blind people. But also to others. – ctrl-alt-delor Mar 07 '22 at 19:30
  • I just had a use case for this user: On a web interface that is controlling a program on my computer, I can specify a command line that is used to process some data (typically grep, sed...). I don't want this feature to be a too large security risk (e.g. specify rm * as "text processing" command)... Running grep or sed as user "nobody" eliminates this risk. – Martin Rosenau Sep 01 '23 at 10:49

6 Answers6

104

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:

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.

Community
  • 1
Oli
  • 293,335
  • Just two more things if you can explain: 1) why I can't access this account with su nobody and 2) can you give a particular example when is indicated to use this account? – Radu Rădeanu Aug 07 '13 at 19:34
  • @RaduRădeanu 1) I'm guessing that's because it doesn't have a password set, and when you su as an ordinary user, you must give the target user's password. Try sudo -i then su nobody from the root shell (which won't require a password). – user Aug 07 '13 at 20:40
  • 2
    Network File System maps root to nobody so local root cannot access everything like the remote root can. – Sylwester Aug 07 '13 at 21:36
  • @RaduRădeanu I've edited to pull in and answer your questions. – Oli Aug 07 '13 at 22:12
  • @Demizey , @Braiam , @Githlar Have you tested this command: sudo -u nobody -i? – Radu Rădeanu Mar 29 '14 at 06:48
  • Ah, crap, it works on some systems, but it's nonstandard. The old one wont work either, the -i needs to be replaced with a shell. – remmy Mar 29 '14 at 10:43
  • @Demizey The old one works perfect. See the OP's picture. – Radu Rădeanu Mar 29 '14 at 12:28
  • @RaduRădeanu Doesn't work for me and for a lot of other people because normally nobody doesn't have a default shell. – remmy Mar 29 '14 at 12:57
  • @Demizey In Ubuntu, because about Ubuntu we speak here, nobody user has and always had a default shell - it's /bin/sh, as Oli said in his answer. – Radu Rădeanu Mar 29 '14 at 13:06
  • @Oli Now you contradict yourself in the answer: The cleanest way is to sudo -u nobody /bin/bash instead. That'll leave you in a pretty desolate sh shell. In my opinion, if /bin/bash was used, that'll leave you in a bash shell. Furthermore, when I run sudo -u nobody /bin/bash, this will give me an error bash: /home/radu/.bash_aliases: Permission denied. So, I suppose that is not the cleanest way. – Radu Rădeanu Mar 29 '14 at 13:26
  • 1
    @RaduRădeanu Please note the edit history. When I tested the original command (not what's there) this originally I was ending up in a dash (/bin/sh) shell but I can't replicate that now. Your original edit was fine. It wasn't me who changed it. – Oli Mar 29 '14 at 18:48
  • @Oli But you've accepted it :D Also you can clean all these useless comments if you feel so. – Radu Rădeanu Mar 29 '14 at 18:58
  • IMPORTANT: The user 'nobody' must NEVER own any files, nor have write access to anything. If either find / -user nobody or find / -group nogroup return any files your system is VULNERABLE. – Born2Smile Feb 27 '15 at 14:57
  • @Born2Smile Why? And vulnerable to what? How? – Oli Feb 27 '15 at 18:41
  • @Oli, The whole idea behind 'nobody'-user is to run vulnerable (or potentially vulnerable) processes from it. Thus, when such a process is hacked the hacker will gain access to the system as 'nobody'. If at that point 'nobody' owns any files or folders the hacker will be allowed to edit those files and folders, thus compromising any systems relying on those files. A scary example of this is npm (node.js package manager). npm will by default install all files as 'nobody', thus someone who gains access as 'nobody' to your machine will have full "admin" rights to all of your node.js-server setup. – Born2Smile Mar 06 '15 at 00:34
  • @Born2Smile I don't disagree. You've just rephrased the opening paragraph of this answer... But the account owning files doesn't mean the system is vulnerable, it means that if a service running as nobody is hacked, those files are vulnerable. That's a very big difference. – Oli Mar 06 '15 at 00:55
  • @Oli, indeed you mentioned something to this effect in your first paragraph, however IME few people realise that the increased security of processes doesn't apply to files owned by 'nobody'. Having files or folders owned by 'nobody' makes your system less secure, not more. Also you needn't be hacked, say you have an anonymous ftp-server on your machine (intended for people to download stuff from you) this would run as 'nobody' specifically to prevent people from getting too much access, however if any folders are owned by 'nobody', anyone would also be allowed to upload to those folders. – Born2Smile Mar 06 '15 at 01:13
  • 1
    I always thought nobody is actually/primarily used by NFS as linuxstandardbase states. – dgonzalez May 14 '19 at 11:38
  • -1: nobody is strictly for NFS and should not be used by other services and certainly not by system administrators. Thanks. – sarnold May 15 '19 at 01:25
  • 4
    Ubuntu man claims: Some misguided programs or guides suggest that this user should be used for untrusted program execution or handling untrusted data. This is bad advice. On QNAP NAS, uid 65534 is user Guest and there is no nobody (there also in no root, but "admin"). Files belonging to guest are shown as belonging to nobody on QTV and other docker/containers running on that NAS. Files created as guest on Samba will be owned 65534, guest/nobody. Seems to be a bit of a confusion about this uid. – papo Oct 23 '20 at 21:53
55

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 generic Wikipedia entry is very wrong too. Compare it with the Ubuntu Wiki.

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.

Chris
  • 103
PeterG
  • 1,105
  • 7
  • 6
  • 7
    This answer does not cite any sources, and explicitly contradicts several of the other answers, which do cite sources. The current bounty indicates this answer is particularly good, in which case it should cite some sources, or at list have some reasoning. – vidarlo May 13 '19 at 19:05
  • 6
    https://wiki.ubuntu.com/nobody , http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/usernames.html – mook765 May 13 '19 at 19:48
  • 1
    @mook765 That part is fine. The paragraph about NFS however, I do not grok. For instance with root_squash on, root is mapped to the user nobody, so files having owner nobody would make absolutely no sense. In addition the statement that files owned by nobody is meant to be inaccessible to anyone makes little sense, as file permissions are separate from ownership in UNIX. I'm not saying that everything in the answer is wrong, just that elements of it makes little or no sense to me :) – vidarlo May 13 '19 at 20:12
  • 2
    @vidarlo, this answer isn't suggesting that you should set files to be owned by nobody. It's telling you that nobody is for NFS to use when mapping permissions, and that's the most important point to me. How NFS uses nobody is less interesting than the fact that it does use nobody. Thanks. – sarnold May 15 '19 at 01:28
  • @sarnold the answer is still plain wrong in this matter in my opinion. If a user reads the answer and man exports, he may be very confused. – vidarlo May 15 '19 at 03:31
  • Well, at least Solaris (the system from which NFS originated!) was using nobody for multiple purposes, not only for NFS - for example for running web server. – raj Nov 03 '20 at 19:31
30

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).

Radu Rădeanu
  • 169,590
psukys
  • 3,590
18

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

Alaa Ali
  • 31,535
4

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

ykuksenko
  • 141
4

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.

jeffmcneill
  • 255
  • 2
  • 8