Those are very valid points, and I agree that the way Neovim handles .swp files is better. I've already explained on here and on Openwall numerous reasons why I believe that is the best solution and made the case that .swp files should be stored in ~/.vim/swap by default. However Bram has veto power and shot that idea down.
So instead I'm trying to find the next best way to address this. /var/lib being writable only by root and therefore requiring cooperation from packagers did not occur to me, but that's definitely a problem. Maybe it would be doable as a major change in the next major release of Vim, but you're right; that definitely won't work as a security patch. So much for that idea. I maintain a Linux Distribution (Cucumber Linux) and have already adopted the Neovim style ~/.vim/swap approach on there. Maybe we'll just have to hope that other distributions independently start doing something similar, as Bram seems pretty convinced this problem is completely a user error and has nothing to do with the way Vim works; he's also pretty set on not changing the default .swp location. On 11/06/2017 01:20 PM, Nikolay Aleksandrovich Pavlov wrote: > 2017-11-06 20:39 GMT+03:00 Scott Court <[email protected]>: >> Update: I just read through the Filesystem Hierarchy Standard more >> carefully, and it appears there actually is a directory for this purpose: >> /var/lib in which the FHS states we can create a /var/lib/vim/swap >> subdirectory in for this purpose. >> >> From >> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBLTEDITORGTEDITORBACKUPFILESAN >> >> /var/lib/<editor> : Editor backup files and state (optional) >> >> Purpose >> >> These directories contain saved files generated by any unexpected >> termination of an editor (e.g., elvis, jove, nvi). >> >> Other editors may not require a directory for crash-recovery files, but may >> require a well-defined place to store other information while the editor is >> running. This information should be stored in a subdirectory under /var/lib >> (for example, GNU Emacs would place lock files in /var/lib/emacs/lock). >> >> Maybe we should store the .swp files there. > That needs active support from package maintainers: on my system > (Gentoo) /var/lib is writeable only by root and I do not think that is > uncommon. So Vim cannot create a directory there on its own when run > by a user and it needs to be created by a package when it is > installed. And there is still a question regarding what to do on > Windows. > > Neovim has currently chosen to store swap, undo, backup (fallback, > first directory is still dot) and view files under $XDG_DATA_HOME/nvim > (Windows: $XDG_DATA_HOME is %LOCALAPPDATA%, but suffix is `nvim-data` > unlike just `nvim` on *nix because $XDG_CONFIG_HOME is also > %LOCALAPPDATA% (our choice and not a standard, XDG does not apply on > Windows)). Reasoning (including “why you should not consider > ‘preventing simultaneous access’ a valid argument for existence of > swap files in a particular location”) may be seen in > https://github.com/neovim/neovim/issues/4481. > >> >> >> On 11/06/2017 12:29 PM, Scott Court wrote: >> >> The problem with storing the .swp tiles in /tmp though is that (on most >> distributions) /tmp gets cleared on every reboot, which is a problem >> since one of the major purposes of .swp files is to allow recovery of a >> vim session after system crash/hard reboot. >> >> Also, the default Apache httpd config does permit serving of . (dot) files. >> >> Perhaps we should store the swap files in a sticky directory visible by >> all users that is a) not ever going to be on a **shared** NFS and b) not >> going to be cleared on reboot (say /var/cache/vim/swap), and then set >> the permissions for all .swp files to 0600. >> >> It's also not really reasonable to expect every user of Vim to be aware >> of every potential security vulnerability and edit his configuration >> files to protect against them. See the first paragraph of the "Secure by >> Default" section at https://www.openbsd.org/security.html. >> >> >> On 11/06/2017 11:29 AM, [email protected] wrote: >> >> On Tuesday, October 31, 2017 at 3:11:55 PM UTC+1, Christian Brabandt wrote: >> >> It is true, that this can cause a problem. However, I am not sure its >> correct to blame vim here. >> >> First, I think you need to configure your webserver to be able to view >> dotfiles. I believe a default installation of at least apache won't let >> you show dotfiles. Second, I wonder why those swapfiles are not deleted. >> Somehow Vim must have crashed or be killed and in that case one >> certainly don't want that the swapfiles are deleted (think of recovery). >> >> I agree. Although a multi-user system usually is connected via ssh - in that >> same scenario sometimes the connection is interrupted or people are on flaky >> wifi. This leaves ~ swapfiles littered over the system more frequently as a >> multi-user system over ssh. Which gives more reason to not litter the >> current directory for multi-user environments even with the argument of >> people editing the same file. Most people are annoyed by littered files over >> a filesystem. >> >> One could argue, that swap files should be stored below ~/.vim directory >> tree. But what if several users edit the same file? One also needs to >> make sure, the path would be encoded into the name, but then we might >> run into trouble with filename length limitations. >> >> A shared directory in /tmp for all vim instances on a multi-user system >> would solve the issue while not littering the filesystem. >> >> >> So I think it in the users responsibility to configure Vim correctly >> (check the directory option) to not have him litter his document root >> with old swap files. >> >> Almost every .vimrc I've ever read had a line to set directory to exclude >> current directory and it is more an annoyance than a feature when countless >> people are asking this question over and over again what filename~ files >> are. I agree vim should be geared towards multi-user systems as well and >> warn when appropriate. It just makes more sense to have it in $TMP in that >> case and retain that behaviour. >> >> >> >> -- >> -- >> You received this message from the "vim_dev" maillist. >> Do not top-post! Type your reply below the text you are replying to. >> For more information, visit http://www.vim.org/maillist.php >> >> --- >> You received this message because you are subscribed to the Google Groups >> "vim_dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
