Could you please explain why a binary compiled file (in, for example, /usr/sbin) has write permission for root user?For me, this is compiled. Meaning that direct write has no use and may expose file to some security issue somehow.A script (e.g. a bash file) may be writeable because it is a text file basically, but why is it the same for a compiled file where no write is actually necessary as far as I know?Thank you in advance for your feedback. 
Why are executables in e.g. /usr/sbin writable by root?
linux;files;permissions;root
It doesn't really matter if the files in /bin (or any other standard directory where executables are kept) are writable by root or not. On a Linux server I'm using, they are writable by root, but on my OpenBSD machine, they're not.As long as they are not writable by the group or by other!There is no security issue having, e.g.-rwxr-xr-x 1 root root 126584 Feb 18  2016 /bin/lsIf someone wanted to overwrite it, they'd have to be root, and if they are root and overwrite it, then they are eitherinstalling a new version, orclumsy, oran attacker with root permissions already.Another thing to consider is that root can write to the file no matter if it's write protected or not, because... root.Notice too that a script is as much an executable as a binary file. A script doesn't need to be writable because it's a text file.  If anything, it should probably just have the same permission as the other executables in the same directory.Don't go changing the permissions on everything now! That can wreak all sorts of havoc and potentially confuse package managers who might verify that permissions are set properly. It may also make the system vulnerable if you accidentally change the permissions in the wrong way on a security-critical application.Just assume that the permissions on the executables are set correctly, unless you find something that looks really odd, in which case you should probably contact the relevant package maintainer to verify rather than start changing stuff.From the comments and on chat, there was a call for some history.The history of the permissions on binaries on Linux is not anything I know anything about. It may be speculated that they simply inherited the permissions from the directory, or just from the default umask of Linux, but I really don't know.What I do know is that OpenBSD installs the binaries in the base system1 with permission mode 555 by default (-r-xr-xr-x). This is specified in a Makefile fragment in /usr/share/mk/bsd.own.mk which sets BINMODE to 555 (unless it's set already).  This is later used when installing the executables during make build in /usr/src.I had a look at the annotated CVS log for this file, and found that this line in the file is unchanged since it was imported from NetBSD in 1995.On NetBSD, the file was first put into CVS in 1993, with BINMODE set to 555.The FreeBSD project seems to have used the exact same file as NetBSD since at least 1994, and with a later commit adds a hint in the commit message that the old files were from the 4.4BSD release of the Berkeley Software Distribution.Beyond that, the CSRG at Berkeley kept the sources in SCCS but their repository is available in Git form on GitHub2. The file that we're giving the forencic treatement here seems to have been committed by Keith Bostic (or someone in close proximity to him) in 1990.So that's that story. If you want the why, then I suppose we'll have to ask Keith. I was kinda hoping to see a commit message to a change saying this needs to be 555 because ..., but no.1 BSD systems have a stricter division into base system and ports/packages than Linux. The base system is a coherent unit that provides a complete set of facilities for running the operating system, while the ports or packages are seen as local software and are installed under /usr/local.2 A more comprehensive GitHub repository of Unix releases from the 70's onwards is available too.