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.
/etc/passwd
(if this is possible) – RSFalcon7 May 05 '13 at 23:39/etc/passwd
. What problem are you trying to solve? – Gilles 'SO- stop being evil' May 05 '13 at 23:54/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 05 '13 at 23:54/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 'SO- stop being evil' May 06 '13 at 19:13