From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <36ae46f3a656c0a71bbb5ef794532c5e@gmx.de> To: 9fans@9fans.net Date: Sun, 9 Jan 2011 02:53:20 +0100 From: cinap_lenrek@gmx.de In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-deczmyjpchpcsoojpyakeljiva" Subject: Re: [9fans] Streaming 9P is out Topicbox-Message-UUID: 925ea954-ead6-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-deczmyjpchpcsoojpyakeljiva Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit thinking about it... why not just let stream() fail and let the program decide if it makes sense to continue without it? way simpler than the struct Stream bookkeeping or returning a pipe and spawning a relay process in the background. fd = open(....); /* use streaming if possible */ if((sfd = stream(fd)) >= 0) dup(sfd, fd); -- cinap --upas-deczmyjpchpcsoojpyakeljiva Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-bounces@9fans.net> Delivered-To: GMX delivery to cinap_lenrek@gmx.de Received: (qmail invoked by alias); 09 Jan 2011 00:46:41 -0000 Received: from mail.9fans.net (EHLO mail.9fans.net) [67.207.142.3] by mx0.gmx.net (mx081) with SMTP; 09 Jan 2011 01:46:41 +0100 Received: from localhost ([127.0.0.1] helo=[67.207.142.3]) by mail.9fans.net with esmtp (Exim 4.71) (envelope-from <9fans-bounces@9fans.net>) id 1PbjSE-0001nh-G9; Sun, 09 Jan 2011 00:48:18 +0000 Received: from mail-bw0-f49.google.com ([209.85.214.49]) by mail.9fans.net with esmtp (Exim 4.71) (envelope-from ) id 1PbjSC-0001nc-Gl for 9fans@9fans.net; Sun, 09 Jan 2011 00:48:16 +0000 Received: by bwz5 with SMTP id 5so18552499bwz.36 for <9fans@9fans.net>; Sat, 08 Jan 2011 16:46:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=oID6UIM4D3jGL5kRo850ThGavJp9GzIe/Rvkp3KGMhE=; b=njwkC9Lv2TiyE/UEIs0o3v1w6FgYYq0rnWwlgTkvTZw/xi7JkRuRvuV/gtAsI1KInc NCKopJqv2iLY0AfcwV0Y/PfX9LKe+/RoW+SgFkWgVtWm5sfCqw8GPNxQMWfaz75Q0WTG kC2rR8znG9X4k60h0tiJ/OT7F6Z6cB+/iwuzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=KcAWr1UyTuLx3vag6TT4999JMbmzwsXEuPn1MnsCCQCXHI5YrKVbiuGX+bfmIeGZyh lNxnKtwIeowX/rVoCRMehQoE+1Y8yU5XlppRGI4XBRKccbqePwqBwnamgnfn1SE33soV J7Q0n5OjwiiCmKgOemUWy9/cVrAtC/aisw1K0= MIME-Version: 1.0 Received: by 10.204.103.132 with SMTP id k4mr1924060bko.28.1294533970575; Sat, 08 Jan 2011 16:46:10 -0800 (PST) Received: by 10.204.232.71 with HTTP; Sat, 8 Jan 2011 16:46:10 -0800 (PST) In-Reply-To: References: Date: Sat, 8 Jan 2011 16:46:10 -0800 Message-ID: From: John Floren To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Streaming 9P is out X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces@9fans.net Errors-To: 9fans-bounces@9fans.net X-GMX-Antivirus: 0 (no virus found) X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=5D7Q89H36p4U4jfdfC5HDevlx1X2sAZgAaLl3DbFfW0PXxL7WgvovMFXXSEPrACW/b9IW Qp+GhEViZlUW4mdBntgP1X8KwB5tjHCA/yxSZMu7BXBiPs3ujyaoi2xLHDqpg8dk65Dhpb3Lg0c1 iTjGg==V1; On Sat, Jan 8, 2011 at 4:31 PM, wrote: > the use of tcp to get flow control is an interesting idea. > > some remaks: > > the client only gets the dial string of a new tcp connection. =C2=A0an > attacker could guess the port numbers and take over the stream. =C2=A0or > the client might be delayed before it makes the dial() causing it to > get the wrong stream or some other random tcp connection at the same > port. > > the initial 9p channel might be encrypted (common when you use > cpu), but the stream data excapes as cleartext... compromising security. > I had thought about the security problem. I acknowledge that it's possible for an attacker to guess the port, but he has to guess in that small time frame between when the server opens the port and the client connects. I haven't heard of FTP having problems with that, though. And, of course, if you encrypt the streaming data, it doesn't matter if an attacker guesses the port. > on the implementation, the server might give the wrong ip address > (because he is behind some nat gateway) causing the dial to fail. i think > the stream() call should fallback to the original filedescriptor then. I had considered this case (the server doesn't know which IP to give) but managed to forget to include the simple check "did dial fail?" > why do we pass the offset and mode in the pstream syscall? =C2=A0devmnt > should know the current offset and mode from the Chan structure right? > > i think you could simplify the userspace interface a little bit > further. =C2=A0for example, i see no use for the Stream structure and > sread/swrite as they never fall back on the old filedescriptor and all > the decisions are already made in the stream() call (except the > isread check). > > what about this: > > newfd =3D stream(oldfd, ....); > > int > stream(int fd, vlong offset, char isread) > { > =C2=A0 =C2=A0 =C2=A0 =C2=A0for(;;){ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0char addr[Maxstrin= g]; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int r; > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if((r =3D pstream(= fd, addr, offset, isread)) < 0) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0break; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if(addr[0] =3D=3D = 0) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0break; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if((r =3D dial(add= r, 0, 0, 0)) < 0) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0break; > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return r; > =C2=A0 =C2=A0 =C2=A0 =C2=A0} > > =C2=A0 =C2=A0 =C2=A0 =C2=A0/* server doesnt support Tstream */ > =C2=A0 =C2=A0 =C2=A0 =C2=A0if((fd =3D dup(fd, -1)) >=3D 0) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0seek(fd, offset, 0= ); > =C2=A0 =C2=A0 =C2=A0 =C2=A0return fd; > } > This ought to work, but I wanted to establish a difference between regular fds, which you can read and write and seek and all that goodness, and streams, which are for reading OR writing sequentially. I also wanted to give an error if you tried to read from a write stream and vice versa; your stream() doesn't seem to do that. Like I said, it's not perfect, and there's probably a better way to do it. John --upas-deczmyjpchpcsoojpyakeljiva--