file permissions destroyed by vim/gvfs/fuse

Hi Apreche,

Thank you for the report as well as the detailed instructions to reproduce the issue. It's much appreciated. I've tried to confirm the issue you are seeing but am unsuccessful in reproducing the bug. I was able to follow your instructions completely up until step 11. In step 11, when I right clicked on the file, Nautilus by default didn't give me an option to launch gvim to open the file. I then decided to use the right-click->Open with Other Application ... which did allow me to select "GVim Text Editor". However, that did not open the file on the remote server, it actually opened a new file locally :( I guess that's a different bug I'll need to report. I even played with right-click->Properties->Open With tab to get GVim to launch properly but still had no luck. You mentioned you were able to reproduce this apart from using Nautilus, so I went ahead and tried opening/editing the file via the command line at Step 11 instead. I issued the following:

gvim sftp://leann@leann//home/leann/bug.txt

I was able to edit the remote file just fine and save my changes. The permissions (664) remained as they should. I did not witness the permissions changing to 600 as you were able to produce. I tried to issue the same type of command that you had documented (vim ~/.gvfs/sftp\ on\ remote/home/user/test.txt) at Step 11 but was unable to as my ~/.gvfs directory is empty. I'll include some of the package information I have below just to confirm we have the same versions of packages? Maybe there are some discrepancies which might account for why I'm unable to reproduce this issue? If you have any other ideas for triggering this, please let me know and I'll give it a test. I'll also see if I can have anyone else try and reproduce the issue as you've documented.

I'd like to add that there is a kernel patch that I was hoping to test to see if it would resolve this issue you are seeing bug since I am unable to reproduce the original bug, testing the patch doesn't make much sense.

Thanks.

ogasawara@yoji:/$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

ogasawara@yoji:~$ cat /proc/version_signature
Ubuntu 2.6.24-16.30-generic

ogasawara@yoji:~$ apt-cache policy vim-gnome
vim-gnome:
  Installed: 1:7.1-138+1ubuntu3
  Candidate: 1:7.1-138+1ubuntu3
  Version table:
 *** 1:7.1-138+1ubuntu3 0
        500 http://archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

ogasawara@yoji:~$ apt-cache policy nautilus
nautilus:
  Installed: 1:2.22.2-0ubuntu4
  Candidate: 1:2.22.2-0ubuntu4
  Version table:
 *** 1:2.22.2-0ubuntu4 0
        500 http://archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

ogasawara@yoji:/$ apt-cache policy openssh-client
openssh-client:
  Installed: 1:4.7p1-8ubuntu1
  Candidate: 1:4.7p1-8ubuntu1
  Version table:
 *** 1:4.7p1-8ubuntu1 0
        500 http://archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

ogasawara@yoji:~$ apt-cache policy gvfs
gvfs:
  Installed: 0.2.3-0ubuntu5
  Candidate: 0.2.3-0ubuntu5
  Version table:
 *** 0.2.3-0ubuntu5 0
        500 http://mirrors.cat.pdx.edu hardy-updates/m...

Hrm, so after a little more testing I'm able to reproduce. I switched the roles of the local and remote machines and can use Apreche's instructions exactly to reproduce the bug.

Anyhow, I'll go ahead and try to test the kernel patch now to see if it helps. Thanks.

Unfortunately the upstream kernel patch did not resolve this bug. I'll inline the patch I tested below just for reference. Thanks.

commit 1a823ac9ff09cbdf39201df37b7ede1f9395de83
Author: Miklos Szeredi <email address hidden>
Date: Sat Feb 23 15:23:27 2008 -0800

    fuse: fix permission checking

diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
index 7fb514b..c4807b3 100644
--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -906,7 +906,7 @@ static int fuse_permission(struct inode *inode, int mask, st
        }

        if (fc->flags & FUSE_DEFAULT_PERMISSIONS) {
- int err = generic_permission(inode, mask, NULL);
+ err = generic_permission(inode, mask, NULL);

                /* If permission is denied, try to refresh file
                   attributes. This is also needed, because the root

gvim sftp://leann@leann//home/leann/bug.txt

Yes, this will not produce the error because gvim will connect to the remote "real" file system directly through sftp. The error only happens when going through the gvfs/fuse file system.

Further thinking about it, I think this bug comes from two places. First, why does vim chmod files when it saves them? Other text editors don't do this. Perhaps a vim patch is necessary?

Second, how come all files in the gvfs/fuse file system have permissions of either 600 or 700? What if someone wants to make a script in the gvfs/fuse file system executable? What if someone wants to allow a web server to deliver files from a gvfs/fuse file system? These things are not possible if all permissions are defaulted to 600/700 and all chmods are passed through to the underlying "true" file system (at least with sftp they are).

I think there needs to be a fundamental change to the way gvfs/fuse deals with file permissions.

FWIW I also am experiencing this behavior.

This has already caused a few problems when deploying fixes for clients. If there's anything I can do to assist in the resolution of this, let me know.

I've investigated this issue more thoroughly, and I think I have come to the conclusion that this is a bug in vim. Here is a quote from the vim documentation.

<blockquote>Vim attempts to preserve the ACL info when writing a file. The backup file
will get the ACL info of the original file.</blockquote>

I attempted to change some of the options in vim, such as set nowritebackup, but that didn't help. I was guessing that vim was creating a backup file with incorrect permissions, and then overwriting the real file with the backup file. However, even with nowritebackup set, which disabled the backup file behavior, the permissions are still destroyed. vim is the only text editor to have this problem. I'm going to submit a bug to vim to see what they say.

If you're still seeing this problem with ":set backupcopy=yes", then I'd definitely push the bug to gvfs/fuse. Even if that still exhibits the behavior, I'd be inclined to think this is a bug in gvfs/fuse. Yes, Vim's behavior is not the same as other editors but that doesn't make it wrong. A properly functioning filesystem should be able to give Vim enough information that it can replicate the permissions of the original file.

So further information, but more confusing to me.

If I mount via
'sshfs user@host:/path/ mountpoint'
then edit the file with vim, I have no problems with permission/ownership resets.

If I mount via
'alt+f2
ssh://user@host'

then travel to path/ and edit the file, I see the permission problem.

Up until now I've been using gvfs/fuse with ssh. For the sake of experimentation, I tried this problem with gvfs/fuse and windows sharing. Here's what happened.

I setup two Ubuntu 8.04 machines on the same network. One one machine I created a Public read/write file share on a folder named Public. I did this through the gui in Nautilus. On the other machine I went to places->connect to server to mount the share. On the host machine in the shared folder I created a file named test.txt with permissions of 644. The owner and group of the file were both srubin (me).

Next, on the client machine, I went into the ~/.gvfs folder to find the file test.txt. The permissions on the file were set to 700, owner and group were both apreche (my user on the client machine). I then proceeded to make a minor edit to the test.txt file in the ~/.gvfs folder with vim and write the changes.

After writing the changes, the permissions on the host changed! Instead of being 644 srubin:srubin they were now 744 nobody:nogroup. This is still the same bug, but it is not the same as what happens when using ssh. With ssh the permissions would have changed to 700 without changing the user or group.

Also, Jonathan, the reason sshfs does not have a problem is that it does not involve gvfs or fuse.

I'm having the same issue with anjuta, with a mounted sftp via gvfs.

The original file octal is 644 and when changed and saved in anjuta it get's saved with 600.

maybe it's related

Because I was reminded of this bug, I decided to check again. I can confirm that on my completely up to date install of Ubuntu 8.04, this bug is still in effect. I tested multiple text editors this time. Some of them caused the bug to appear, and some did not.

Editing with vim, emacs, or anjuta(scintilla) all resulted in the undesired change of permissions.

Editing with gedit or nano did not change the permissions.

Editing with anjuta(gtksourceview) failed to even open my test file over gvfs.

I ran these tests over two different gvfs/sftp connections. One connection was to a FreeBSD 6.3 box, and the other was to an Ubuntu 8.04 server. I imagine that looking at the source code of the save functions in these different text editors will bring the cause of this problem to light.

This bug hasn't been touched in a while. Can somebody confirm if it is still a problem in 8.10?

I just tested the bug, and the same exact problem persists in 8.10.

I think really this is one of those bugs where you have two competing projects/philosophies against each other. It's not a problem of coding the solution, it's a problem of resolving conflict.

When something is mounted in .gvfs, the virtual file system applies a umask of 077. This makes sense. If I use SSH to mount a virtual file system from another machine, I can't allow anyone else on the local machine to have any permissions on the remote files.

If a user chmods a file in the virtual file system, the chmod is passed onto the real file system. That makes sense. I might virtually mount a directory on a web server I'm working on, and I might want to change permissions on some files so the web server allows access to them. I don't want the chmod to allow other users on the client end to go poking around my web server. I want it to change permissions on the other side.

Some text editors, and I'm sure other programs as well, like to set a files permissions when they save. I'm sure they have a valid reason for this, even though I personally can't think of any. In order to set the permissions, the text editor first needs to know what the original permissions are. When they ask the virtual file system for the permissions, they are told the post-umask permissions. This is correct, otherwise the text editor might thing a file is read-write when it is read-only or some other such situation. When the editor saves the file, it also sets the permissions. The virtual file system doesn't modify its own permissions, it passes the chmod down the line to the real file system it represents. As a result, the local permissions overwrite the remote permissions, and the umask is pushed through.

You have two separate things which behave correctly and appropriately when considered individually, but act very badly when working in combination. It's a problem that affects all virtual file systems. You want to give users the functionality to modify remote permissions, but you want the local security of the umask. I think there definitely needs to be a philosophical discussion before we're going to see a resolution.

could anybody try on jaunty?

Tested with Jaunty Live CD. Same exact problem still exists.

Permissions on .gvfs folder are set to 700 in order to prevent unauthorized access of virtual file systems by other users of local system. vim and some other applications are running chmods and passing these permissions through to the virtual file system to the underlying non-virtual file system.

the issue is an upstream one and should ideally be sent on bugzilla.gnome.org, could somebody there do that?

Any news on this bug? It's still in 9.04 & 9.10..

The bug is still there !

(see here : https://bugs.launchpad.net/gedit/+bug/199167 )

I do not appear to be on the list of subscribers to this issue, so I don't
know why I've gotten this e-mail.

I had a similar problem, but in gvim.

Larry Siden, 734-926-9614, http://umich.edu/~lsiden

The United States is a nation of laws, badly written and randomly enforced.
--Frank Zappa 1940-1993

On Mon, Jan 18, 2010 at 11:41 PM, David V. <email address hidden> wrote:

> The bug is still there !
>
> (see here : https://bugs.launchpad.net/gedit/+bug/199167 )
>
> --
> file permissions destroyed by vim/gvfs/fuse
> https://bugs.launchpad.net/bugs/227808
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Still a problem as of this posting.
Really irritating to have a "ghost" bug crop up while doing remote edits - and then finding out GVFS's weird decision on apparent local permissions (all permissions being displayed incorrectly, and occasionaly the user being wrong too) force applications to reset thigns to the wrong settings.

The fudge /sadface.

Hax

sshfs does not exhibit this problem, and is a workaround i've had to use in the meantime.

I just tested this on the latest 10.04 RC. The bug still exists. It's exactly the same as it has been for two years.

10.04 final here, and this bug is exhibiting itself (I use Emacs). Is there a way to *not* set the 077 umask on GVFS dirs? That could be a potential workaround.

I have the same problem with Ubuntu 10.04
I notice that gedit works fine, so I think the problem is only gvim + fuse , isn't it?

In reply to #25, I believe the reason it happens with gvim but not gedit is because gedit natively supports opening files via gvfs, whereas gvim doesn't and so it gets passed the "~/.gvfs" path, but the permissions are not exposed correctly there. I do not know if this is intentional or a bug, but it is making it very hard to use gvfs for making remote edits (to configs etc.) with gvim. I'm also currently using sshfs/fuse as a workaround, but I have to manually mount things so I hope I'll one day be able to just use gvim/gvfs.

I'm using Ubuntu 11.04 and this problem still exists. Steps to reproduce:

1. Open Nautilus
2. Press <CTRL> + L.
3. In the address bar, enter: sftp://yourserver:/path/to/file
4. Right-click on a text file and open it with GEdit (select 'Open with TextEdit').
5. Make a change to the file.
6. Save the file.
7. ssh yourserver
8. cd /path/to/file
9. ls -l

The owner of the file is changed to the username you logged in as in step 3, and the permissions are 700.

I hope this bug is fixed soon as it completely ruins a really cool way of working in Linux.

Im having the same problem in ubntu 11.04.
And is only happening with vim and gvim. The others editor i use, geany, gedit are working ok.

Me too, also on 10.04. Vim (7.2) itself works find using sftp://blah, rsync://blah, etc. from its own command line, but when opening from GVFS, permissions on the remote file are set to 600 each time the file is saved.

Sorry to make extra comments, but I'll just add that after installing sshfs (fuse was already installed), then mounting the remote server by creating /mnt/servername, and using 'sshfs user@servername:/path/ /mnt/servername/ -p port', I was able to use gvfs to navigate to /mnt/servername and open, edit and save the file using GVim without problems. This is both a workaround, and perhaps useful in narrowing down the problem.

This problem also happens with Qt Creator!

So coming on 5 years now and still not fixed?

Any chance of it EVER being fixed?

At this point I hope it is never fixed. It's more hilarious that I keep getting emails every year or so when people discover it.

Still an issue.. I just ran into this myself.

Also affecting me on Ubuntu 12.04 with emacs editing a file mounted from a remote server via gvfs. Permissions are set to 600.

This bug has surprised me several times as well. Works with practically any other text editor
except Qt Creator, Vim and Emacs. Is SSHFS a workaround?

5 years, 9 months and 3 days have passed since the first report...

Also a problem here on Xubuntu 13.10
Permissions set to 600 when connecting to remote site through ssh using gvfs and editing with Sublime Text 3

sorry for double-post
it should read "Beyond Compare 3" instead of "Sublime Text 3" in my comment above

I can confirm this issue

Fedora
Vim
GVFS

Anyone have a work-around until it get's addressed?

@Marc Thomas: A not particular work around is to install sshfs* and mount the file systems manually. I found that IntelliJ (netbeans) stopped overwriting permissions when mounted this way.

*See: http://shellspells.org/sshfs/

This is fixed upstream in gvfs 1.21.1.

Interesting to note that despite all the comments, no one bothered to file a bug upstream.

This bug is back again as a regression in:

patben@patben-amd:~/.ssh$ apt-cache policy gvfs gedit kate
gvfs:
  Zainstalowana: 1.24.2-0ubuntu4
  Kandydująca: 1.24.2-0ubuntu4
  Tabela wersji:
 *** 1.24.2-0ubuntu4 0
        500 http://pl.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages
        100 /var/lib/dpkg/status
gedit:
  Zainstalowana: 3.10.4-0ubuntu13
  Kandydująca: 3.10.4-0ubuntu13
  Tabela wersji:
 *** 3.10.4-0ubuntu13 0
        500 http://pl.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages
        100 /var/lib/dpkg/status
kate:
  Zainstalowana: 4:15.08.2-0ubuntu1
  Kandydująca: 4:15.08.2-0ubuntu1
  Tabela wersji:
 *** 4:15.08.2-0ubuntu1 0
        500 http://pl.archive.ubuntu.com/ubuntu/ wily/universe amd64 Packages
        100 /var/lib/dpkg/status

1) Logged as root to remote system (on purpose)

1A) Tested with Kate editor:
  on remote OS, changed permissions: 644 -> 640
  on remote OS, changed ownership: user.group -> root.system

1B) Tested with Gedit editor, content saved, and no changes in ownership and permissions.

Do you need some additional activity from me to speed up fixing this? Some strace/ltrace/debug?