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).
The
users
command you used, according to
its man page, shows only the users that are
currently logged in. Since the syslog user is a
system user, it will never log in, so it will never show up in this list. You can look into the file
/etc/passwd
or use any of the other methods described
here to get a list of
all (human and system) users on your system.
/etc/passwd
sometime. I count 36 role users, excluding root. Also, tryman users
--you're assuming (incorrectly) what the command does.