emacs can't overwrite user's own write protection on file

On a recently installed fedora 25 system (uname -a → Linux [host] 4.10.6-200.fc25.x86_64 #1 SMP Mon Mar 27 14:06:23 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux; using GNU Emacs 25.1.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.22.4) of 2016-12-15 according to emacs' own opening page), I am unable to overwrite in emacs the write protection of my own files.

This is the way it happens:

(a) I open my write-protected file (ls -l → -r--------. 1 me me 92996 Apr 10 20:44 myfile),

(b) I disable write protection so I can edit (C-x C-q)

(d) I want to save (C-x C-s)

(e) I am prompted "File myfile is write-protected; try to save anyway? (yes or no) "

(f) I answer "yes", enter

(g) The message appears: "Opening output file: Permission denied, [full path]/myfile"

The directory is not write protected.

I have been able to edit and save my write-protected files forever on other systems (opensuse in the most recent years).

Disabling selinux mode on the system doesn't help. Please see more information in the comments.

I am unable to figure out what may be wrong.

Gyula

Posted 2017-04-11T08:05:13.020

Reputation: 41

What about SELinux labels? Are there any AVCs? – Jakuje – 2017-04-11T09:55:46.320

How can I check those? I am not sure what they are. However, note that the problem persists even when I disable selinux (after I set SELINUX=disabled in /etc/selinux/config and reboot afterwards). – Gyula – 2017-04-11T10:47:40.417

In my home directory (selinux disabled, see my previous comment) "ls -lZ" on the write protected "myfile" gives: [code] r--r--r-- 1 iam iam ? 12 Apr 12 13:14 ./myfile[code/]. On my home directory, the "ls -lZd ." command gives [code]drwxr-xr-x. 52 iam iam system_u:object_r:user_home_dir_t:s0 4096 Apr 12 13:15 ./[code/] – Gyula – 2017-04-12T19:29:32.577

In my home directory (selinux disabled, see my previous comment) "ls -lZ" on the write protected "myfile" gives: r--r--r-- 1 iam iam ? 12 Apr 12 13:14 ./myfile. On my home directory, the "ls -lZd ." command gives drwxr-xr-x. 52 iam iam system_u:object_r:user_home_dir_t:s0 4096 Apr 12 13:15 ./ The ausearch -m avc command seems to give no relevant information. Is this what you asked for? – Gyula – 2017-04-12T19:38:01.287

Yes. It was that. But in case it does the same with disabled SELinux, it will not be the cause. – Jakuje – 2017-04-12T19:43:35.480

Thank you for your answer. Is there anything else I may try? – Gyula – 2017-04-12T19:46:05.050

Answers

C-x C-q disables read-only for the buffer, not for its file.

The purpose of C-x C-q is to prevent yourself from accidentally changing the content of a buffer (whether or not it is a file buffer).

To change the permissions of a file, use one of the following:

Command chmod
Dired, with M (command dired-do-chmod)

Use C-h f to see the doc of each command:

chmod is an alias for set-file-modes in subr.el.

(chmod FILENAME MODE)

Set mode bits of file named FILENAME to MODE (an integer). Only the 12 low bits of MODE are used.

Interactively, mode bits are read by read-file-modes, which accepts symbolic notation, like the chmod command from GNU Coreutils.

dired-do-chmod is an interactive autoloaded compiled Lisp function in dired-aux.el.

It is bound to M, <menu-bar> <operate> <chmod>.

(dired-do-chmod &optional ARG)

Change the mode of the marked (or next ARG) files. Symbolic modes like g+w are allowed. Type M-n to pull the file attributes of the file at point into the minibuffer.

Drew

Posted 2017-04-11T08:05:13.020

Reputation: 1 898

Thank you all for your attention.
The question turned mute yesterday because, having given up on the problem, I ended up installing another linux distribution where emacs (there, emacs v24) behaves as usual.

Although my original problem hasn't been solved, I remain to entertain the following suspects for its cause:

Suspect 1: emacs 25, the version I had the problem with, may behave different from its predecessor in this respect. A hint to different behavior in general is that, for example, it doesn't accept the version 24's configuration file .emacs

Suspect 2: some file system or distribution specific setting.

Neither of the two suspicions have been followed up on, confirmed, or refuted.

Response to the previous answer (on chmod etc.): thank you for your input, but I am afraid you misunderstood my question (perhaps I was not clear enough to begin with). My problem was not how emacs can change a file's permissions, but: why in my case it refused to overwrite a protected file even when the user requested such action? (Indeed, C-x C-q changes only a buffer's editability, an editability that defaults after the permissions and/or kind of the file opened -- it was my mistake to use the wrong term for the effects of this keystroke combination.)

Gyula

Posted 2017-04-11T08:05:13.020

Reputation: 41

"it refused to overwrite a protected file even when the user requested such action". No. You did not request such action. That's not what C-x C-q does, as I explained. To "request such action" you need to use the Emacs chmod command. It's not about sending you to the OS chmod command. It's about the Emacs chmod command. That's what you use to "request such action" from Emacs. – Drew – 2017-04-17T23:57:18.727

You misunderstood me. I "requested such action" in bullet (f) of my original post, in response to the prompt according to bullet (e). In bullet (b), C-x C-q, I simply enabled buffer editing which had been disabled by default when emacs opened the write-protected file. As I described, all other emacs-es / systems I used before did effectively accept a "yes" response to said prompt in bullet (e), I didn't have to invoke emacs' chmod or any other functions, just reply "yes" in bullet (f), and the write protection was overwritten for that particular save operation. – Gyula – 2017-04-19T05:27:34.520

I see. Yes, Emacs tries to DTRT in that case. But the OS/file-manager might not let it. The code is in function basic-save-buffer-2 of files.el, if you want to follow it in the debugger (M-x debug-on-entry basic-save-buffer-2) to see why it cannot save the file. But if you've already changed your Linux version and you no longer see the problem then you probably can't do that. ;-) – Drew – 2017-04-19T13:56:10.970