[had trouble with my Google for Domains address after they transitioned
my account, sorry if this shows up twice]
On Fri, 10 Jun 2011, Bram Moolenaar wrote:
Yukihiro Nakadaira wrote:
Danek Duvall wrote:
On Wed, Jun 08, 2011 at 06:38:14AM +0200, Bram Moolenaar wrote:
Yasuhiro Matsumoto wrote:
On Unix it uses sockets? How does it protect from other users
sending commands to my Vim?
Yes, it use unix domain socket. this control in
/tmp/vim-cmdsrv-UID-SERVERID on unix. And it is set permission
0600.
This it's sure that only the user himself can access the Vim
instance, right?
I know on Solaris, and I believe on Linux, at least at one point in
the past, the permissions on the socket itself don't actually
prevent anyone from reading or writing.
Linux respects socket permissions, but unix(7) (the manpage for UNIX sockets)
notes:
Portable programs should not rely on this feature for security.
(So, it's prudent to not rely on it, even if it works on Linux.)
The only protection comes from putting the socket inside a directory
that's inaccessible to anyone but the intended user(s).
Solaris has a getpeerucred() function which allows a program to get
the credential information about a socket's peer, but I don't know
if other OSes have any equivalents.
Thank you for your review.
I fixed the problem as
- Create per user directory with 0700 and store sockets in it.
(/tmp/vim-cmdsrv-UID/SERVERID)
Vim already creates a private directory for temp files. But it's
different for each Vim instance, do you need one for each user?
In addition to the portability requirement (proper socket security
requires a containing directory), it's using the directory as a
namespace. Otherwise, there's no nice way to track the various servers
that exist. Just based on what's currently open in my /tmp/ dir, this
is a pretty common pattern (It looks more common to use the username
rather than user ID, but using the ID makes more sense to me).
I really like this branch. Seems to work fine outside of X11, which is
something people have expressed interest in. It's unclear whether the X
implementation of +clientserver should just be excised. There are
things you can do with the X11-based version, since it's inherently a
networked protocol.
This implementation doesn't handle '/' in server names, since it uses
the filesystem. The only documentation I see about the name merely
states that the case of the name is ignored. It didn't specify much
else. Special characters seem to be handled fine, so it seems '/' and
'\x00' are the only restrictions on *nix. There would be a handful more
characters forbidden under typical Windows filesystems:
* " \ [ ] : ; | = ?
I'm not saying the lack of these characters is necessarily a problem.
Just that one of the following things should happen with servernames.
They could be:
1. documented - just say "Unix handles anything but / or nul characters"
2. munged - transform "/" to "%", ala the 'dir' option
3. escaped - transform any non-ASCII into UTF-8-encoded URI-escaped
names. école/䀀/lalala -> %C3%A9cole%2F%E4%80%80%2Flalala
3. collapsed - remove characters that can't be handled, and renumber if
one already exists but doesn't match (the way case-folding currently
does it)
4. specified - just require that the servername is limited to some range
of characters that tends to be handled reliably ( 7-bit ASCII without
'/' or something similar)
5. handled elsewhere - maybe instead of encoding it in the filename, the
pipe itself could be easily queried for the name, and then the filenames
could simply be sequential integers. (increment
/tmp/vim-cmd-{uid}/{number} until a free number is found)
--
Best,
Ben
--
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
