Re: Security risk of vim swap files
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 <z...@z5t1.com>: >> 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 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, dezz...@gmail.com 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 >> certainl
Re: Security risk of vim swap files
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 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. 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, dezz...@gmail.com 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: Security risk of vim swap files
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, dezz...@gmail.com 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
