I would like to know difference between user and service account.
I know that e.g.
Jenkins installed to ubuntu is not a user, but service account.
- What is use of service account?
- When we need them?
- How can I create service account?
User accounts are used by real users, service accounts are used by system services such as web servers, mail transport agents, databases etc. By convention, and only by convention, service accounts have user IDs in the low range, e.g. < 1000 or so. Except for UID 0, service accounts don't have any special privileges. Service accounts may - and typically do - own specific resources, even device special files, but they don't have superuser-like privileges.
Service accounts can be created like ordinary user accounts (e.g. using
useradd). However, service accounts are typically created and configured by the package manager upon installation of the service software. So, even as an administrator you should be rarely directly concerned with the creation of service accounts.
For good reason: In contrast to user accounts, service accounts often don't have a "proper" login shell, i.e. they have
/usr/sbin/nologin as login shell (or, back in the old days,
/bin/false). Moreover, service accounts are typically locked, i.e. it is not possible to login (for traditional
/etc/shadow this can be achieved by setting the password hash to arbitrary values such as
x). This is to harden the service accounts against abuse (defense in depth).
Having individual service accounts for each service serves two main purposes: It is a security measure to reduce the impact in case of an incident with one service (compartmentalization), and it simplifies administration as it becomes easier to track down what resources belong to which service. See this or this answers on related questions for more details.
Originally, users were intended to correspond to a human using the system, hence the name. Each process runs as a particular user, and each file is owned by a particular user. A special user, called root, is used for things that don't belong to any particular human user, i.e. the operating system itself. Since root corresponds to the operating system itself, it has all privileges.
Soon people found that it was convenient to create multiple system users, without extensive privileges. This allows isolating the various services that run on a machine, so that they don't tread on each others' toes. A service account (or “system account”, these two terms are synonyms) is one that corresponds to a service running on the system, rather than to someone using the system. You generally have a service account for each task running on the system that has its own set of privileges (e.g. its own files, its own network ports, etc.).
There is no formal definition of human vs system/service account. 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:
/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.
footo have a shell).
/etc/passwdbut in some other file such as
/home(or some site-specific location), whereas a system user's home directory is usually not under
/homeand might not exist (but there are exceptions).
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.
Service accounts and human accounts are managed by the same commands and recorded in the same files. Account creation commands may have options to set reasonable defaults for human vs service users, e.g. to pick a user ID in the proper range, and to prompt for a password for a human and disable password authentication for a service. For example,
adduser --system or
useradd -r on Linux.
systemdor similar, which run as root, quickly downgrade to the service account to limit the risks. Depending on the OS used, the application accounts might be granted more privileges than regular accounts, e.g. the right to bind to a privileged TCP port, or on the opposite have their privileges reduced compared to a regular user, for example denying the service processes to call
exec. In such case, there is no need to have the services downgrading to the service account, they can be started with it.
/bin/false) and it won't be usable by a regular user, i.e. there will be no way to log in locally or remotely (e.g. thru
ssh) using the account name. Like most limitations, using the root account or
sudoallows to overcome it.
A service account may not have the ability to use a shell for example. It is used to execute services (daemon) with restricted scope and privilege. My opinion is that you can create it as a regular user, just being careful with the rights and group membership. However, most of the time you don't because programs automatically create them during installation .
Take a look in
0 is the UID, it characterize the hierarchy of the account in the user space, root is above everybody, then you have the group membership
:root the home directory
/root finally the shell used by the account
/bin/bash to 'log in' the system.
You can use
/usr/sbin/nologin for an account you don't want login privilege for.