Re: Is it possible to forward unix sockets?

[Graham Percival <gperciva@tarsnap.com>]

I think that one (or both!) of us has a misunderstanding about unix sockets.
Based on my (limited) knowledge, it simply does not make sense to say "binds a
socket that I need to forward to a remote machine".  For example,
    bind() is typically used on the server side
    https://en.wikipedia.org/wiki/Berkeley_sockets

Let's put it this way: what are the ultimate endpoints of this communication?
Without any mention of spiped or socat.  As far as I understand it, you have:
- local machine binds a unix domain socket.
- remote machine wants to connect to that socket.

?  If that's the case, you would want to have
- local spiped decryption
- remote spiped encryption
(no socat)

You wrote "so decrypting on my local machine doesn't make sense", but I don't
understand why.

Cheers,
- Graham

On Thu, Jun 08, 2017 at 10:18:43AM +0800, JunglHilt wrote:
>    Yes I tried that...my local machine is behind NAT and it wouldn't be
>    desirable any way to have a connection back to my machine. I have a
>    process on my local machine that binds a socket that I need to forward
>    to a remote machine, so decrypting on my local machine doesn't make
>    sense - it needs to encrypt on my machine but that won't work as the
>    source socket is already bound (obviously).
>    At the moment I have socat performing the unix domain functions and
>    spiped doing network and encryption / decryption functions...I just
>    wondered if it was possible without socat, which I don't think it is,
>    unfortunately!
>    H
> 
>    On 8 June 2017 at 00:04, Graham Percival <[1]gperciva@tarsnap.com>
>    wrote:
> 
>      Yes, spiped is trying to bind the /tmp/blah socket, yet the file
>      /tmp/blah
>      already exists.  Please delete that file, then run your spiped -e
>      command, and
>      then run the other program which you want to send data to /tmp/blah.
>      (if that other program is also trying to bind /tmp/blah, then it
>      probably needs
>      to be re-thought.  The "server" program is the one which binds the
>      socket; the
>      "client" program merely connects to it.)
>      Cheers,
>      - Graham
>      On Wed, Jun 07, 2017 at 10:14:11PM +0800, JunglHilt wrote:
>      >    ok so I have the following :
>      >    A process which created a unix domain socket (/tmp/blah) on my
>      local
>      >    machine that I want to send to a remote machine
>      [1][2]4.3.2.1:9999 and end
>      >    up as /tmp/blah  on which side has another process that wants
>      to read
>      >    from the socket.
>      >    On the sending side I have :
>      >    spiped -e -F -s /tmp/blah -t [2][3]4.3.2.1:9999 -k key.key
>      >    yet it complains that the address is already in use...I thought
>      that
>      >    the intent of the source directive is to read from given source
>      but
>      >    perhaps it is trying to bind to that socket?
>      >    I'm not that familiar with sockets so please excuse any
>      paradigms that
>      >    I have gotten wrong.
>      >    H
>      >
>      >    On 7 June 2017 at 20:07, Colin Percival
>      <[3][4]cperciva@tarsnap.com>
>      >    wrote:
>      >
>      >      On 06/07/17 01:17, JunglHilt wrote:
>      >      > I'm trying to forward a unix domain socket securely over
>      the
>      >      internet and was
>      >      > wondering if this is possible with spiped?
>      >      Yes.
>      >      > I have tried specifying a socket as the source(on one side)
>      and
>      >      target on the
>      >      > other yet the target socket doesn't get created, so not
>      sure if
>      >      this is
>      >      > possible..?
>      >
>      >    spiped doesn't create the target socket.  spiped connects to
>      the target
>      >    socket, which should have been created by whatever process you
>      want to
>      >    connect to.
>      >    --
>      >    Colin Percival
>      >    Security Officer Emeritus, FreeBSD | The power to serve
>      >    Founder, Tarsnap | [4][5]www.tarsnap.com | Online backups for
>      the truly
>      >    paranoid
>      >
>      > References
>      >
>      >    1. [6]http://4.3.2.1:9999/
>      >    2. [7]http://4.3.2.1:9999/
>      >    3. mailto:[8]cperciva@tarsnap.com
>      >    4. [9]http://www.tarsnap.com/
> 
> References
> 
>    1. mailto:gperciva@tarsnap.com
>    2. http://4.3.2.1:9999/
>    3. http://4.3.2.1:9999/
>    4. mailto:cperciva@tarsnap.com
>    5. http://www.tarsnap.com/
>    6. http://4.3.2.1:9999/
>    7. http://4.3.2.1:9999/
>    8. mailto:cperciva@tarsnap.com
>    9. http://www.tarsnap.com/