*** This bug is a security vulnerability ***

Public security bug reported:

This bug is a little difficult to explain, but I will do my best. I'm
using Ubuntu Hardy Heron with no third party repositories. Every package
is up to date as of this posting.

It goes like this. When I edit files with vim or gvim through
gvfs/fuse/sftp the file permissions on the real remote file system get
destroyed. Here is a procedure you can follow to duplicate this bug. The
only non-default package you need installed is vim or gvim.

1 - Open a terminal and ssh to a remote machine.
2 - In this terminal create a text file on the remote machine, and set the 
permissions to 644. 
3 - Go to the Places->Connect to Server... menu item, and create an SSH 
connection to the remote machine.
4 - Double click the new sftp folder icon that appears on the desktop to open 
nautilus.
5 - In nautilus browse to the directory containing the text file you just 
created.
6 - Use the command ls -l in the ssh terminal to verify the permissions of the 
file are still 644.
7 - In nautilus right-click on the text file, open it with "Text Editor" (gedit)
8 - Make a change to the file in gedit and save it.
9 - Use the ls -l command in the terminal to verify that the permissions of the 
file are still 644.
10 - Exit gedit.
11 - In nautilus right-click on the text file and select the option to open it 
with "GVim Text Editor"
12 - Make some changes to the file in GVim, and save those changes.
13 - Use the ls -l command in the terminal, and you will see that the 
permissions of the file are now 600, not 644.

Some interesting things to note about this bug.

If you open the text editors from the command line, instead of through
nautilus, the same problem happens.

So opening gedit like this:
gedit ~/.gvfs/sftp\ on\ remote/home/user/test.txt
will not damage the permissions.

However, opening vim like this:
vim ~/.gvfs/sftp\ on\ remote/home/user/test.txt
will damage the permissions.

Also, I notice that if you do this
ls -l ~/.gfvs/sftp\ on\ remote/home/user/
the permissions of test.txt (and every other file) will appear to be 600 (700 
for directories), regardless of the file permissions on the "real" remote file 
system. If you attempt to chmod any files, it will result in a chmod of the 
actual permissions on the remote file system, but it will not change the 
permissions of the file in the local ~/.gvfs directory. 

This has led me to conclude that this bug is a combination of two
things. First, using the chmod command on files through gvfs/fuse/sftp
does not work in an expected fashion. Secondly, gvim and vim appear to
be chmod-ing files when they write to those files.

I'm not sure this bug is an actual security risk. It seems it can only
result in file permissions becoming more strict, not more permissive.
However, I have checked the security box just to be safe. If file
permissions involved, there could always be an unseen security issue. I
can see a situation where an application losing the ability to read a
needed file causes system breakage, if not a security hole.

** Affects: ubuntu
     Importance: Undecided
         Status: New

** Visibility changed to: Public

-- 
file permissions destroyed by vim/gvfs/fuse
https://bugs.launchpad.net/bugs/227808
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to