Why are executables in e.g. /usr/sbin writable by root?
Clash Royale CLAN TAG#URR8PPP
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.
linux files permissions root
edited Jan 26 '17 at 13:39
Kusalananda
136k17257425
asked Jan 26 '17 at 13:02
t1m0th33t1m0th33
16125
|
show 4 more comments
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.
linux files permissions root
edited Jan 26 '17 at 13:39
Kusalananda
136k17257425
asked Jan 26 '17 at 13:02
t1m0th33t1m0th33
16125
6
Just to clarify, you're wondering why the userroothas 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, usememmove()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 ofpread()/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 forETXTBSY). 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
|
show 4 more comments
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.
linux files permissions root
edited Jan 26 '17 at 13:39
Kusalananda
136k17257425
asked Jan 26 '17 at 13:02
t1m0th33t1m0th33
16125
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.
linux files permissions root
linux files permissions root
edited Jan 26 '17 at 13:39
Kusalananda
136k17257425
asked Jan 26 '17 at 13:02
t1m0th33t1m0th33
16125
edited Jan 26 '17 at 13:39
Kusalananda
136k17257425
asked Jan 26 '17 at 13:02
t1m0th33t1m0th33
16125
edited Jan 26 '17 at 13:39
Kusalananda
136k17257425
edited Jan 26 '17 at 13:39
Kusalananda
136k17257425
edited Jan 26 '17 at 13:39
Kusalananda
136k17257425
136k17257425
asked Jan 26 '17 at 13:02
t1m0th33t1m0th33
16125
asked Jan 26 '17 at 13:02
t1m0th33t1m0th33
16125
asked Jan 26 '17 at 13:02
t1m0th33t1m0th33
16125
16125
6
Just to clarify, you're wondering why the userroothas 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, usememmove()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 ofpread()/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 forETXTBSY). 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
|
show 4 more comments
6
Just to clarify, you're wondering why the userroothas 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, usememmove()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 ofpread()/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 forETXTBSY). 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
6
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
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
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
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
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
@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
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
@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
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
@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
|
show 4 more comments
1 Answer
1
active
oldest
votes
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
- installing a new version, or
- clumsy, or
- 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.
1BSD 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.
2A more comprehensive GitHub repository of Unix releases from the 70's onwards is available too.
answered Jan 26 '17 at 13:14
KusalanandaKusalananda
136k17257425
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 byroot.
– 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 didchmod -Ron/usror/var, and surprise - theirsudoisn'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?)
– Wumpus Q. Wumbley
Jan 26 '17 at 17:51
|
show 4 more comments
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',
autoActivateHeartbeat: false,
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%2f340295%2fwhy-are-executables-in-e-g-usr-sbin-writable-by-root%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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
- installing a new version, or
- clumsy, or
- 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.
1BSD 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.
2A more comprehensive GitHub repository of Unix releases from the 70's onwards is available too.
answered Jan 26 '17 at 13:14
KusalanandaKusalananda
136k17257425
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 byroot.
– 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 didchmod -Ron/usror/var, and surprise - theirsudoisn'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?)
– Wumpus Q. Wumbley
Jan 26 '17 at 17:51
|
show 4 more comments
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
- installing a new version, or
- clumsy, or
- 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.
1BSD 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.
2A more comprehensive GitHub repository of Unix releases from the 70's onwards is available too.
answered Jan 26 '17 at 13:14
KusalanandaKusalananda
136k17257425
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 byroot.
– 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 didchmod -Ron/usror/var, and surprise - theirsudoisn'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?)
– Wumpus Q. Wumbley
Jan 26 '17 at 17:51
|
show 4 more comments
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
- installing a new version, or
- clumsy, or
- 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.
1BSD 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.
2A more comprehensive GitHub repository of Unix releases from the 70's onwards is available too.
answered Jan 26 '17 at 13:14
KusalanandaKusalananda
136k17257425
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
- installing a new version, or
- clumsy, or
- 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.
1BSD 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.
2A more comprehensive GitHub repository of Unix releases from the 70's onwards is available too.
answered Jan 26 '17 at 13:14
KusalanandaKusalananda
136k17257425
edited Feb 21 at 19:23
answered Jan 26 '17 at 13:14
KusalanandaKusalananda
136k17257425
answered Jan 26 '17 at 13:14
KusalanandaKusalananda
136k17257425
answered Jan 26 '17 at 13:14
KusalanandaKusalananda
136k17257425
136k17257425
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 byroot.
– 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 didchmod -Ron/usror/var, and surprise - theirsudoisn'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?)
– Wumpus Q. Wumbley
Jan 26 '17 at 17:51
|
show 4 more comments
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 byroot.
– 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 didchmod -Ron/usror/var, and surprise - theirsudoisn'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?)
– Wumpus Q. Wumbley
Jan 26 '17 at 17:51
1
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
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
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
@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
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
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
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
+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
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?)
– Wumpus Q. Wumbley
Jan 26 '17 at 17:51
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?)
– Wumpus Q. Wumbley
Jan 26 '17 at 17:51
|
show 4 more comments
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.
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%2f340295%2fwhy-are-executables-in-e-g-usr-sbin-writable-by-root%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
6
Just to clarify, you're wondering why the user
roothas 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 ofpread()/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