The problem appeared in 4.10 and now it's not possible to edit files, which owned by groups user belongs to. Reproducible: Always Steps to Reproduce: 1. touch /tmp/test.txt 2. chmod 664 /tmp/test.txt 3. chown root:admin /tmp/test.txt (You must be in the admin group or use any other group You are in) 4. Open /tmp/test.txt with the Kate, edit it and try to save. Actual Results: You will get an error "The document could not be saved, as it was not possible to write to /tmp/test. Check that you have write access to this file or that enough disk space is available." But you can edit it with other editors, Nano, Geany or other.
Created attachment 77806 [details] Screenshot
*** This bug has been confirmed by popular vote. ***
But when editing files with kate, running with root privileges, it works Ok, owners of the editing files aren't changed.
I can confirm only half of this bug. The saving of a text file works, however the user is changed. I'm on Kubuntu 13.04 with KDE SC 4.10.1
I can confirm this bug for Fedora. If I run command 'chown alex:nobobdy /tmp/test.txt && kate /tmp/test.txt'. Edit and saved file. Group of file was changed to alex. I've created file as: $ touch /tmp/test.txt $ chmod 664 /tmp/test.txt $ chown alex:nobody /tmp/test.txt. After kate editing: $ ls -al /tmp/test.txt -rw-rw-r--. 1 alex alex 11 Mar 6 22:53 /tmp/test.txt
(In reply to comment #4) > I can confirm only half of this bug. The saving of a text file works, > however the user is changed. Look like You allowed to change owner of the file. When You can not do in, Kate will fail to save the file with write access error.
This may be related to https://bugs.kde.org/show_bug.cgi?id=312415 In Kate, we use KSaveFile to save files to disk. KSaveFile first saves the data to a temporary file in the same location, and then moves/renames the data to the destination. This way, either all data is written or none, minimizing the risk of loosing data. Would that behavior explain what you experience?
(In reply to comment #7) > Would that behavior explain what you experience? Yes, looks like so.
*** This bug has been marked as a duplicate of bug 312415 ***
"In Kate, we use KSaveFile to save files to disk. KSaveFile first saves the data to a temporary file in the same location, and then moves/renames the data to the destination. This way, either all data is written or none, minimizing the risk of loosing data. Would that behavior explain what you experience?" I have been having the same problem. And YES this explains it. However - OMG - Do you realize how fundamentally WRONG it is for Kate to be changing the file owner and group (regardless of the method)???? This is a horrific breach of security!! This produces SYSTEM bugs! If a user has permission to edit a system file that another process writes to - THIS BREAKS THE SYSTEM! Because the process then can't write to the file because the owner:group was changed. What were you guys thinking when you did this? Time to abandon this DANGEROUS Kate editor I think and remove it from all installations because an user can cause SYSTEM MALFUNCTION simply by clearing a log file with kate. OMG.
@David: Ignoring the rather impolite tone in comment #10, can you quickly clarify how KSaveFile on KDE 4 and QSaveFile on KF5 behave when a user saves a file that he does not own?
Ok so its now a few months later.. And with a new xubuntu install from 2 months ago and latest update I end up with this problem.. sigh! Messed me up this morning as a true spagtti code tiki.wiki.php app and one template changes permissions, means www-data could not read. Apache report no errors, neither did php.. sign..!! took a "few" hours to find it....
Ahem.... not an expert, but scanning down the issue it seems to be the idea that - 1 = I open a file - 2 = save it = making temp copy - 3 = use OS to cp temp to original So perms is lost.. Maybe what we need to do is on open u open temp file then at save cp origin to temp, and over write temp with origin inal.. Ie copy the file before save to "temp" overwrite temp with edited and then copy