3 ms·

> saving backups of files in ~/.vim/backup every time you save, and keeping an undo-per file Is this a security risk? Not complaining, as it can be changed in

> saving backups of files in ~/.vim/backup every time you save, and keeping an undo-per file Is this a security risk? Not complaining, as it can be changed in the vimrc, just want to pose the question.

cardanome 3y ago
For a file to end up in ~/.vim/backup you need to have (had) the right to edit it in the first place. (I assume) files that are edited as root would go into the root home directory, so no problem. I can maybe see it be a problem for servers but I can't really think of a likely case, you would have to mess up pretty badly.
- tczMUFlmoNk 3y ago
  On the other hand, files edited through a flow like `sudoedit(1)` get copied into /var/tmp with mode 0600 and edited under the user's editor. This is in some ways much better than something like `sudo vim`, since that's a lot of privilege to be granting to a large attack surface. But it does create files like ~/.undodir/%var%tmp%shadow.XXcFqVH3: also with mode 0600, but they stick around even after sudoedit(1) terminates. So I think that it's fair to say that it is a nonzero security risk because it creates persistent copies of potentially sensitive files. Aside from just a strict Unix permissions model, I think it's also easy to imagine cases where you create a sensitive file, edit it, delete it, and expect it to be really deleted. Or even just use Vim as a scratch buffer with no name! Yet undodir persists data in these cases, too.
  - csdvrx 3y ago
    > So I think that it's fair to say that it is a nonzero security risk because it creates persistent copies of potentially sensitive files. sudoedit is something I hadn't considered. The backup should have an exclusion list, with at least /var/tmp > Yet undodir persists data in these cases, too. Except showing the count of available backups files somewhere in the interface, I don't see an easy way to avoid that

cardanome 3y ago

For a file to end up in ~/.vim/backup you need to have (had) the right to edit it in the first place. (I assume) files that are edited as root would go into the root home directory, so no problem. I can maybe see it be a problem for servers but I can't really think of a likely case, you would have to mess up pretty badly.

tczMUFlmoNk 3y ago
On the other hand, files edited through a flow like `sudoedit(1)` get copied into /var/tmp with mode 0600 and edited under the user's editor. This is in some ways much better than something like `sudo vim`, since that's a lot of privilege to be granting to a large attack surface. But it does create files like ~/.undodir/%var%tmp%shadow.XXcFqVH3: also with mode 0600, but they stick around even after sudoedit(1) terminates. So I think that it's fair to say that it is a nonzero security risk because it creates persistent copies of potentially sensitive files. Aside from just a strict Unix permissions model, I think it's also easy to imagine cases where you create a sensitive file, edit it, delete it, and expect it to be really deleted. Or even just use Vim as a scratch buffer with no name! Yet undodir persists data in these cases, too.
- csdvrx 3y ago
  > So I think that it's fair to say that it is a nonzero security risk because it creates persistent copies of potentially sensitive files. sudoedit is something I hadn't considered. The backup should have an exclusion list, with at least /var/tmp > Yet undodir persists data in these cases, too. Except showing the count of available backups files somewhere in the interface, I don't see an easy way to avoid that