4

Let's say you open a file on which you have write permission. Meanwhile you change permissions and remove write permission while you still have the file open in some editor.

What will happen if you edit and save it?

lpostula
  • 143

2 Answers2

6

The permissions of a file are checked when the file is opened. Changing the permissions doesn't affect what processes that already have the file open can do with it. This is used sometimes with processes that start with additional privileges, open a file, then drop those additional privileges: they can still access the file but may not be able to reopen it.

However editors typically do not keep a file open. When an editor opens a document, what happens under the hood is that the editor loads the file contents in memory and closes the file. When you save the document, the editor opens the file and writes the new content.

Editors can follow one of two strategies when saving a file. They can create a new file, then move it into place. Alternatively, they can open the existing file and overwrite the old contents. Overwriting has the advantage that the file's permission and ownership do not change, and that it works even in a read-only directory. The major disadvantage of overwriting is that if saving fails midway (editor crash, system crash, disk full, …), you are left with a truncated document. Different editors choose different strategies; the good one do write-to-new-then-move if possible, and overwrite only in a read-only directory (after making a backup somewhere else).

If the editor follows the new-then-move strategy, the permissions on the file don't matter: the editor will create a new file, and it only needs write permission on the directory for that. There are two exceptions: if the directory has the sticky bit, changing the ownership of the file (but not the permission) may make it impossible for the process to move the new file into place. Another exception is on systems that support delete permission through ACLs (such as OSX): revoking the delete permission from the file may make the move impossible.

If the editor follows the overwrite strategy, revoking write permission will make saving impossible. (However, some editors that overwrite by default may fall back to new-then-move.)

In Vim, you can force the overwrite strategy by turning off the backupcopy option; see also why inode value changes when we edit in "vi" editor?. In Emacs, you can force the overwrite strategy by setting the backup-by-copying variable to t.

2

You can do all the edits you like, but when you try to save, your editor will complain that the file cannot be written to. If your editor creates a backup file, the changes will be obviously saved to the backup file.

Depending on your editor, you may be able to override this. In vim for example, I can save to a non-writable file if I'm either the file's owner or root by entering the command :w! (the ! means to forcibly apply the write action). Other editors, like gedit for instance, don't allow you to save the file and instead offer you a Save As... option.

Update

Thanks to msw's comment below, you should note that this behavior is actually due to the way editors are designed: they use a temporary file (buffer) to hold all your edits until you actually decide to write your buffer to the file.

Joseph R.
  • 39,549
  • Ok, so it doesn't matters what was the file permissions at the openning, because these wll be check at the savnig ( the file permissions), thanks a lot – lpostula Sep 01 '13 at 10:37
  • 4
    But note that's an artifact of how most editors are designed (using temporary files until write). If I have a file descriptor open and you change the mode of the i-node while I have it open, the permissions at my time of open() will not change until I close it. You can even unlink the file I have open and it won't affect my open descriptor. – msw Sep 01 '13 at 12:42
  • @msw So If we do not use an editor but use C command like open,... I will be able to write on the file descriptor – lpostula Sep 01 '13 at 15:16