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

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

[Ciprian Dorin, Craciun]

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

    Just to be clear: I know how to trick an application to have it's
stdin and stdout be an opened socket (by using dup syscall). But in
this case I need to trick the Linux kernel into thinking that stdin /
stdout pair is a socket (or a single file descriptor).

    Thank you,
    Ciprian Craciun.

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

[Laurent Vivier]

[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]

Le dimanche 10 mai 2009 à 21:19 +0300, Ciprian Dorin, Craciun a écrit :
> Hello all!

Hi,

perhaps the attached patch I wrote last year (november) is what you
want...

I didn't try to apply it to an up-to-date qemu-nbd.

Regards,
Laurent

>     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.)
> 
>     Just to be clear: I know how to trick an application to have it's
> stdin and stdout be an opened socket (by using dup syscall). But in
> this case I need to trick the Linux kernel into thinking that stdin /
> stdout pair is a socket (or a single file descriptor).
> 
>     Thank you,
>     Ciprian Craciun.
> 
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Nbd-general mailing list
> Nbd-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nbd-general
> 
-- 
------------------ Laurent.Vivier@bull.net  ------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard

[-- Attachment #2: qemu-nbd-inetd.patch --]
[-- Type: text/x-vhdl, Size: 3645 bytes --]

---
 qemu-nbd.c |   41 +++++++++++++++++++++++++++++++++++------
 1 file changed, 35 insertions(+), 6 deletions(-)

Index: qemu/qemu-nbd.c
===================================================================
--- qemu.orig/qemu-nbd.c	2008-09-11 17:06:05.000000000 +0200
+++ qemu/qemu-nbd.c	2008-09-15 16:10:37.000000000 +0200
@@ -57,6 +57,7 @@ static void usage(const char *name)
 "  -d, --disconnect     disconnect the specified device\n"
 "  -e, --shared=NUM     device can be shared by NUM clients (default '1')\n"
 "  -t, --persistent     don't exit on the last connection\n"
+"  -i, --inetd          inetd interface: use stdin/stdout instead of a socke\n"
 "  -v, --verbose        display extra debugging information\n"
 "  -h, --help           display this help and exit\n"
 "  -V, --version        output version information and exit\n"
@@ -183,14 +184,14 @@ int main(int argc, char **argv)
     bool readonly = false;
     bool disconnect = false;
     const char *bindto = "0.0.0.0";
-    int port = 1024;
+    int port = 0;
     struct sockaddr_in addr;
     socklen_t addr_len = sizeof(addr);
     off_t fd_size;
     char *device = NULL;
     char *socket = NULL;
     char sockpath[128];
-    const char *sopt = "hVbo:p:rsnP:c:dvk:e:t";
+    const char *sopt = "hVbo:p:rsnP:c:dvk:e:ti";
     struct option lopt[] = {
         { "help", 0, 0, 'h' },
         { "version", 0, 0, 'V' },
@@ -207,6 +208,7 @@ int main(int argc, char **argv)
         { "shared", 1, 0, 'e' },
         { "persistent", 0, 0, 't' },
         { "verbose", 0, 0, 'v' },
+        { "inetd", 0, 0, 'i' },
         { NULL, 0, 0, 0 }
     };
     int ch;
@@ -225,6 +227,7 @@ int main(int argc, char **argv)
     int nb_fds = 0;
     int max_fd;
     int persistent = 0;
+    int inetd = 0;
 
     while ((ch = getopt_long(argc, argv, sopt, lopt, &opt_ind)) != -1) {
         switch (ch) {
@@ -289,6 +292,9 @@ int main(int argc, char **argv)
 	case 't':
 	    persistent = 1;
 	    break;
+        case 'i':
+	    inetd = 1;
+	    break;
         case 'v':
             verbose = 1;
             break;
@@ -326,6 +332,18 @@ int main(int argc, char **argv)
 	return 0;
     }
 
+    if (inetd) {
+        if (shared != 1)
+           errx(EINVAL, "You cannot use inetd and shared");
+        if (socket)
+           errx(EINVAL, "You cannot use inetd and socket");
+        if (port)
+           errx(EINVAL, "You cannot use inetd and port");
+    } else {
+        if (!socket)
+            port = 1024;
+    }
+
     bdrv_init();
 
     bs = bdrv_new("hda");
@@ -412,9 +430,24 @@ int main(int argc, char **argv)
     if (sharing_fds == NULL)
         errx(ENOMEM, "Cannot allocate sharing fds");
 
+    data = qemu_memalign(512, NBD_BUFFER_SIZE);
+    if (data == NULL)
+        errx(ENOMEM, "Cannot allocate data buffer");
+
     if (socket) {
         sharing_fds[0] = unix_socket_incoming(socket);
     } else {
+        if (inetd) {
+            /* read and write on stdin/stdout */
+            ret = nbd_negotiate(STDIN_FILENO, fd_size);
+            while (ret != -1) {
+                ret = nbd_trip(bs, STDIN_FILENO, fd_size, dev_offset,
+                               &offset, readonly, data, NBD_BUFFER_SIZE);
+            }
+            qemu_free(data);
+            bdrv_close(bs);
+            return 0;
+        }
         sharing_fds[0] = tcp_socket_incoming(bindto, port);
     }
 
@@ -423,10 +456,6 @@ int main(int argc, char **argv)
     max_fd = sharing_fds[0];
     nb_fds++;
 
-    data = qemu_memalign(512, NBD_BUFFER_SIZE);
-    if (data == NULL)
-        errx(ENOMEM, "Cannot allocate data buffer");
-
     do {
 
         FD_ZERO(&fds);

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

[Ciprian Dorin, Craciun]

On Mon, May 11, 2009 at 11:03 AM, Laurent Vivier
<Laurent.Vivier@bull.net> wrote:
> Le dimanche 10 mai 2009 à 21:19 +0300, Ciprian Dorin, Craciun a écrit :
>> Hello all!
>
> Hi,
>
> perhaps the attached patch I wrote last year (november) is what you
> want...
>
> I didn't try to apply it to an up-to-date qemu-nbd.
>
> Regards,
> Laurent
>
>>     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.)
>>
>>     Just to be clear: I know how to trick an application to have it's
>> stdin and stdout be an opened socket (by using dup syscall). But in
>> this case I need to trick the Linux kernel into thinking that stdin /
>> stdout pair is a socket (or a single file descriptor).
>>
>>     Thank you,
>>     Ciprian Craciun.
>>
>> ------------------------------------------------------------------------------
>> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
>> production scanning environment may not be a perfect world - but thanks to
>> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
>> Series Scanner you'll get full speed at 300 dpi even with all image
>> processing features enabled. http://p.sf.net/sfu/kodak-com
>> _______________________________________________
>> Nbd-general mailing list
>> Nbd-general@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/nbd-general
>>
> --
> ------------------ Laurent.Vivier@bull.net  ------------------
> "Tout ce qui est impossible reste à accomplir"    Jules Verne
> "Things are only impossible until they're not" Jean-Luc Picard

    Well, very clever! :) From what I've seen you are actually using
the stdin as the socket descriptor, knowing that if qemu-nbd was
started with the -i flag it means that inetd has already set both
stdin and stdout to a real socket, and thus everything works Ok.

    Unfortunately this works only with inetd (or compatible system)
without any SSL/TLS wrapping. My problem is that if the stdin and
stdout are instead pipes (as it would happen in case of sshd?, or
socat with SSL connector?) this would not work...

    Thank you for the idea. I could use if I don't find another solution.

    Ciprian.

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

[Anthony Liguori]

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

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

[Ciprian Dorin, Craciun]

On Mon, May 11, 2009 at 3:02 PM, Anthony Liguori <anthony@codemonkey.ws> 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.

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

[Wouter Verhelst]

On Mon, May 11, 2009 at 04:32:26PM +0300, Ciprian Dorin, Craciun wrote:
>     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...

That's still the case even if you do not use SSH port forwarding; NBD
does not actually implement anything remotely resembling security at
this point.

I've had plans to implement username/password authentication in
nbd-server and nbd-client, and there's even an implementation floating
around somewhere (written by someone else), but it still needs some work
and isn't finished. Additionally, I'd have to be able to get a patch
into qemu-nbd.c so that it'd support that kind of authentication, too.

-- 
<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

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

[Paul Brook]

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

In that case you need to fix socat to use splice() when available. I have a 
hard time believing socat adds measurable overhead, especially if you're 
already tunnelling over ssh.

Paul

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

[Anthony Liguori]

Paul Brook wrote:
>>     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...)
>>     
>
> In that case you need to fix socat to use splice() when available. I have a 
> hard time believing socat adds measurable overhead, especially if you're 
> already tunnelling over ssh.
>   

splice() doesn't really buy you anything when copying from a socket to 
another socket.  The data is going to get copied just like it would if 
you dropped to userspace.  It's useful if you introduce pipe-to-pipe 
copies because they'll be eliminated but if you're going from socket -> 
pipe -> socket it'll be the same as using socat.

Regards,

Anthony Liguori
> Paul
>