Mixing
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?
users log
edited Jan 15 at 11:30
Zanna
50.7k13136241
asked Jan 15 at 9:05
AliceAlice
415110
add a comment |
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?
users log
edited Jan 15 at 11:30
Zanna
50.7k13136241
asked Jan 15 at 9:05
AliceAlice
415110
6
I assure you that there are far more than one user on your system. I know you mean "human user associated with an account and home directory" but the notion of a "user" for all systems is broader than that.
– jdv
Jan 15 at 14:26
Take a look in/etc/passwdsometime. I count 36 role users, excluding root. Also, tryman users--you're assuming (incorrectly) what the command does.
– chrylis
Jan 16 at 9:12
add a comment |
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?
users log
edited Jan 15 at 11:30
Zanna
50.7k13136241
asked Jan 15 at 9:05
AliceAlice
415110
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?
users log
users log
edited Jan 15 at 11:30
Zanna
50.7k13136241
asked Jan 15 at 9:05
AliceAlice
415110
edited Jan 15 at 11:30
Zanna
50.7k13136241
asked Jan 15 at 9:05
AliceAlice
415110
edited Jan 15 at 11:30
Zanna
50.7k13136241
edited Jan 15 at 11:30
Zanna
50.7k13136241
edited Jan 15 at 11:30
Zanna
50.7k13136241
50.7k13136241
asked Jan 15 at 9:05
AliceAlice
415110
asked Jan 15 at 9:05
AliceAlice
415110
asked Jan 15 at 9:05
AliceAlice
415110
415110
6
I assure you that there are far more than one user on your system. I know you mean "human user associated with an account and home directory" but the notion of a "user" for all systems is broader than that.
– jdv
Jan 15 at 14:26
Take a look in/etc/passwdsometime. I count 36 role users, excluding root. Also, tryman users--you're assuming (incorrectly) what the command does.
– chrylis
Jan 16 at 9:12
add a comment |
6
I assure you that there are far more than one user on your system. I know you mean "human user associated with an account and home directory" but the notion of a "user" for all systems is broader than that.
– jdv
Jan 15 at 14:26
Take a look in/etc/passwdsometime. I count 36 role users, excluding root. Also, tryman users--you're assuming (incorrectly) what the command does.
– chrylis
Jan 16 at 9:12
6
6
I assure you that there are far more than one user on your system. I know you mean "human user associated with an account and home directory" but the notion of a "user" for all systems is broader than that.
– jdv
Jan 15 at 14:26
I assure you that there are far more than one user on your system. I know you mean "human user associated with an account and home directory" but the notion of a "user" for all systems is broader than that.
– jdv
Jan 15 at 14:26
Take a look in
/etc/passwd sometime. I count 36 role users, excluding root. Also, try man users--you're assuming (incorrectly) what the command does.– chrylis
Jan 16 at 9:12
Take a look in
/etc/passwd sometime. I count 36 role users, excluding root. Also, try man users--you're assuming (incorrectly) what the command does.– chrylis
Jan 16 at 9:12
add a comment |
3 Answers
3
active
oldest
votes
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 the group.
edited Jan 16 at 8:27
Peter Mortensen
1,03721016
answered Jan 15 at 9:10
RinzwindRinzwind
207k28397528
That number hasn't always been 1000 though. I have worked on systems which had a long enough history that IDs of real users started from 20.
– kasperd
Jan 15 at 11:39
1
I know but Ubuntu always starts at 1000. Redhat for instance starts at 500.
– Rinzwind
Jan 15 at 11:44
Yes, but the users are not necessarily created locally. In my case they were received over NIS, these days it would probably have been LDAP.
– kasperd
Jan 15 at 11:50
Real users starting at 20 would seriously break a Debian-based distro. UIDs 0-99 on Debian based systems are statically allocated by the Debian project to specific uses.
– Peter Green
Jan 15 at 16:24
1
@PaddyLandau /bin/false will exit a login without notifying. nologin should show a message "This account is currently not available." (/etc/nologin.txt holds this notice)
– Rinzwind
Jan 22 at 12:32
|
show 2 more comments
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.answered Jan 15 at 12:20
Hans-JakobHans-Jakob
2712
add a comment |
Because syslog is not a file; it is a daemon used by the system to store system daemon and application messages (debug, error, warn, and info) to files.
Read here for a brief history of syslog.
In other distributions, for example those based on Red Hat Linux, the syslog output for the system is stored in a file called /var/log/messages. It depends on configuration.
As Rinzwind says, for security reasons different components in the operating system run with a specific user, and each user has their own rights. For example, syslog at least has write permission on the /var/log folder.
A system has many services, and there are usually users for each service or for a small group of services. For example, apache get www-data|httpd|apache. Normally these daemon users do not get Bash access to avoid security leaks.
edited Jan 16 at 8:29
Zanna
50.7k13136241
answered Jan 15 at 9:16
AtomiX84AtomiX84
955111
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1109859%2fwhy-is-syslog-a-user%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 the group.
edited Jan 16 at 8:27
Peter Mortensen
1,03721016
answered Jan 15 at 9:10
RinzwindRinzwind
207k28397528
That number hasn't always been 1000 though. I have worked on systems which had a long enough history that IDs of real users started from 20.
– kasperd
Jan 15 at 11:39
1
I know but Ubuntu always starts at 1000. Redhat for instance starts at 500.
– Rinzwind
Jan 15 at 11:44
Yes, but the users are not necessarily created locally. In my case they were received over NIS, these days it would probably have been LDAP.
– kasperd
Jan 15 at 11:50
Real users starting at 20 would seriously break a Debian-based distro. UIDs 0-99 on Debian based systems are statically allocated by the Debian project to specific uses.
– Peter Green
Jan 15 at 16:24
1
@PaddyLandau /bin/false will exit a login without notifying. nologin should show a message "This account is currently not available." (/etc/nologin.txt holds this notice)
– Rinzwind
Jan 22 at 12:32
|
show 2 more comments
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 the group.
edited Jan 16 at 8:27
Peter Mortensen
1,03721016
answered Jan 15 at 9:10
RinzwindRinzwind
207k28397528
That number hasn't always been 1000 though. I have worked on systems which had a long enough history that IDs of real users started from 20.
– kasperd
Jan 15 at 11:39
1
I know but Ubuntu always starts at 1000. Redhat for instance starts at 500.
– Rinzwind
Jan 15 at 11:44
Yes, but the users are not necessarily created locally. In my case they were received over NIS, these days it would probably have been LDAP.
– kasperd
Jan 15 at 11:50
Real users starting at 20 would seriously break a Debian-based distro. UIDs 0-99 on Debian based systems are statically allocated by the Debian project to specific uses.
– Peter Green
Jan 15 at 16:24
1
@PaddyLandau /bin/false will exit a login without notifying. nologin should show a message "This account is currently not available." (/etc/nologin.txt holds this notice)
– Rinzwind
Jan 22 at 12:32
|
show 2 more comments
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 the group.
edited Jan 16 at 8:27
Peter Mortensen
1,03721016
answered Jan 15 at 9:10
RinzwindRinzwind
207k28397528
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 the group.
edited Jan 16 at 8:27
Peter Mortensen
1,03721016
answered Jan 15 at 9:10
RinzwindRinzwind
207k28397528
edited Jan 16 at 8:27
Peter Mortensen
1,03721016
edited Jan 16 at 8:27
Peter Mortensen
1,03721016
edited Jan 16 at 8:27
Peter Mortensen
1,03721016
1,03721016
answered Jan 15 at 9:10
RinzwindRinzwind
207k28397528
answered Jan 15 at 9:10
RinzwindRinzwind
207k28397528
answered Jan 15 at 9:10
RinzwindRinzwind
207k28397528
207k28397528
That number hasn't always been 1000 though. I have worked on systems which had a long enough history that IDs of real users started from 20.
– kasperd
Jan 15 at 11:39
1
I know but Ubuntu always starts at 1000. Redhat for instance starts at 500.
– Rinzwind
Jan 15 at 11:44
Yes, but the users are not necessarily created locally. In my case they were received over NIS, these days it would probably have been LDAP.
– kasperd
Jan 15 at 11:50
Real users starting at 20 would seriously break a Debian-based distro. UIDs 0-99 on Debian based systems are statically allocated by the Debian project to specific uses.
– Peter Green
Jan 15 at 16:24
1
@PaddyLandau /bin/false will exit a login without notifying. nologin should show a message "This account is currently not available." (/etc/nologin.txt holds this notice)
– Rinzwind
Jan 22 at 12:32
|
show 2 more comments
That number hasn't always been 1000 though. I have worked on systems which had a long enough history that IDs of real users started from 20.
– kasperd
Jan 15 at 11:39
1
I know but Ubuntu always starts at 1000. Redhat for instance starts at 500.
– Rinzwind
Jan 15 at 11:44
Yes, but the users are not necessarily created locally. In my case they were received over NIS, these days it would probably have been LDAP.
– kasperd
Jan 15 at 11:50
Real users starting at 20 would seriously break a Debian-based distro. UIDs 0-99 on Debian based systems are statically allocated by the Debian project to specific uses.
– Peter Green
Jan 15 at 16:24
1
@PaddyLandau /bin/false will exit a login without notifying. nologin should show a message "This account is currently not available." (/etc/nologin.txt holds this notice)
– Rinzwind
Jan 22 at 12:32
That number hasn't always been 1000 though. I have worked on systems which had a long enough history that IDs of real users started from 20.
– kasperd
Jan 15 at 11:39
That number hasn't always been 1000 though. I have worked on systems which had a long enough history that IDs of real users started from 20.
– kasperd
Jan 15 at 11:39
1
1
I know but Ubuntu always starts at 1000. Redhat for instance starts at 500.
– Rinzwind
Jan 15 at 11:44
I know but Ubuntu always starts at 1000. Redhat for instance starts at 500.
– Rinzwind
Jan 15 at 11:44
Yes, but the users are not necessarily created locally. In my case they were received over NIS, these days it would probably have been LDAP.
– kasperd
Jan 15 at 11:50
Yes, but the users are not necessarily created locally. In my case they were received over NIS, these days it would probably have been LDAP.
– kasperd
Jan 15 at 11:50
Real users starting at 20 would seriously break a Debian-based distro. UIDs 0-99 on Debian based systems are statically allocated by the Debian project to specific uses.
– Peter Green
Jan 15 at 16:24
Real users starting at 20 would seriously break a Debian-based distro. UIDs 0-99 on Debian based systems are statically allocated by the Debian project to specific uses.
– Peter Green
Jan 15 at 16:24
1
1
@PaddyLandau /bin/false will exit a login without notifying. nologin should show a message "This account is currently not available." (/etc/nologin.txt holds this notice)
– Rinzwind
Jan 22 at 12:32
@PaddyLandau /bin/false will exit a login without notifying. nologin should show a message "This account is currently not available." (/etc/nologin.txt holds this notice)
– Rinzwind
Jan 22 at 12:32
|
show 2 more comments
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.answered Jan 15 at 12:20
Hans-JakobHans-Jakob
2712
add a comment |
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.answered Jan 15 at 12:20
Hans-JakobHans-Jakob
2712
add a comment |
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.answered Jan 15 at 12:20
Hans-JakobHans-Jakob
2712
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.answered Jan 15 at 12:20
Hans-JakobHans-Jakob
2712
answered Jan 15 at 12:20
Hans-JakobHans-Jakob
2712
answered Jan 15 at 12:20
Hans-JakobHans-Jakob
2712
answered Jan 15 at 12:20
Hans-JakobHans-Jakob
2712
2712
add a comment |
add a comment |
Because syslog is not a file; it is a daemon used by the system to store system daemon and application messages (debug, error, warn, and info) to files.
Read here for a brief history of syslog.
In other distributions, for example those based on Red Hat Linux, the syslog output for the system is stored in a file called /var/log/messages. It depends on configuration.
As Rinzwind says, for security reasons different components in the operating system run with a specific user, and each user has their own rights. For example, syslog at least has write permission on the /var/log folder.
A system has many services, and there are usually users for each service or for a small group of services. For example, apache get www-data|httpd|apache. Normally these daemon users do not get Bash access to avoid security leaks.
edited Jan 16 at 8:29
Zanna
50.7k13136241
answered Jan 15 at 9:16
AtomiX84AtomiX84
955111
add a comment |
Because syslog is not a file; it is a daemon used by the system to store system daemon and application messages (debug, error, warn, and info) to files.
Read here for a brief history of syslog.
In other distributions, for example those based on Red Hat Linux, the syslog output for the system is stored in a file called /var/log/messages. It depends on configuration.
As Rinzwind says, for security reasons different components in the operating system run with a specific user, and each user has their own rights. For example, syslog at least has write permission on the /var/log folder.
A system has many services, and there are usually users for each service or for a small group of services. For example, apache get www-data|httpd|apache. Normally these daemon users do not get Bash access to avoid security leaks.
edited Jan 16 at 8:29
Zanna
50.7k13136241
answered Jan 15 at 9:16
AtomiX84AtomiX84
955111
add a comment |
Because syslog is not a file; it is a daemon used by the system to store system daemon and application messages (debug, error, warn, and info) to files.
Read here for a brief history of syslog.
In other distributions, for example those based on Red Hat Linux, the syslog output for the system is stored in a file called /var/log/messages. It depends on configuration.
As Rinzwind says, for security reasons different components in the operating system run with a specific user, and each user has their own rights. For example, syslog at least has write permission on the /var/log folder.
A system has many services, and there are usually users for each service or for a small group of services. For example, apache get www-data|httpd|apache. Normally these daemon users do not get Bash access to avoid security leaks.
edited Jan 16 at 8:29
Zanna
50.7k13136241
answered Jan 15 at 9:16
AtomiX84AtomiX84
955111
Because syslog is not a file; it is a daemon used by the system to store system daemon and application messages (debug, error, warn, and info) to files.
Read here for a brief history of syslog.
In other distributions, for example those based on Red Hat Linux, the syslog output for the system is stored in a file called /var/log/messages. It depends on configuration.
As Rinzwind says, for security reasons different components in the operating system run with a specific user, and each user has their own rights. For example, syslog at least has write permission on the /var/log folder.
A system has many services, and there are usually users for each service or for a small group of services. For example, apache get www-data|httpd|apache. Normally these daemon users do not get Bash access to avoid security leaks.
edited Jan 16 at 8:29
Zanna
50.7k13136241
answered Jan 15 at 9:16
AtomiX84AtomiX84
955111
edited Jan 16 at 8:29
Zanna
50.7k13136241
edited Jan 16 at 8:29
Zanna
50.7k13136241
edited Jan 16 at 8:29
Zanna
50.7k13136241
50.7k13136241
answered Jan 15 at 9:16
AtomiX84AtomiX84
955111
answered Jan 15 at 9:16
AtomiX84AtomiX84
955111
answered Jan 15 at 9:16
AtomiX84AtomiX84
955111
955111
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1109859%2fwhy-is-syslog-a-user%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
6
I assure you that there are far more than one user on your system. I know you mean "human user associated with an account and home directory" but the notion of a "user" for all systems is broader than that.
– jdv
Jan 15 at 14:26
Take a look in
/etc/passwdsometime. I count 36 role users, excluding root. Also, tryman users--you're assuming (incorrectly) what the command does.– chrylis
Jan 16 at 9:12