A typical Linux system has not only accounts for the actual user(s) of the system, but also various system accounts.

Is there any file like /etc/passwd for daemons, or other means resources where an account might be defined?

I heard that it is possible to camouflage a account as a service account, I'm trying to find accounts like these in a computer.

  • I'm a little confused by the question. If you're asking how to tell if an account is a service account, most distros put their UID below the 500 mark and set their default shell to something bogus. – Bratchley May 5 '13 at 23:33
  • I want to list all service accounts even those not listed in /etc/passwd (if this is possible) – RSFalcon7 May 5 '13 at 23:39
  • 2
    @RSFalcon7 The service accounts are listed in /etc/passwd. What problem are you trying to solve? – Gilles May 5 '13 at 23:54
  • 2
    /etc/passwd is going to house 100% of all local accounts on the system (which is how your distro would have to create the service account). Since all service accounts are going to be in /etc/passwd it's just a matter of filtering out the local accounts that are for real people (usually either the root user or an account with a UID above 500, but GECOS can also help you determine). – Bratchley May 5 '13 at 23:54
  • 1
    @RSFalcon7 The downvote is probably due to 1. your weird statement passed as a “well-known fact”, 2. the misconception embodied in the question (the “file like /etc/passwd” is /etc/passwd, and since looking at /etc/passwd is how you'd find about these system users, it's hard to understand where this remark comes from); 3. your asking a weird question devoid of context, instead of stating your actual goal (which does make sense, unlike the original question). – Gilles May 6 '13 at 19:13

Daemon users and flesh-and-blood users are listed in the same files. The “file like /etc/passwd for daemons” is /etc/passwd.

There is no formal definition of human vs system users. The kernel doesn't care (other than granting a lot of privileges to the user with UID 0). Most administration commands don't care either. Some typical differences are:

  • A human user has a real name like “John Doe”, whereas a system user has a descriptive name like “Nasal daemon” or none at all.
  • A human user has a real login shell (e.g. /bin/sh or /bin/bash or /bin/csh. Some system users have a shell (almost always /bin/sh), others don't, depending on how they are meant to be used (e.g. su foo requires foo to have a shell).
  • A human user often has a password — but that's not always the case, for example a remote-only user might only have an SSH key. Note that on modern unices, the password is not in /etc/passwd but in some other file such as /etc/shadow.
  • A human user's home directory is usually under /home (or some site-specific location), whereas a system user's home directory is usually not under /home and might not exist (but there are exceptions).
  • Most sites designate a range of user IDs for system users and a disjoint range for human users. Reserving 100–65533 or 500–65533 or 1000–65533 is typical, and most distributions are set up to start allocating real user IDs from 500 or 1000.

On sites where accounts are shared across multiple machines, there is typically a central server that contains user lists, accessible via NIS or LDAP. The passwd entry in /etc/nsswitch.conf specifies where to find user information. It is common to have system users in the local /etc/passwd and real users from the network-wide database, but sometimes there are system users in the network-wide database (to enforce consistent UIDs, which facilitates server and data replication), and sometimes there are human users in the local file (to let them log in even when the network is hosed).

A human-accessible account disguised as a system user would typically not have a real name, but have a login shell, and either a password set or an SSH key, while having a user ID in the system range. In fact, it would be a better disguise to use an actual system account whose removal would cause some service to stop working. But you cannot have any hard-and-fast rules to detect potential attacks: by definition, attackers don't follow rules.

  • If I got you right it is possible to have users that are not listed in the /etc/passwd if the /etc/nsswitch.conf file is configured to get the passwd information in more places that files? In my file I have this valid options nisplus or nis+, nis or yp, dns, files, db, compat, hesiod and the special [NOTFOUND=return] – RSFalcon7 May 6 '13 at 21:40
  • 1
    @RSFalcon7 Yes, you can have users not listed in /etc/passwd if there are other databases (something other than compat or files mentioned for passwd in /etc/nsswitch.conf). – Gilles May 6 '13 at 21:46

There is no reason to have a seperate user definition file. System users and real users are not technically seperated but organizationally: by the range from which their UIDs are taken. have a look at the file /etc/login.defs. My openSUSE has these entries:

SYSTEM_UID_MIN            100
SYSTEM_UID_MAX            499
UID_MIN                  1000
UID_MAX                 60000

The distro tools use these values to tell the two groups apart. But if you created a user account with UID 300 then it would probably not be shown in a login menu but you could use that account like any other.

  • I know there is no reason to split them, but is it possible? – RSFalcon7 May 5 '13 at 23:52
  • 1
    The only other source of user information would be some sort of network authentication service but nobody is going to put a service account there. – Bratchley May 5 '13 at 23:56
  • 1
    @RSFalcon7 Have a look at /etc/nsswitch.conf. You would need to write a new mechanism (i.e. extend the glibc functions for user handling). That may be rather easy as you maybe would just have to copy the files mechanism and replace the paths. But why should anyone do that? – Hauke Laging May 6 '13 at 0:00

If you really want to split user and system accounts (reading some of the comments on other posts, it looks like you are curious about this), you could leave all system users in the files (i.e. /etc/passwd) database and put people users in a second database (kinda like if you were doing ldap).

For this, you can use the Berkeley DB NSS module (available on many systems through an extra glibc package called nss_db). I'm not sure what OS you're using, but this site offers some insight for Linux: http://www.linuxfromscratch.org/hints/downloads/files/nss_db.txt

This is not for the faint of heart as documentation isn't exactly plentiful, but it might be fun to play around with if you're looking to learn more about how this kind of stuff works (@Hauke Laging's suggestion about implementing your own is great as well).


Most daemons run as root, a few (for security reasons, to limit their capacity for harm) run as their own users. They are listed in the /etc/passwd file. Most distributions limit the "system user's" UID to some value, like 500 or 1000, so that gives a clue. Some deamons have GECOS (user description) entries saying "daemon", others have strange shells. But there are also phantom users for NFS and other uses.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.