25

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
bin:x:2:2:bin:/bin:/usr/sbin/nologin
%
… and on FreeBSD …

% getent passwd bin
bin:*:3:7:Binaries Commands and Source:/:/usr/sbin/nologin
%
… and on OpenBSD …

$ getent passwd bin
bin:*:3:7:Binaries Commands and Source:/:/sbin/nologin
$
… one can still today find a bin account. But it is pretty much undocumented. The Linux Standard Base version 5 says merely …

Notes: The bin User ID/Group ID is included for compatibility with legacy applications. New applications should no longer use the bin User ID/Group ID.
… without explaining the nature of the compatibility mechanism. As Joey Hess put it back in 2001:

bin:

HELP: No files on my system are owned by user or group bin. 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?

33

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 /etc/passwd file must have passwords. These are the administrative accounts — bin, daemon, sys, uucp, lp, and adm. […] 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-free bin account is extremely useful for a system breaker.
— Rebecca Thomas and Rik Farrow (1989). UNIX Administration Guide for System V. Prentice Hall. ISBN 9780139428890. p. 452.

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

  • 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 '18 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 '18 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 '18 at 17:17
-8

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.

  • 3
    Are you talking about the /bin directory? Or the bin user? – Sparhawk Dec 3 '18 at 2:14
  • 6
    Are you even on any sort of Unix? You're talking about .exe files. – user62251 Dec 3 '18 at 3:24
  • 5
    And why would you put logfiles or configuration files in a "bin" directory? – Lightness Races in Orbit Dec 3 '18 at 12:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.