What is the bin user for?
up vote
23
down vote
favorite
As I wrote at https://unix.stackexchange.com/a/484626/5132 this is worthy of its own Q&A.
On Linux operating systems …
% getent passwd bin… and on FreeBSD …
bin:x:2:2:bin:/bin:/usr/sbin/nologin
%
% getent passwd bin… and on OpenBSD …
bin:*:3:7:Binaries Commands and Source:/:/usr/sbin/nologin
%
$ getent passwd bin… one can still today find a
bin:*:3:7:Binaries Commands and Source:/:/sbin/nologin
$
bin account. But it is pretty much undocumented. The Linux Standard Base version 5 says merely … Notes: The… without explaining the nature of the compatibility mechanism. As Joey Hess put it back in 2001:binUser ID/Group ID is included for compatibility with legacy applications. New applications should no longer use thebinUser ID/Group ID.
bin:No files on my system are owned by user or groupbin. What good are they? Historically they were probably the owners of binaries in/bin? It is not mentioned in the FHS, Debian policy, or the changelog of base-passwd or base-files.
M. Hess's question remains unanswered in the Debian doco for its base-passwd package to this day, 17 years later.
So what is the bin account for?
passwd non-root-user
edited Dec 4 at 22:32
Rui F Ribeiro
38.6k1479128
asked Dec 2 at 15:34
JdeBP
32.7k468154
add a comment |
up vote
23
down vote
favorite
As I wrote at https://unix.stackexchange.com/a/484626/5132 this is worthy of its own Q&A.
On Linux operating systems …
% getent passwd bin… and on FreeBSD …
bin:x:2:2:bin:/bin:/usr/sbin/nologin
%
% getent passwd bin… and on OpenBSD …
bin:*:3:7:Binaries Commands and Source:/:/usr/sbin/nologin
%
$ getent passwd bin… one can still today find a
bin:*:3:7:Binaries Commands and Source:/:/sbin/nologin
$
bin account. But it is pretty much undocumented. The Linux Standard Base version 5 says merely … Notes: The… without explaining the nature of the compatibility mechanism. As Joey Hess put it back in 2001:binUser ID/Group ID is included for compatibility with legacy applications. New applications should no longer use thebinUser ID/Group ID.
bin:No files on my system are owned by user or groupbin. What good are they? Historically they were probably the owners of binaries in/bin? It is not mentioned in the FHS, Debian policy, or the changelog of base-passwd or base-files.
M. Hess's question remains unanswered in the Debian doco for its base-passwd package to this day, 17 years later.
So what is the bin account for?
passwd non-root-user
edited Dec 4 at 22:32
Rui F Ribeiro
38.6k1479128
asked Dec 2 at 15:34
JdeBP
32.7k468154
A related question is unix.stackexchange.com/questions/244989 .
– JdeBP
Dec 5 at 19:33
add a comment |
up vote
23
down vote
favorite
up vote
23
down vote
favorite
As I wrote at https://unix.stackexchange.com/a/484626/5132 this is worthy of its own Q&A.
On Linux operating systems …
% getent passwd bin… and on FreeBSD …
bin:x:2:2:bin:/bin:/usr/sbin/nologin
%
% getent passwd bin… and on OpenBSD …
bin:*:3:7:Binaries Commands and Source:/:/usr/sbin/nologin
%
$ getent passwd bin… one can still today find a
bin:*:3:7:Binaries Commands and Source:/:/sbin/nologin
$
bin account. But it is pretty much undocumented. The Linux Standard Base version 5 says merely … Notes: The… without explaining the nature of the compatibility mechanism. As Joey Hess put it back in 2001:binUser ID/Group ID is included for compatibility with legacy applications. New applications should no longer use thebinUser ID/Group ID.
bin:No files on my system are owned by user or groupbin. What good are they? Historically they were probably the owners of binaries in/bin? It is not mentioned in the FHS, Debian policy, or the changelog of base-passwd or base-files.
M. Hess's question remains unanswered in the Debian doco for its base-passwd package to this day, 17 years later.
So what is the bin account for?
passwd non-root-user
edited Dec 4 at 22:32
Rui F Ribeiro
38.6k1479128
asked Dec 2 at 15:34
JdeBP
32.7k468154
As I wrote at https://unix.stackexchange.com/a/484626/5132 this is worthy of its own Q&A.
On Linux operating systems …
% getent passwd bin… and on FreeBSD …
bin:x:2:2:bin:/bin:/usr/sbin/nologin
%
% getent passwd bin… and on OpenBSD …
bin:*:3:7:Binaries Commands and Source:/:/usr/sbin/nologin
%
$ getent passwd bin… one can still today find a
bin:*:3:7:Binaries Commands and Source:/:/sbin/nologin
$
bin account. But it is pretty much undocumented. The Linux Standard Base version 5 says merely … Notes: The… without explaining the nature of the compatibility mechanism. As Joey Hess put it back in 2001:binUser ID/Group ID is included for compatibility with legacy applications. New applications should no longer use thebinUser ID/Group ID.
bin:No files on my system are owned by user or groupbin. What good are they? Historically they were probably the owners of binaries in/bin? It is not mentioned in the FHS, Debian policy, or the changelog of base-passwd or base-files.
M. Hess's question remains unanswered in the Debian doco for its base-passwd package to this day, 17 years later.
So what is the bin account for?
passwd non-root-user
passwd non-root-user
edited Dec 4 at 22:32
Rui F Ribeiro
38.6k1479128
asked Dec 2 at 15:34
JdeBP
32.7k468154
edited Dec 4 at 22:32
Rui F Ribeiro
38.6k1479128
asked Dec 2 at 15:34
JdeBP
32.7k468154
edited Dec 4 at 22:32
Rui F Ribeiro
38.6k1479128
edited Dec 4 at 22:32
Rui F Ribeiro
38.6k1479128
edited Dec 4 at 22:32
Rui F Ribeiro
38.6k1479128
38.6k1479128
asked Dec 2 at 15:34
JdeBP
32.7k468154
asked Dec 2 at 15:34
JdeBP
32.7k468154
asked Dec 2 at 15:34
JdeBP
32.7k468154
32.7k468154
A related question is unix.stackexchange.com/questions/244989 .
– JdeBP
Dec 5 at 19:33
add a comment |
A related question is unix.stackexchange.com/questions/244989 .
– JdeBP
Dec 5 at 19:33
A related question is unix.stackexchange.com/questions/244989 .
– JdeBP
Dec 5 at 19:33
A related question is unix.stackexchange.com/questions/244989 .
– JdeBP
Dec 5 at 19:33
add a comment |
2 Answers
2
active
oldest
votes
up vote
31
down vote
bin has not properly been for anything for the entire lifetime of Linux.
Like run-levels and init spawning getty because of records in /etc/inittab, the bin account was obsolete in the Unix world before Linux was even invented. It was an idea from the 1980s that was broken by the invention and adoption of NFS (Network File System) and its nobody user. Its continued presence in user account databases in the late 2010s when people in the commercial Unix world actively discontinued its use in the 1990s is a testament to inertia.
The idea was that the bin user owned various directories such as /bin and /usr/bin (and indeed some of the others mentioned at https://unix.stackexchange.com/a/448799/5132 such as /usr/mbin and /usr/5bin) and the non-set-UID/non-set-GID files within them. It also owned doco files and directories, such as manual pages.
(In more extreme cases on some Unices it even owned / and /etc, although the latter was an acknowledged mistake in the creation of a SunOS operating system image. The former was just dunderheaded.)
Thus the permission to enact software updates, running as user bin, was not a blanket permission, running as the superuser, to perform any action whatsoever against the system. The software upgrader could not read/write private user files, access mailboxes, and so forth; which updating softwares as the superuser of course could.
Several other special account entries in your— Rebecca Thomas and Rik Farrow (1989). UNIX Administration Guide for System V. Prentice Hall. ISBN 9780139428890. p. 452./etc/passwdfile must have passwords. These are the administrative accounts —bin,daemon,sys,uucp,lp, andadm. […] The primary reason for the existence of these accounts is the secure ownership of commands, scripts, files, and devices. And some administrators install passwords for these accounts and actually use them. […] A password-freebinaccount is extremely useful for a system breaker.
NFS was invented in the early 1980s, and broke this idea completely.
It was already on shaky ground, as the aforegiven quotation alludes. This was because the ability to update the program image files for basic utilities that the superuser executed as a matter of course, such as /bin/ls for example, is a direct vector for gaining superuser privileges, and the division of access in using a bin account merely prevented accidentally modifying the wrong directories rather than prevented a malefactor from gaining superuser access.
The advent of NFS highlighted this. Although NFS had a mechanism for remapping the superuser account to an ordinary non-system user account, it did not have the same for non-root-accounts like bin. So if someone could gain bin access on an NFS client it gave them bin access to the operating system files on an NFS server. Indeed, it enabled a superuser on an NFS client, who would otherwise be remapped to an ordinary non-system user on the server, to gain owner access to the server's operating system files and directories.
This was common knowledge by the early 1990s, and at that time received wisdom was to chown stuff that was owned by bin to being owned by the superuser, to plug this hole that had already become a standard reporting item in Unix security auditing tools and was warned against in the likes of the installation doco for Sendmail.
As far as M. Hess's questions are concerned, this idea was never adopted on Debian, which only came into existence years after it was known to be a bad idea in the Unix world, which indeed knew it to be a bad idea before Linux itself was invented. The BSD operating systems whose history does stretch back into the 1980s have long since done away with the actual ownership, but nonetheless retain the user account in the account database. FreeBSD converted bin:bin ownership to root:wheel ownership back in 1998, for example.
Further reading
- Jonathan de Boyne Pollard (2015).
/etc/inittabis a thing of the past.. Frequently Given Answers. - Jonathan de Boyne Pollard (2018). run-levels are things of the past.. Frequently Given Answers.
- Jonathan de Boyne Pollard (2018). Don't abuse nobody for running dæmons.. Frequently Given Answers.
- Thomas Benjamin (1995-11-07). Tiger flags *bin* owned system files, disabled accounts. comp.sys.hp.hpux.
- Bob Proulx (2002-09-15). Re: question about /etc/passwd entries. linux.debian.user.
- Doug Siebert (1999-06-22). Re: OS files owned by bin not root. comp.security.unix.
- Doug Siebert (1998-06-01). Re: AIX : "/" is owned by bin.bin. umn.local-lists.security.
- Theo de Raadt (1999-06-22). Re: OS files owned by bin not root. comp.security.unix.
- gene (1994-09-08). Why should bin not own a directory. comp.security.unix.
- Brad Powell (1993-08-12). Re: Root directory 'bin bin'?. comp.security.unix.
- Mario Wolczko (1991-09-13). Re: What breaks if /etc is not owned by bin?. alt.security.
edited Dec 4 at 4:38
Isaac
11k11648
answered Dec 2 at 15:34
JdeBP
32.7k468154
1
I have seen files today owned by thebinuser and group on AIX systems. It’s possible that IBM uses it for a reason. One AIX fileset that comes to mind isjava. I will have to hop on the AIX systems at work to verify further.
– Peschke
Dec 2 at 18:25
There are still a substantial number of bin:bin-owned files on an AIX system today. The IBM Knowledge Center for AIX 7.2, in the Security - Securing the base operating system - Users, groups, and passwords section has the linked page explaining the purpose of the various "System special user accounts", includingbin.
– Jeff Schaller
Dec 3 at 17:17
From the previous link,binis not one of the common default user IDs that you might be able to remove. Also:bin's password entry is:bin:!:2:2::/bin:
– Jeff Schaller
Dec 3 at 17:17
add a comment |
up vote
-8
down vote
There are 2 case uses that I use bin for 2018. 1: executable's - mainly for web server side .exe files used to complete functions. And 2: logs - sometimes I put my .log or .dat files in my bin folder. Hope this answer helps you out in the long run.
answered Dec 3 at 0:33
jehovahsays
983
2
Are you talking about the/bindirectory? Or the bin user?
– Sparhawk
Dec 3 at 2:14
6
Are you even on any sort of Unix? You're talking about.exefiles.
– user62251
Dec 3 at 3:24
4
And why would you put logfiles or configuration files in a "bin" directory?
– Lightness Races in Orbit
Dec 3 at 12:44
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
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',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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%2funix.stackexchange.com%2fquestions%2f485505%2fwhat-is-the-bin-user-for%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
31
down vote
bin has not properly been for anything for the entire lifetime of Linux.
Like run-levels and init spawning getty because of records in /etc/inittab, the bin account was obsolete in the Unix world before Linux was even invented. It was an idea from the 1980s that was broken by the invention and adoption of NFS (Network File System) and its nobody user. Its continued presence in user account databases in the late 2010s when people in the commercial Unix world actively discontinued its use in the 1990s is a testament to inertia.
The idea was that the bin user owned various directories such as /bin and /usr/bin (and indeed some of the others mentioned at https://unix.stackexchange.com/a/448799/5132 such as /usr/mbin and /usr/5bin) and the non-set-UID/non-set-GID files within them. It also owned doco files and directories, such as manual pages.
(In more extreme cases on some Unices it even owned / and /etc, although the latter was an acknowledged mistake in the creation of a SunOS operating system image. The former was just dunderheaded.)
Thus the permission to enact software updates, running as user bin, was not a blanket permission, running as the superuser, to perform any action whatsoever against the system. The software upgrader could not read/write private user files, access mailboxes, and so forth; which updating softwares as the superuser of course could.
Several other special account entries in your— Rebecca Thomas and Rik Farrow (1989). UNIX Administration Guide for System V. Prentice Hall. ISBN 9780139428890. p. 452./etc/passwdfile must have passwords. These are the administrative accounts —bin,daemon,sys,uucp,lp, andadm. […] The primary reason for the existence of these accounts is the secure ownership of commands, scripts, files, and devices. And some administrators install passwords for these accounts and actually use them. […] A password-freebinaccount is extremely useful for a system breaker.
NFS was invented in the early 1980s, and broke this idea completely.
It was already on shaky ground, as the aforegiven quotation alludes. This was because the ability to update the program image files for basic utilities that the superuser executed as a matter of course, such as /bin/ls for example, is a direct vector for gaining superuser privileges, and the division of access in using a bin account merely prevented accidentally modifying the wrong directories rather than prevented a malefactor from gaining superuser access.
The advent of NFS highlighted this. Although NFS had a mechanism for remapping the superuser account to an ordinary non-system user account, it did not have the same for non-root-accounts like bin. So if someone could gain bin access on an NFS client it gave them bin access to the operating system files on an NFS server. Indeed, it enabled a superuser on an NFS client, who would otherwise be remapped to an ordinary non-system user on the server, to gain owner access to the server's operating system files and directories.
This was common knowledge by the early 1990s, and at that time received wisdom was to chown stuff that was owned by bin to being owned by the superuser, to plug this hole that had already become a standard reporting item in Unix security auditing tools and was warned against in the likes of the installation doco for Sendmail.
As far as M. Hess's questions are concerned, this idea was never adopted on Debian, which only came into existence years after it was known to be a bad idea in the Unix world, which indeed knew it to be a bad idea before Linux itself was invented. The BSD operating systems whose history does stretch back into the 1980s have long since done away with the actual ownership, but nonetheless retain the user account in the account database. FreeBSD converted bin:bin ownership to root:wheel ownership back in 1998, for example.
Further reading
- Jonathan de Boyne Pollard (2015).
/etc/inittabis a thing of the past.. Frequently Given Answers. - Jonathan de Boyne Pollard (2018). run-levels are things of the past.. Frequently Given Answers.
- Jonathan de Boyne Pollard (2018). Don't abuse nobody for running dæmons.. Frequently Given Answers.
- Thomas Benjamin (1995-11-07). Tiger flags *bin* owned system files, disabled accounts. comp.sys.hp.hpux.
- Bob Proulx (2002-09-15). Re: question about /etc/passwd entries. linux.debian.user.
- Doug Siebert (1999-06-22). Re: OS files owned by bin not root. comp.security.unix.
- Doug Siebert (1998-06-01). Re: AIX : "/" is owned by bin.bin. umn.local-lists.security.
- Theo de Raadt (1999-06-22). Re: OS files owned by bin not root. comp.security.unix.
- gene (1994-09-08). Why should bin not own a directory. comp.security.unix.
- Brad Powell (1993-08-12). Re: Root directory 'bin bin'?. comp.security.unix.
- Mario Wolczko (1991-09-13). Re: What breaks if /etc is not owned by bin?. alt.security.
edited Dec 4 at 4:38
Isaac
11k11648
answered Dec 2 at 15:34
JdeBP
32.7k468154
1
I have seen files today owned by thebinuser and group on AIX systems. It’s possible that IBM uses it for a reason. One AIX fileset that comes to mind isjava. I will have to hop on the AIX systems at work to verify further.
– Peschke
Dec 2 at 18:25
There are still a substantial number of bin:bin-owned files on an AIX system today. The IBM Knowledge Center for AIX 7.2, in the Security - Securing the base operating system - Users, groups, and passwords section has the linked page explaining the purpose of the various "System special user accounts", includingbin.
– Jeff Schaller
Dec 3 at 17:17
From the previous link,binis not one of the common default user IDs that you might be able to remove. Also:bin's password entry is:bin:!:2:2::/bin:
– Jeff Schaller
Dec 3 at 17:17
add a comment |
up vote
31
down vote
bin has not properly been for anything for the entire lifetime of Linux.
Like run-levels and init spawning getty because of records in /etc/inittab, the bin account was obsolete in the Unix world before Linux was even invented. It was an idea from the 1980s that was broken by the invention and adoption of NFS (Network File System) and its nobody user. Its continued presence in user account databases in the late 2010s when people in the commercial Unix world actively discontinued its use in the 1990s is a testament to inertia.
The idea was that the bin user owned various directories such as /bin and /usr/bin (and indeed some of the others mentioned at https://unix.stackexchange.com/a/448799/5132 such as /usr/mbin and /usr/5bin) and the non-set-UID/non-set-GID files within them. It also owned doco files and directories, such as manual pages.
(In more extreme cases on some Unices it even owned / and /etc, although the latter was an acknowledged mistake in the creation of a SunOS operating system image. The former was just dunderheaded.)
Thus the permission to enact software updates, running as user bin, was not a blanket permission, running as the superuser, to perform any action whatsoever against the system. The software upgrader could not read/write private user files, access mailboxes, and so forth; which updating softwares as the superuser of course could.
Several other special account entries in your— Rebecca Thomas and Rik Farrow (1989). UNIX Administration Guide for System V. Prentice Hall. ISBN 9780139428890. p. 452./etc/passwdfile must have passwords. These are the administrative accounts —bin,daemon,sys,uucp,lp, andadm. […] The primary reason for the existence of these accounts is the secure ownership of commands, scripts, files, and devices. And some administrators install passwords for these accounts and actually use them. […] A password-freebinaccount is extremely useful for a system breaker.
NFS was invented in the early 1980s, and broke this idea completely.
It was already on shaky ground, as the aforegiven quotation alludes. This was because the ability to update the program image files for basic utilities that the superuser executed as a matter of course, such as /bin/ls for example, is a direct vector for gaining superuser privileges, and the division of access in using a bin account merely prevented accidentally modifying the wrong directories rather than prevented a malefactor from gaining superuser access.
The advent of NFS highlighted this. Although NFS had a mechanism for remapping the superuser account to an ordinary non-system user account, it did not have the same for non-root-accounts like bin. So if someone could gain bin access on an NFS client it gave them bin access to the operating system files on an NFS server. Indeed, it enabled a superuser on an NFS client, who would otherwise be remapped to an ordinary non-system user on the server, to gain owner access to the server's operating system files and directories.
This was common knowledge by the early 1990s, and at that time received wisdom was to chown stuff that was owned by bin to being owned by the superuser, to plug this hole that had already become a standard reporting item in Unix security auditing tools and was warned against in the likes of the installation doco for Sendmail.
As far as M. Hess's questions are concerned, this idea was never adopted on Debian, which only came into existence years after it was known to be a bad idea in the Unix world, which indeed knew it to be a bad idea before Linux itself was invented. The BSD operating systems whose history does stretch back into the 1980s have long since done away with the actual ownership, but nonetheless retain the user account in the account database. FreeBSD converted bin:bin ownership to root:wheel ownership back in 1998, for example.
Further reading
- Jonathan de Boyne Pollard (2015).
/etc/inittabis a thing of the past.. Frequently Given Answers. - Jonathan de Boyne Pollard (2018). run-levels are things of the past.. Frequently Given Answers.
- Jonathan de Boyne Pollard (2018). Don't abuse nobody for running dæmons.. Frequently Given Answers.
- Thomas Benjamin (1995-11-07). Tiger flags *bin* owned system files, disabled accounts. comp.sys.hp.hpux.
- Bob Proulx (2002-09-15). Re: question about /etc/passwd entries. linux.debian.user.
- Doug Siebert (1999-06-22). Re: OS files owned by bin not root. comp.security.unix.
- Doug Siebert (1998-06-01). Re: AIX : "/" is owned by bin.bin. umn.local-lists.security.
- Theo de Raadt (1999-06-22). Re: OS files owned by bin not root. comp.security.unix.
- gene (1994-09-08). Why should bin not own a directory. comp.security.unix.
- Brad Powell (1993-08-12). Re: Root directory 'bin bin'?. comp.security.unix.
- Mario Wolczko (1991-09-13). Re: What breaks if /etc is not owned by bin?. alt.security.
edited Dec 4 at 4:38
Isaac
11k11648
answered Dec 2 at 15:34
JdeBP
32.7k468154
1
I have seen files today owned by thebinuser and group on AIX systems. It’s possible that IBM uses it for a reason. One AIX fileset that comes to mind isjava. I will have to hop on the AIX systems at work to verify further.
– Peschke
Dec 2 at 18:25
There are still a substantial number of bin:bin-owned files on an AIX system today. The IBM Knowledge Center for AIX 7.2, in the Security - Securing the base operating system - Users, groups, and passwords section has the linked page explaining the purpose of the various "System special user accounts", includingbin.
– Jeff Schaller
Dec 3 at 17:17
From the previous link,binis not one of the common default user IDs that you might be able to remove. Also:bin's password entry is:bin:!:2:2::/bin:
– Jeff Schaller
Dec 3 at 17:17
add a comment |
up vote
31
down vote
up vote
31
down vote
bin has not properly been for anything for the entire lifetime of Linux.
Like run-levels and init spawning getty because of records in /etc/inittab, the bin account was obsolete in the Unix world before Linux was even invented. It was an idea from the 1980s that was broken by the invention and adoption of NFS (Network File System) and its nobody user. Its continued presence in user account databases in the late 2010s when people in the commercial Unix world actively discontinued its use in the 1990s is a testament to inertia.
The idea was that the bin user owned various directories such as /bin and /usr/bin (and indeed some of the others mentioned at https://unix.stackexchange.com/a/448799/5132 such as /usr/mbin and /usr/5bin) and the non-set-UID/non-set-GID files within them. It also owned doco files and directories, such as manual pages.
(In more extreme cases on some Unices it even owned / and /etc, although the latter was an acknowledged mistake in the creation of a SunOS operating system image. The former was just dunderheaded.)
Thus the permission to enact software updates, running as user bin, was not a blanket permission, running as the superuser, to perform any action whatsoever against the system. The software upgrader could not read/write private user files, access mailboxes, and so forth; which updating softwares as the superuser of course could.
Several other special account entries in your— Rebecca Thomas and Rik Farrow (1989). UNIX Administration Guide for System V. Prentice Hall. ISBN 9780139428890. p. 452./etc/passwdfile must have passwords. These are the administrative accounts —bin,daemon,sys,uucp,lp, andadm. […] The primary reason for the existence of these accounts is the secure ownership of commands, scripts, files, and devices. And some administrators install passwords for these accounts and actually use them. […] A password-freebinaccount is extremely useful for a system breaker.
NFS was invented in the early 1980s, and broke this idea completely.
It was already on shaky ground, as the aforegiven quotation alludes. This was because the ability to update the program image files for basic utilities that the superuser executed as a matter of course, such as /bin/ls for example, is a direct vector for gaining superuser privileges, and the division of access in using a bin account merely prevented accidentally modifying the wrong directories rather than prevented a malefactor from gaining superuser access.
The advent of NFS highlighted this. Although NFS had a mechanism for remapping the superuser account to an ordinary non-system user account, it did not have the same for non-root-accounts like bin. So if someone could gain bin access on an NFS client it gave them bin access to the operating system files on an NFS server. Indeed, it enabled a superuser on an NFS client, who would otherwise be remapped to an ordinary non-system user on the server, to gain owner access to the server's operating system files and directories.
This was common knowledge by the early 1990s, and at that time received wisdom was to chown stuff that was owned by bin to being owned by the superuser, to plug this hole that had already become a standard reporting item in Unix security auditing tools and was warned against in the likes of the installation doco for Sendmail.
As far as M. Hess's questions are concerned, this idea was never adopted on Debian, which only came into existence years after it was known to be a bad idea in the Unix world, which indeed knew it to be a bad idea before Linux itself was invented. The BSD operating systems whose history does stretch back into the 1980s have long since done away with the actual ownership, but nonetheless retain the user account in the account database. FreeBSD converted bin:bin ownership to root:wheel ownership back in 1998, for example.
Further reading
- Jonathan de Boyne Pollard (2015).
/etc/inittabis a thing of the past.. Frequently Given Answers. - Jonathan de Boyne Pollard (2018). run-levels are things of the past.. Frequently Given Answers.
- Jonathan de Boyne Pollard (2018). Don't abuse nobody for running dæmons.. Frequently Given Answers.
- Thomas Benjamin (1995-11-07). Tiger flags *bin* owned system files, disabled accounts. comp.sys.hp.hpux.
- Bob Proulx (2002-09-15). Re: question about /etc/passwd entries. linux.debian.user.
- Doug Siebert (1999-06-22). Re: OS files owned by bin not root. comp.security.unix.
- Doug Siebert (1998-06-01). Re: AIX : "/" is owned by bin.bin. umn.local-lists.security.
- Theo de Raadt (1999-06-22). Re: OS files owned by bin not root. comp.security.unix.
- gene (1994-09-08). Why should bin not own a directory. comp.security.unix.
- Brad Powell (1993-08-12). Re: Root directory 'bin bin'?. comp.security.unix.
- Mario Wolczko (1991-09-13). Re: What breaks if /etc is not owned by bin?. alt.security.
edited Dec 4 at 4:38
Isaac
11k11648
answered Dec 2 at 15:34
JdeBP
32.7k468154
bin has not properly been for anything for the entire lifetime of Linux.
Like run-levels and init spawning getty because of records in /etc/inittab, the bin account was obsolete in the Unix world before Linux was even invented. It was an idea from the 1980s that was broken by the invention and adoption of NFS (Network File System) and its nobody user. Its continued presence in user account databases in the late 2010s when people in the commercial Unix world actively discontinued its use in the 1990s is a testament to inertia.
The idea was that the bin user owned various directories such as /bin and /usr/bin (and indeed some of the others mentioned at https://unix.stackexchange.com/a/448799/5132 such as /usr/mbin and /usr/5bin) and the non-set-UID/non-set-GID files within them. It also owned doco files and directories, such as manual pages.
(In more extreme cases on some Unices it even owned / and /etc, although the latter was an acknowledged mistake in the creation of a SunOS operating system image. The former was just dunderheaded.)
Thus the permission to enact software updates, running as user bin, was not a blanket permission, running as the superuser, to perform any action whatsoever against the system. The software upgrader could not read/write private user files, access mailboxes, and so forth; which updating softwares as the superuser of course could.
Several other special account entries in your— Rebecca Thomas and Rik Farrow (1989). UNIX Administration Guide for System V. Prentice Hall. ISBN 9780139428890. p. 452./etc/passwdfile must have passwords. These are the administrative accounts —bin,daemon,sys,uucp,lp, andadm. […] The primary reason for the existence of these accounts is the secure ownership of commands, scripts, files, and devices. And some administrators install passwords for these accounts and actually use them. […] A password-freebinaccount is extremely useful for a system breaker.
NFS was invented in the early 1980s, and broke this idea completely.
It was already on shaky ground, as the aforegiven quotation alludes. This was because the ability to update the program image files for basic utilities that the superuser executed as a matter of course, such as /bin/ls for example, is a direct vector for gaining superuser privileges, and the division of access in using a bin account merely prevented accidentally modifying the wrong directories rather than prevented a malefactor from gaining superuser access.
The advent of NFS highlighted this. Although NFS had a mechanism for remapping the superuser account to an ordinary non-system user account, it did not have the same for non-root-accounts like bin. So if someone could gain bin access on an NFS client it gave them bin access to the operating system files on an NFS server. Indeed, it enabled a superuser on an NFS client, who would otherwise be remapped to an ordinary non-system user on the server, to gain owner access to the server's operating system files and directories.
This was common knowledge by the early 1990s, and at that time received wisdom was to chown stuff that was owned by bin to being owned by the superuser, to plug this hole that had already become a standard reporting item in Unix security auditing tools and was warned against in the likes of the installation doco for Sendmail.
As far as M. Hess's questions are concerned, this idea was never adopted on Debian, which only came into existence years after it was known to be a bad idea in the Unix world, which indeed knew it to be a bad idea before Linux itself was invented. The BSD operating systems whose history does stretch back into the 1980s have long since done away with the actual ownership, but nonetheless retain the user account in the account database. FreeBSD converted bin:bin ownership to root:wheel ownership back in 1998, for example.
Further reading
- Jonathan de Boyne Pollard (2015).
/etc/inittabis a thing of the past.. Frequently Given Answers. - Jonathan de Boyne Pollard (2018). run-levels are things of the past.. Frequently Given Answers.
- Jonathan de Boyne Pollard (2018). Don't abuse nobody for running dæmons.. Frequently Given Answers.
- Thomas Benjamin (1995-11-07). Tiger flags *bin* owned system files, disabled accounts. comp.sys.hp.hpux.
- Bob Proulx (2002-09-15). Re: question about /etc/passwd entries. linux.debian.user.
- Doug Siebert (1999-06-22). Re: OS files owned by bin not root. comp.security.unix.
- Doug Siebert (1998-06-01). Re: AIX : "/" is owned by bin.bin. umn.local-lists.security.
- Theo de Raadt (1999-06-22). Re: OS files owned by bin not root. comp.security.unix.
- gene (1994-09-08). Why should bin not own a directory. comp.security.unix.
- Brad Powell (1993-08-12). Re: Root directory 'bin bin'?. comp.security.unix.
- Mario Wolczko (1991-09-13). Re: What breaks if /etc is not owned by bin?. alt.security.
edited Dec 4 at 4:38
Isaac
11k11648
answered Dec 2 at 15:34
JdeBP
32.7k468154
edited Dec 4 at 4:38
Isaac
11k11648
edited Dec 4 at 4:38
Isaac
11k11648
edited Dec 4 at 4:38
Isaac
11k11648
11k11648
answered Dec 2 at 15:34
JdeBP
32.7k468154
answered Dec 2 at 15:34
JdeBP
32.7k468154
answered Dec 2 at 15:34
JdeBP
32.7k468154
32.7k468154
1
I have seen files today owned by thebinuser and group on AIX systems. It’s possible that IBM uses it for a reason. One AIX fileset that comes to mind isjava. I will have to hop on the AIX systems at work to verify further.
– Peschke
Dec 2 at 18:25
There are still a substantial number of bin:bin-owned files on an AIX system today. The IBM Knowledge Center for AIX 7.2, in the Security - Securing the base operating system - Users, groups, and passwords section has the linked page explaining the purpose of the various "System special user accounts", includingbin.
– Jeff Schaller
Dec 3 at 17:17
From the previous link,binis not one of the common default user IDs that you might be able to remove. Also:bin's password entry is:bin:!:2:2::/bin:
– Jeff Schaller
Dec 3 at 17:17
add a comment |
1
I have seen files today owned by thebinuser and group on AIX systems. It’s possible that IBM uses it for a reason. One AIX fileset that comes to mind isjava. I will have to hop on the AIX systems at work to verify further.
– Peschke
Dec 2 at 18:25
There are still a substantial number of bin:bin-owned files on an AIX system today. The IBM Knowledge Center for AIX 7.2, in the Security - Securing the base operating system - Users, groups, and passwords section has the linked page explaining the purpose of the various "System special user accounts", includingbin.
– Jeff Schaller
Dec 3 at 17:17
From the previous link,binis not one of the common default user IDs that you might be able to remove. Also:bin's password entry is:bin:!:2:2::/bin:
– Jeff Schaller
Dec 3 at 17:17
1
1
I have seen files today owned by the
bin user and group on AIX systems. It’s possible that IBM uses it for a reason. One AIX fileset that comes to mind is java. I will have to hop on the AIX systems at work to verify further.– Peschke
Dec 2 at 18:25
I have seen files today owned by the
bin user and group on AIX systems. It’s possible that IBM uses it for a reason. One AIX fileset that comes to mind is java. I will have to hop on the AIX systems at work to verify further.– Peschke
Dec 2 at 18:25
There are still a substantial number of bin:bin-owned files on an AIX system today. The IBM Knowledge Center for AIX 7.2, in the Security - Securing the base operating system - Users, groups, and passwords section has the linked page explaining the purpose of the various "System special user accounts", including
bin.– Jeff Schaller
Dec 3 at 17:17
There are still a substantial number of bin:bin-owned files on an AIX system today. The IBM Knowledge Center for AIX 7.2, in the Security - Securing the base operating system - Users, groups, and passwords section has the linked page explaining the purpose of the various "System special user accounts", including
bin.– Jeff Schaller
Dec 3 at 17:17
From the previous link,
bin is not one of the common default user IDs that you might be able to remove. Also: bin's password entry is: bin:!:2:2::/bin:– Jeff Schaller
Dec 3 at 17:17
From the previous link,
bin is not one of the common default user IDs that you might be able to remove. Also: bin's password entry is: bin:!:2:2::/bin:– Jeff Schaller
Dec 3 at 17:17
add a comment |
up vote
-8
down vote
There are 2 case uses that I use bin for 2018. 1: executable's - mainly for web server side .exe files used to complete functions. And 2: logs - sometimes I put my .log or .dat files in my bin folder. Hope this answer helps you out in the long run.
answered Dec 3 at 0:33
jehovahsays
983
2
Are you talking about the/bindirectory? Or the bin user?
– Sparhawk
Dec 3 at 2:14
6
Are you even on any sort of Unix? You're talking about.exefiles.
– user62251
Dec 3 at 3:24
4
And why would you put logfiles or configuration files in a "bin" directory?
– Lightness Races in Orbit
Dec 3 at 12:44
add a comment |
up vote
-8
down vote
There are 2 case uses that I use bin for 2018. 1: executable's - mainly for web server side .exe files used to complete functions. And 2: logs - sometimes I put my .log or .dat files in my bin folder. Hope this answer helps you out in the long run.
answered Dec 3 at 0:33
jehovahsays
983
2
Are you talking about the/bindirectory? Or the bin user?
– Sparhawk
Dec 3 at 2:14
6
Are you even on any sort of Unix? You're talking about.exefiles.
– user62251
Dec 3 at 3:24
4
And why would you put logfiles or configuration files in a "bin" directory?
– Lightness Races in Orbit
Dec 3 at 12:44
add a comment |
up vote
-8
down vote
up vote
-8
down vote
There are 2 case uses that I use bin for 2018. 1: executable's - mainly for web server side .exe files used to complete functions. And 2: logs - sometimes I put my .log or .dat files in my bin folder. Hope this answer helps you out in the long run.
answered Dec 3 at 0:33
jehovahsays
983
There are 2 case uses that I use bin for 2018. 1: executable's - mainly for web server side .exe files used to complete functions. And 2: logs - sometimes I put my .log or .dat files in my bin folder. Hope this answer helps you out in the long run.
answered Dec 3 at 0:33
jehovahsays
983
answered Dec 3 at 0:33
jehovahsays
983
answered Dec 3 at 0:33
jehovahsays
983
answered Dec 3 at 0:33
jehovahsays
983
983
2
Are you talking about the/bindirectory? Or the bin user?
– Sparhawk
Dec 3 at 2:14
6
Are you even on any sort of Unix? You're talking about.exefiles.
– user62251
Dec 3 at 3:24
4
And why would you put logfiles or configuration files in a "bin" directory?
– Lightness Races in Orbit
Dec 3 at 12:44
add a comment |
2
Are you talking about the/bindirectory? Or the bin user?
– Sparhawk
Dec 3 at 2:14
6
Are you even on any sort of Unix? You're talking about.exefiles.
– user62251
Dec 3 at 3:24
4
And why would you put logfiles or configuration files in a "bin" directory?
– Lightness Races in Orbit
Dec 3 at 12:44
2
2
Are you talking about the
/bin directory? Or the bin user?– Sparhawk
Dec 3 at 2:14
Are you talking about the
/bin directory? Or the bin user?– Sparhawk
Dec 3 at 2:14
6
6
Are you even on any sort of Unix? You're talking about
.exe files.– user62251
Dec 3 at 3:24
Are you even on any sort of Unix? You're talking about
.exe files.– user62251
Dec 3 at 3:24
4
4
And why would you put logfiles or configuration files in a "bin" directory?
– Lightness Races in Orbit
Dec 3 at 12:44
And why would you put logfiles or configuration files in a "bin" directory?
– Lightness Races in Orbit
Dec 3 at 12:44
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2funix.stackexchange.com%2fquestions%2f485505%2fwhat-is-the-bin-user-for%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
A related question is unix.stackexchange.com/questions/244989 .
– JdeBP
Dec 5 at 19:33