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

%

% getent passwd bin

bin:*:3:7:Binaries Commands and Source:/:/usr/sbin/nologin

%

$ getent passwd bin

bin:*:3:7:Binaries Commands and Source:/:/sbin/nologin

$

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.

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?

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.

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/inittab is 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.

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.