Why is syslog a user?

When I check the /var/log, I find something very strange

me@me:~$ ls -lt /var/log |head -6 '
total 160368
-rw-r-----  1 syslog            adm              19919118 Jan 15 16:55 auth.log
-rw-r-----  1 syslog            adm             139702302 Jan 15 16:55 syslog
-rw-r-----  1 syslog            adm                191122 Jan 15 16:55 mail.log
-rw-r-----  1 syslog            adm               2210432 Jan 15 16:32 kern.log
-rw-r--r--  1 root              root              1741863 Jan 15 14:22 dpkg.log

Notice that the owner of the first four log file is syslog. It's weird, because there is only one user on my system:

me@me~$ users
me

Why could a filename syslog be a user?

It has to do with security and permissions on accessing your system.

And no, you have a lot more users than just your own user. There is "root", "daemon","bin", "games", "nobody", and "list".

Do a more /etc/passwd for a list of users on your system. You will see lots of lines with "/usr/sbin/nologin". That means those can not be used as a normal user with a login like your own user can. The third column is the user ID. All user IDs below 1000 are pseudo users. Your 1st sudo user (the one that installed the system) has 1000 by default.

Basically user syslog is allowed to use the /var/log/ directory that is set as a directory owned by root. To not have to compromise permissions on the directory (i.e., lower the permissions so other users can use it), this user was created.

The same is done with the user for Apache and MySQL (you will see a www-data user and group and a MySQL user and group when you install these), but it is used for loads of things. There is a group "dialout" that is used to access devices to externals. Users get added to this group to allow the user to use these devices. Otherwise you will get a permission denied error. It works two ways: denying a user access means removing that user from the group.

The syslog service, which writes log messages created by the kernel and by other services to various log files, the console, and/or other destinations, runs under its own, special user account. So do many other services. This is to implement the principle of least privilege:

In order to minimize the possible impact of a compromised or faulty service (e.g. a service that has a bug which in turn gets exploited by an attacker, or a service that has a bug that causes is to do random undesired things, or a service that has been deliberately designed by a malignant developer to do bad things), you want each service to have access only to what it needs for its operation and nothing else.

On any unix-like operation system (that includes all GNU/Linux distributions such as Ubuntu), you can most easily assign privilieges (that is mostly the right to read and/or write from/to certain files or file-like things such as device nodes) based on users and groups. There are other possibilities, but they are often more tedious and error-prone to set up, or work only in specific contexts.

So, the syslog service runs under the syslog user account. If now, for example, an attacker can get the syslog service to do what they tell it to instead of what it is supposed to, the syslog service is still restricted (enforced by the kernel based on the user account, not enforced by the syslog software itself, which would be useless because it is compromised) to write only to the log files (the only files to which the syslog user has write access). Thus, the attacker can not use the compromised syslog service to e.g. change the contents of a website or database hosted on the same computer, because the relevant files are set up to be writable only by some particular set of other (human or system) user accounts, not by the syslog user account.

In order to cause more harm than just deleting/modifying the log files and reading "public" files (with "read" permission for everyone), the attacker would first need to additionally exploit a second bug, either in the kernel or in some software that is installed to run with different privileges than the user that invoked it (setuid), and thus gain additional privileges (privilege escalation).