GNOME Bugzilla – Bug 324281
gnome-vfs ssh - gedit doesn't warn about files that are read only
Last modified: 2008-12-31 10:37:39 UTC
Distribution/Version: Debian Editing a file through a gnome-vfs ssh folder that is read only, gedit doesn't show the file as read only and doesn't warn that it can't save the file. It says it is saving the file, and shows the file as saved. Trying to save a read-only file locally or through a gnome-vfs smb folder, gedit functions normally. Debian unstable, Linux 2.6.14-ck7 gnomevfs 2.12.1
Yes this is a bug in gnome-vfs that we discovered and fixed, please try to upgrade to the last gnome-vfs and if possible confirm if things are better. For now we decided to not make gnome-vfs mandatory yet since not all users need vfs saving and compiling gnome-vfs is an additional burden that would reduce the number of testers, but we will bump the gnome-vfs requirements before 2.14.0
Upgrading to latest gnomevfs 2.12.2 actually makes it worse. Trying to open a file that the user doesnt have read bit displays the proper error. Opening a file that user has read bit, but not write bit, file opens but does not display that it is read only. It lets me save the file, even though I shouldnt be able to, not having write access to the file. It also changes the ownership of the file when saved, this is bad. I was allowed to save to a read only file owned by root, and it changed the owner of that file to the user. Is this is a priviledge bug in SSH? Example: Logged in as user web -rwxr-x--- 1 root root 30 2005-12-19 09:20 robots.txt Cant open the file, displays proper error. -rwxr-xr-- 1 root root 30 2005-12-19 09:20 robots.txt Doesn't open it as read only, allows user web to save the file, and changes the ownership of the file to web.web It is apparent that this isn't a problem with gedit, should I be filing this with gnomevfs or with SSH?
whoah! if that is true you should double check (maybe see if you can reproduce with gnomevfs-copy) and then file a bug against gnome-vfs. As a said above, it's a known issue that unless you upgrade to gnome-vfs 2.13.3 gedit may clain to have saved a remote file successfully even if it was not saved. But overwriting a file you cannot access should definately never happen!
Upgraded to gnomevfs 2.13.3 and now gnomevfs is showing the lock icon on read only files but still allowing me to overwrite them. So because gnomevfs isnt behaving properly I can't test that Gedit is behaving properly. I will file a bug against gnomevfs and when I get that hashed out I can test my gedit.
ok. Please CC me on that bug. Thanks again for your testing efforts, it's really appreciated!
So now that I have the gnomevfs stuff worked out. Using gnomevfs 2.13.3 I'm still having the same problem. I've verified that the file im trying to edit is read-only, gnomevfs says it's read only and wont let me overwrite it, but gedit still doesn't show it as read-only and lets me save it. I've purged all my gnomevfs libs and gedit. And I recompiled them both. Is there some other gnome 2.13 modules I need?
Adding a "me too" (Gedit 2.13.90, gnome-vfs 2.13.4 on Ubuntu Dapper) : on a SSH remote share, opening a file I own, mode 000 : error (normal behavior). on the same SSH share, opening the same file, mode 444 : i can write in it (closing and reopening the file in gedit shows me the text i just inserted), but i shouldn't be able to. on another SSH share, opening a root:root file, mode 644 : gedit seems to write in it, seems to save data on Ctrl-S, but if i close and reopen the file, what I inserted isn't there (normal).
Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/gedit/+bug/55269 "SFTP save of write-protected files 1) Open a file via sftp on a remote machine that you do not have write-permission for. 2) Make some change. 3) Save the file.... No error message...!!! The file on the remote machine is not changed. An error message of some kind would be good in this situation. ..."
Is this still a problem?
I will close this as obsolete, fill free to open it again if you find the bug in a newer gedit version.