bug-sed
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27200: sed happily modifies read-only files.


From: Assaf Gordon
Subject: bug#27200: sed happily modifies read-only files.
Date: Fri, 2 Jun 2017 21:52:01 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

tag 27200 notabug
thanks

Hello,

On Fri, Jun 02, 2017 at 05:57:37PM +0200, Péter wrote:

sed happily modifies read-only files.

*Modifying* *write-protected* files sound me contradicting..

This is not a bug - just a sligthly wrong expectation of what
'write-protected' means.

When a FILE is 'write-protected' (technically: does not have
the write bit enabled in its access mode), it means you can not modify
fhe file's content.

Example:

   $ echo hello > 1.txt
   $ chmod a-w 1.txt
   $ echo world > 1.txt
   -bash: 1.txt: Permission denied

However, the directory where the file is stored is still writable
(which is why creating files works fine). Deleting
a file and renaming a file also works - it requires write-permission
for the directory, *not* for the file:

   $ echo a > 1.txt
   -bash: 1.txt: Permission denied
   $ mv -f 1.txt old1.txt
   $ ls -l
   total 4
   -r--r--r-- 1 gordon gordon 6 Jun  2 17:36 old1.txt

$ rm -f old1.txt $ ls -l
   total 0

To summarize: read-only access mode on a file protects *only*
the file's content. It does not protect the file from being deleted
or renamed.

Knowing the above, it's easier to see how 'sed -i' works:
it creates a temporary new file, then renames it to replace
the input file.

   # Create a write-protected file:

   $ echo CCC > 1.txt
$ chmod a-w 1.txt $ echo a > 1.txt
   -bash: 1.txt: Permission denied

   # Replace it using a temporary file:

   $ sed 's/C/zi/g' 1.txt > 1.tmp
   $ mv -f 1.tmp 1.txt

   # Or use 'sed -i', which is equivalent to using a temp file:

$ sed -i 's/C/zi/g' 1.txt $ cat 1.txt zizizi


In the example above I've used 'rm -f' and 'mv -f'
because these programs detect that a file does not have
the write-bit enabled, and as a courtesy ask the user
if he/she is sure about overwriting it - but there is
nothing technically that 'protects' the file from being deleted/renamed.

As such I'm closing this bug-report, but discussion can continue by replying to this thread.

regards,
- assaf









reply via email to

[Prev in Thread] Current Thread [Next in Thread]