Skip to content

Instantly share code, notes, and snippets.

@thbkrkr
Created September 21, 2016 09:45
Show Gist options
  • Select an option

  • Save thbkrkr/ee1706c9d481be613b8dd6429a9d83ae to your computer and use it in GitHub Desktop.

Select an option

Save thbkrkr/ee1706c9d481be613b8dd6429a9d83ae to your computer and use it in GitHub Desktop.
chmod 400 && sed
~ thb@io
> echo toto > toto
~ thb@io
> chmod 400 toto
~ thb@io
> cat toto
toto
~ thb@io
> sed -i "s|toto|tutu|" toto
~ thb@io
> cat toto
tutu
~ thb@io
> ll toto
-r-------- 1 thb thb 5 sept. 21 11:44 toto
~ thb@io
> sed -i "s|tut|WTF?|" toto
~ thb@io
> cat toto
WTF?u
@thbkrkr

thbkrkr commented Sep 21, 2016

Copy link
Copy Markdown
Author

This is not a bug, but rather a consequence of how the Unix filesystem works.
Yeah. this is something that really confuses new UNIX users.
But it has absolutely nothing to do with sed.
If you have write-access to a directory, you can delete any file in that directory. You can also create a new file in that directory with the same name as the old file. So write-permission on a directory is a bit like write-permission on everything beneath that directory.
The exception is the sticky bit... /tmp directories are traditionally 1777, meaning all can read, write and traverse, but the 1, the 'sticky bit' means that you can't delete or overwrite files you don't own.
With the sticky bit set, the directory functions the way most non-UNIX users expect; e.g. if I create a file and make it writable only to me, nobody else can overwrite it.

http://permalink.gmane.org/gmane.comp.gnu.utils.bugs/18060

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment