remote API without X

[mattn]

Hi, bram and list.

In few weeks ago, Taro Muraoka posted a suggestion "+clientserver without X" written by Yukihiro Nakadaira.

I tested it on windows/linux both. It seems working good for me now.

I guess that this will be helpful to write client/server application with vimscript.

Until now, most linux user couldn't write vimscript the asynchronizing application. But this patch make be possible.

Bram, would you try to include it?

http://code.google.com/r/yukihironakadaira-vim-cmdsrv-nox/

Thanks.

- Yasuhiro Matsumoto

[Bram Moolenaar]

Yasuhiro Matsumoto wrote:

On Unix it uses sockets? How does it protect from other users sending
commands to my Vim?

That site doesn't seem to have a way to show a diff with the original
code. Perhaps you can make a diff available?

--
We are the Borg of GNU GPL. We will assimilate your source code.
Resistance is futile.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[mattn]

On Tuesday, June 7, 2011 12:50:38 PM UTC+9, Bram Moolenaar wrote:

Yasuhiro Matsumoto wrote:

> Hi, bram and list.
>
> In few weeks ago, Taro Muraoka posted a suggestion "+clientserver without X"
> written by Yukihiro Nakadaira.
> I tested it on windows/linux both. It seems working good for me now.
>
> I guess that this will be helpful to write client/server application with
> vimscript.
> Until now, most linux user couldn't write vimscript the asynchronizing
> application. But this patch make be possible.
>
> Bram, would you try to include it?
>
> http://code.google.com/r/yukihironakadaira-vim-cmdsrv-nox/

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. For windows, it use named pipe. This is provided for the user.

i.e. serverlist() is listing the files /tmp/vim-cmd-.... 

That site doesn't seem to have a way to show a diff with the original
code.  Perhaps you can make a diff available?

Sorry, now I can't attach the file. I put it on following.

https://raw.github.com/gist/1011747/ba51bf12e331e2287ad299875561cb62a5c4280e

Thanks.

- Yasuhiro Matsumoto

[Yukihiro Nakadaira]

Hello,

Attached file is latest diff.

hg clone https://yukihironakadaira-vim-cmdsrv-nox.googlecode.com/hg/ vim-cmdsrv-nox
cd vim-cmdsrv-nox
hg diff -r default -r cmdsrv-nox

--
Yukihiro Nakadaira - yukihiro....@gmail.com

[Bram Moolenaar]

Yasuhiro Matsumoto wrote:

> > > Hi, bram and list.
> > >
> > > In few weeks ago, Taro Muraoka posted a suggestion "+clientserver without
> > X"
> > > written by Yukihiro Nakadaira.
> > > I tested it on windows/linux both. It seems working good for me now.
> > >
> > > I guess that this will be helpful to write client/server application with
> >
> > > vimscript.
> > > Until now, most linux user couldn't write vimscript the asynchronizing
> > > application. But this patch make be possible.
> > >
> > > Bram, would you try to include it?
> > >
> > > http://code.google.com/r/yukihironakadaira-vim-cmdsrv-nox/
> >
> > 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. For windows, it use named pipe. This is
> provided for the user.
> i.e. serverlist() is listing the files /tmp/vim-cmd-....

This it's sure that only the user himself can access the Vim instance,
right?

> > That site doesn't seem to have a way to show a diff with the original
> > code. Perhaps you can make a diff available?
>
> Sorry, now I can't attach the file. I put it on following.
>
> https://raw.github.com/gist/1011747/ba51bf12e331e2287ad299875561cb62a5c4280e

Thanks. This is a big change. I won't have time for this soon. I hope
some others will try it out.

--
hundred-and-one symptoms of being an internet addict:
153. You find yourself staring at your "inbox" waiting for new e-mail
to arrive.

[Danek Duvall]

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.
> > For windows, it use named pipe. This is provided for the user. i.e.
> > serverlist() is listing the files /tmp/vim-cmd-....
>
> 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. 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.

Danek

[Yukihiro Nakadaira]

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)
- Check peer's credentials with OS specific method if possible.
(getpeerucred(), getpeereid(), LOCAL_PEERCRED or SO_PEERCRED)

I tested it with Ubuntu 11.04, OpenSolaris 2009.06 and FreeBSD 8.2.

src/configure.in was modified for getpeerucred() and getpeereid(). But
src/auto/configure is not updated yet.

[Bram Moolenaar]

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.
> >>> For windows, it use named pipe. This is provided for the user. i.e.
> >>> serverlist() is listing the files /tmp/vim-cmd-....
> >>
> >> 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. 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?

> - Check peer's credentials with OS specific method if possible.
> (getpeerucred(), getpeereid(), LOCAL_PEERCRED or SO_PEERCRED)
>
> I tested it with Ubuntu 11.04, OpenSolaris 2009.06 and FreeBSD 8.2.
>
> src/configure.in was modified for getpeerucred() and getpeereid(). But
> src/auto/configure is not updated yet.
>
> --
> Yukihiro Nakadaira - yukihiro....@gmail.com
>

> --
> 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

--
hundred-and-one symptoms of being an internet addict:

163. You go outside for the fresh air (at -30 degrees) but open the
window first to hear new mail arrive.

[Yukihiro Nakadaira]

Using per user directory with fixed name is for ease to list and access
Vim servers. It makes it simple to map server-id to socket path and vice versa.

[Yukihiro Nakadaira]

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.

[Benjamin R. Haskell]

[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

* " \ [ ] : ; | = ?

--
Best,
Ben