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

[Péter]

(We are discussing about these bits: 
https://www.gnu.org/software/coreutils/manual/html_node/Mode-Structure.html)

 $ ls -la
 total 24
 drwxrwxr-x 2 pp pp  2048 jún    7 15:31 .
 drwxrwxr-x 4 pp pp 18432 jún    7 15:31 ..
 -r--r--r-- 1 pp pp    10 jún    7 15:02 foo

 $ cat foo
 ccccccccc

Are you stating that in this case the file is (should be treated) writable? 
Just as if the file had permissions
 -rw-rw-rw- 1 pp pp    10 jún    7 15:02 foo
? Without any difference?
Any program can and should ignore the lack of the "w" bits? The "w" bit (in this case) has no meaning at all? Does not 
give any protection? Completely to-be-ignored? Role-less?


Sorry, I can not believe that.



Some *facts*:

 $ vi foo

When trying to insert something: "W10: Warning: Changing a readonly file"
When trying to save the file: "[RED] E45: 'readonly' option is set (add ! to 
override)"

 $ nano foo

When trying to save (after some insertion): "[ Error writing foo: Permission denied 
]"

 $ geany foo

When trying to save (after some insertion), a message box rises with red spot:
"Error saving file.", "Error opening file /home/xx/bar/foo: Permission denied"

 $ echo FFFFF >foo
 bash: foo: Permission denied

 $ echo FFFFF >nii
 $ ls -la
 total 26
 drwxrwxr-x 2 pp pp  2048 jún    7 15:48 .
 drwxrwxr-x 4 pp pp 18432 jún    7 15:31 ..
 -r--r--r-- 1 pp pp    10 jún    7 15:02 foo
 -rw-rw-r-- 1 pp pp     6 jún    7 15:48 nii
 $ mv nii foo
 mv: replace 'foo', overriding mode 0444 (r--r--r--)? n

 $ cat nii >foo
 bash: foo: Permission denied

 $ rm foo
 rm: remove write-protected regular file 'foo'? n

 $ python3 -c 'with open("foo", "w") as f: f.write("FFFFFFFF\n")'
 Traceback (most recent call last):
   File "<string>", line 1, in <module>
 PermissionError: [Errno 13] Permission denied: 'foo'

 $ cat foo
 ccccccccc

All of these programs do respect that bit.




I know that this protection is not hyper-strong. Can be "circumvented". If a (bad) guy wants to modify the foo file, 
(s)he can accomplish it (with the trick of using unlink instead of mv ...):

 $ cat foo >zaa
 $ ls -la
 total 26
 drwxrwxr-x 2 pp pp  2048 jún    7 16:05 .
 drwxrwxr-x 4 pp pp 18432 jún    7 15:31 ..
 -r--r--r-- 1 pp pp    10 jún    7 15:02 foo
 -rw-rw-r-- 1 pp pp    10 jún    7 16:05 zaa
 $ nano zaa

(Some modifications, "write out", to the same name, exit.)

 $ chmod --reference=foo zaa
 $ unlink foo
 $ mv zaa foo


But this does not give the right to any program, which is called to act on foo, 
to give *zero* protection, even no warning.

(Of course, you can (and will) apologize that sed, when called upon that file, internally will do the (or variant of) 
circumvention. [Including the copying of permission bits! Just to hide that some new file was created..] But.. those are 
internals (from the viewpoint of the user).)

Write-protecting also the outer directory is not well affordable (not zero-cost) because almost every user wants (the 
possibility of) adding (and removing) new files. The user had to constantly chmod-ing the directory. Before and after 
each file-addition, file-deletion, etc..


(I remain unconvinced, unless will state otherwise.)



Bob Proulx:
> Very few commands do anything special with read-only files.
> [] And python

python not (as seen above).

> Pretty much every command other than vi, rm, mv.