vim can't edit non-group-writable on GVFS SSH mounts #5237
Comments
|
Can you bisect the commit?
… Am 17.11.2019 um 21:37 schrieb interfect ***@***.***>:
Describe the bug
Somewhere between Vim 7.4 and Vim 8 (or at least the Vim 8 that Ubuntu ships), the ability to write to files mounted over Gnome's Virtual File System (GVFS) was lost.
See this Ubuntu bug from a few months ago that nobody noticed:
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1813679
And see also this Ubuntu bug I went to report again today, having forgotten about the first bug
because nobody ever responded to it:
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1852927
To Reproduce
Detailed steps to reproduce the behavior:
Open Nautilus, hit Ctrl+L to get the URL bar, and type in "ssh://your.server", and hit enter.
Navigate to a directory.
Create a file through Nautilus (Right-click -> New Document -> New Text Document). (You may need to touch ~/Templates/New\ Text\ Document.txt if you don't have one.
Open the document with gvim.
Edit it.
Try to save it.
Expected behavior
The document should save.
Screenshots
Instead I get an error like this:
"/run/user/1000/gvfs/sftp:host=your.server/path/to/your/file.txt: E212: Can't open file for writing"
Environment (please complete the following information):
Vim version:
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jun 06 2019 17:31:41)
Included patches: 1-1453
Modified by ***@***.***
Compiled by ***@***.***
Huge version with GTK2 GUI. Features included (+) or not (-):
+acl +farsi +mouse_sgr -tag_any_white
+arabic +file_in_path -mouse_sysmouse +tcl
+autocmd +find_in_path +mouse_urxvt +termguicolors
-autoservername +float +mouse_xterm +terminal
+balloon_eval +folding +multi_byte +terminfo
+balloon_eval_term -footer +multi_lang +termresponse
+browse +fork() -mzscheme +textobjects
++builtin_terms +gettext +netbeans_intg +timers
+byte_offset -hangul_input +num64 +title
+channel +iconv +packages +toolbar
+cindent +insert_expand +path_extra +user_commands
+clientserver +job +perl +vertsplit
+clipboard +jumplist +persistent_undo +virtualedit
+cmdline_compl +keymap +postscript +visual
+cmdline_hist +lambda +printer +visualextra
+cmdline_info +langmap +profile +viminfo
+comments +libcall -python +vreplace
+conceal +linebreak +python3 +wildignore
+cryptv +lispindent +quickfix +wildmenu
+cscope +listcmds +reltime +windows
+cursorbind +localmap +rightleft +writebackup
+cursorshape +lua +ruby +X11
+dialog_con_gui +menu +scrollbind -xfontset
+diff +mksession +signs +xim
+digraphs +modify_fname +smartindent +xpm
+dnd +mouse +startuptime +xsmp_interact
-ebcdic +mouseshape +statusline +xterm_clipboard
+emacs_tags +mouse_dec -sun_workshop -xterm_save
+eval +mouse_gpm +syntax
+ex_extra -mouse_jsbterm +tag_binary
+extra_search +mouse_netterm +tag_old_static
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
defaults file: "$VIMRUNTIME/defaults.vim"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 -Wdate-time -g -O2 -fdebug-prefix-map=/build/vim-8l5tlu/vim-8.0.1453=. -fstack-protector-strong -Wformat -Werror=format-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -L. -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o vim -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lnsl -lselinux -lacl -lattr -lgpm -ldl -L/usr/lib -llua5.2 -Wl,-E -fstack-protector-strong -L/usr/local/lib -L/usr/lib/x86_64-linux-gnu/perl/5.26/CORE -lperl -ldl -lm -lpthread -lcrypt -L/usr/lib/python3.6/config-3.6m-x86_64-linux-gnu -lpython3.6m -lpthread -ldl -lutil -lm -L/usr/lib/x86_64-linux-gnu -ltcl8.6 -ldl -lz -lpthread -lm -lruby-2.5 -lpthread -lgmp -ldl -lcrypt -lm
OS: Ubuntu 18.04
Terminal: GUI
Additional context
Weirdly, this only seems to affect files created by Nautilus. Files creaded by opening a terminsl, cd-ing into /run/user/1000/gvfs/sftp:host=your.server/path/to/your/ and touch-ing file2.txt don't have this problem.
This also only seems to affect Vim 8+. My build of 7.4.1689 doesn't have this problem. nano does not have this problem.
This affects both CLI vim and GUI gvim.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
OK, I think I have the commit, and I have a much easier way to reproduce the problem. My Nautilus's text document template has 644 permissions (not group writable), while my regular umask has me creating files with 664 permissions (group writable). When Vim tries to save a file that is not group writable over a GVFS SSH mount, it fails, even if the file is owned and writable by the user you are doing the SSH mount as. I ran a bisect and it looks like cd142e3 is the offending commit: |
interfect
changed the title
|
The only thing I can think of is that that commit adds some calls to |
|
OK, I think I have the commit, and I have a much easier way to
reproduce the problem.
My Nautilus's text document template has 644 permissions (not group
writable), while my regular umask has me creating files with 664
permissions (group writable). When Vim tries to save a file that **is
not group writable** over a GVFS SSH mount, it fails, even if the file
is owned and writable by the user you are doing the SSH mount as.
I ran a bisect and it looks like
cd142e3 is the offending commit:
```
commit cd142e3
Author: Bram Moolenaar ***@***.***>
Date: Thu Nov 16 17:03:45 2017 +0100
patch 8.0.1300: file permissions may end up wrong when writing
Problem: File permissions may end up wrong when writing.
Solution: Use fchmod() instead of chmod() when possible. Don't truncate
until we know we can change the file.
If I remember correctly it was intentional that by default we do not
give a file more permissions than what the original file had. Thus
"umask" is applied on top of the original permissions. Not sure if this
is exactly the case for you.
Anyway, I find it very strange that a write fails because of lacking
permissions, other than directory permissions. Should be possible to
create a file only readable by the user and nothing else.
…--
I AM THANKFUL...
...for the piles of laundry and ironing because it means I
have plenty of clothes to wear.
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
|
I can't tell if the write is really failing, or why it is failing, or if the code is bailing out for some other reason. Is there something I can put in there instead of printfs to trace things? My user umask on the local machine is 0022, and on the remote machine it's 0002. The offending commit adds some calls to umask which I don't quite understand what they're for, but if any logic depends on the set umask actually taking effect, it won't work, because the local/process umask isn't respected when making files on a GVFS SSH mount. |
|
Seems like the same issue (#5309) if file has eXecute chmod enabled. And sometimes else, so I'm even not sure... |
|
Any news on this? |
|
Messing around with the code, seems like the removal of O_TRUNC ( line 4406 in src/fileio.c of cd142e3 ) causes this issue on FUSE GVFS. Without actually diving into it, I can only say that I think this has something to do with the way open() interacts with FUSE in the kernel - it only works when we have either O_TRUNC or O_APPEND set. I'm pretty confident this isn't an issue with the commit itself, just that it exposed some weirdness in the kernel. Changing line 4390 in src/fileio.c of this specific commit actually resolves the issue for me: #ifdef HAVE_FTRUNCATE
- # define TRUNC_ON_OPEN 0
+ # define TRUNC_ON_OPEN O_APPEND
#else
# define TRUNC_ON_OPEN O_TRUNC
#endifNo guarantees on the legitimacy or security of that, though. -- I've been getting into the weeds on this. I've ruled out the Linux Kernel (open() syscall), FUSE, and GVFS / GIO. I've only verified this issue on Thunar/Nautilus-mounted GVFS so far. My running suspicion is how those programs actually set up the mount. Setting up a mount manually (via the gio program) seems to not have this issue. I'm pretty positive this isn't a vim issue, but it's definitely interesting that we can work around it. For now, I'll just set up the sftp mounts manually b/c that's a better solution for me. -- I found the following issues in gvfs, whose solutions resolve this issue: https://gitlab.gnome.org/GNOME/gvfs/-/issues/370 I get that these issues aren't exactly describing the behavior here, but restarting/stopping the gvfs-daemon in userspace suddenly had things working again (for a little bit). Judging by this issue: https://gitlab.gnome.org/GNOME/gvfs/-/issues/249 It appears the correct workaround is to open with O_TRUNC or O_APPEND until the O_WRONLY and O_RDWR operations are fully supported. I'm not going to spend much more time on this, but I hope this helps anyone who stumbles upon this like I have. |
Problem: open() may fail with EOPNOTSUPP in linux if opening a file in a gvfs-fuse mount with O_WRONLY or O_RDWR when neither O_TRUNC nor O_APPEND is set; This is a known issue: [GNOME/gvfs#249](https://gitlab.gnome.org/GNOME/gvfs/-/issues/249) Solution: Open a file with O_APPEND when not specifically overwriting or truncating. Memfile functions may still be affected by this bug, sorry. Closes: vim#5237
Describe the bug
Somewhere between Vim 7.4 and Vim 8 (or at least the Vim 8 that Ubuntu ships), the ability to write to files created by Nautilus in directories mounted over Gnome's Virtual File System (GVFS) was lost.
See this Ubuntu bug from a few months ago that nobody noticed:
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1813679
And see also this Ubuntu bug I went to report again today, having forgotten about the first bug
because nobody ever responded to it:
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1852927
To Reproduce
Detailed steps to reproduce the behavior:
touch ~/Templates/New\ Text\ Document.txtif you don't have one.Expected behavior
The document should save.
Screenshots
Instead I get an error like this:
Environment (please complete the following information):
Additional context
Weirdly, this only seems to affect files created by Nautilus. Files creaded by opening a terminsl,
cd-ing into/run/user/1000/gvfs/sftp:host=your.server/path/to/your/andtouch-ingfile2.txtdon't have this problem.This also only seems to affect Vim 8+. My build of 7.4.1689 doesn't have this problem. nano does not have this problem.
This affects both CLI
vimand GUIgvim.The text was updated successfully, but these errors were encountered: