Benjamin R. Haskell wrote:
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)
I think that it is better to keep compatibility. I fixed it to use
URI-escape for server name, but use internal encoding as is. There is
still limit on maximum length of server name which is about 80 bytes.
Percent-encoded name must fit in this limit.
--
Yukihiro Nakadaira - [email protected]
--
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
