31

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.

  • 6
    Just to clarify, you're wondering why the user root has write permission to a binary file? If nothing else it would help when upgrading that package. – Eric Renouf Jan 26 '17 at 13:32
  • 5
    Note that ironically binary files are the only files that we normally write/edit directly on disk. We can't do that with text files like scripts because text modifications involve not writing to the file but adding extra bytes in the middle of the file or deleting bytes in the middle of the file. This is impossible to do with fseek fwrite. So for text files we normally read to RAM then delete the old file and write the contents of RAM to disk (ie. we overwrite). Also, when you install, move or replace executables, you are writing to disk so you need write permissions. – slebetman Jan 26 '17 at 14:29
  • 1
    @slebetman: You can directly edit text files. For example, open the file, extend it, memory map it, use memmove() to move the last part to the end and open a hole, then insert new text into the hole. Or you can use a series of pread() / pwrite() to do the same. – Zan Lynx Jan 26 '17 at 17:15
  • 6
    @EricRenouf Actually, write permissions on the binary file is not required to upgrade the package that contains it. On package upgrade, the old binary is not written to; in fact this is impossible if the binary is currently running (search for ETXTBSY). Instead, the old binary is removed, and the new binary is written to a new file of the same name. Removing files does not require write permissions on them, merely on the containing directory (i.e., /usr/sbin/). – marcelm Jan 26 '17 at 21:15
  • 1
    @marcelm: Strictly speaking you're not merely using fseek and write, you're buffering the remainder to RAM. You can also buffer the remainder to another file. Or you can write new content to a new file. None of which allows you to extend text files without some sort of large buffer. – slebetman Jan 27 '17 at 0:50
50

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/ls

If someone wanted to overwrite it, they'd have to be root, and if they are root and overwrite it, then they are either

  1. installing a new version, or
  2. clumsy, or
  3. an 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 "3rd party packages" (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.

  • 1
    Thank you for you answer. Write permission is normal as it doesn't really matter as being root user (he can do anything). But, as it doesn't really matter, why don't we put no write permission if it is the same from the start? Is it arbitrary decision? – t1m0th33 Jan 26 '17 at 13:25
  • 1
    @t1m0th33 I belive it may be an arbitrary decision that someone has taken, yes. As I said, on my OpenBSD system, the files in those locations are not writable by root. – Kusalananda Jan 26 '17 at 13:28
  • 1
    I don't think it's a conscious decision by anyone. The package manager defaults to installing the file with the permission bits they ended up with during the build process; while building the linker created the files with permissions 755 because that's what you get when you subtract the umask from 777, and the umask root (on the OS vendor's build machines) had while building was 022 because 022 is the default umask for everyone and making it be 222 for root would be pointless extra work. – Henning Makholm Jan 26 '17 at 14:49
  • 8
    +1 for "Don't go changing the permissions on everything now!" I see so many questions like that on Ask Ubuntu where user did chmod -R on /usr or /var , and surprise - their sudo isn't working or something else isn't working. – Sergiy Kolodyazhnyy Jan 26 '17 at 17:38
  • 4
    Historically the absence of write permission for root would have no effect (root can chmod anything, and doesn't even need to, because root never gets an EPERM on open or write anyway). I wonder if this 555 stuff started because it had actually become possible for root to be restricted (when did securelevels first show up? around the same time as 4.4BSD or early 386BSD/NetBSD?) – user41515 Jan 26 '17 at 17:51

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.