qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Transforming stdin and stdout pair into a socket


From: Ciprian Dorin, Craciun
Subject: Re: [Qemu-devel] Transforming stdin and stdout pair into a socket
Date: Mon, 11 May 2009 16:32:26 +0300

On Mon, May 11, 2009 at 3:02 PM, Anthony Liguori <address@hidden> wrote:
> Ciprian Dorin, Craciun wrote:
>>
>>    Hello all!
>>
>>    Today I've played around with NBD (Network Block Disk), and
>> qemu-nbd (a NBD client that exports QEMU disks as NBD's).
>>
>>    My problem is the following: both NBD kernel module and qemu-nbd
>> implementation expect to use a socket in order to communicate.
>>    This means that in order to securely tunnel the connection over
>> SSH (OpenSSH), I need an intermediary process that creates a socket
>> and forwards all input / output between this socket and stdin / stdout
>> (which are in fact pipes received from OpenSSH).
>>
>>    My question is: can I somehow make the pair of stdin / stdout seem
>> as a socket to the Linux syscalls (read and write)? (I would have to
>> make stdin / stdout pair look like a single file descriptor.) (This
>> would eliminate the intermediate process that just pipes data, and
>> thus reduce the overhead.)
>>
>
> Something like socat should to do the trick.
>
> For instance, if you have qemu-nbd on localhost:1025:
>
> ssh -l user hostname.com socat stdio tcp:localhost:1025
>
> Alternative, you could just do ssh based port forwarding.  For instance:
>
> ssh -l user -L 1025:localhost:1025 hostname.com
>
> And then connect locally with nbd-client
>
> Regards,
>
> Anthony Liguori

    I've seen socat, and I could use it as you described. My only
objection to this solution is that there is an unneeded process in the
middle that just pipes data around...

   (Instead of socat, I think it would be more efficient to just write
a simple application that uses the "new" Linux syscall "splice" that
I've just found by mistake yesterday...)

    About the other solution with SSH port forwarding, I don't really
like it, because it has some security implications: any process on the
local machine can access the block device... (I know I can use
iptables to actually restrict the process.) Still on the same topic I
would have liked something like UNIX domain socket forwarding for SSH.
(Which is available as a patch but on top of an older version...)

    Ciprian.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]