Daemon users and flesh-and-blood users are listed in the same files. The “file like
/etc/passwd for daemons” is
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/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
- 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.