Date: Sat, 7 Jun 2003 10:35:44 +0200 (CEST) From: Martin Blapp <mb@imp.ch> To: Mike Romberg <romberg@fsl.noaa.gov> Cc: freebsd-bugs@freebsd.org Subject: Re: rpc/svc_tcp.c (readtcp) calls svc_getreqset2 Message-ID: <20030607101200.W44942@cvs.imp.ch>
next in thread | raw e-mail | index | archive | help
Hi, Please write the next time to freebsd-questions@freebsd.org or freebsd-hackers@freebsd.org. This is definitly not a freebsd bug :) > I'm attempting to port some code to a mac running os x. From what I >have found on the net, it seems that os x uses a freebsd version of >the rpc libraries. I'm not sure if this is a bug or not. But it sure >readtcp has it's own select loop in it which can call >svc_getreqset2(). I think this was done for some kind of security >related problem (a DOS attack). Dawrin uses the ONC RPC version we have in FreeBSD 4. In FreeBSD 5 we use now TIRPC, which has now non-blocking behaviour, also to prevent some sort of DOS attack ( you can telnet to port 111 or the port used by your rpc server and deadlock it for 35 seconds each time with just two or three returns) >My application is an rpc server which is not threaded and is in no >way prepared to deal with serving multiple requests at the same time. >In fact it likes to dump core when this happens. The select loop in >my code calls svc_getreqset() to process file descriptors that are >ready. And then while doing the xdr processing for a single request, >readtcp() is calling svc_getreqset2() and starting the dispatching of >another request. This ends up causing my application to dump core >because it is in the middle of one transaction when another starts. > > As far as I know, an RPC implementation is not supposed to do this. >I'm wondering if there is some sort of workaround short of threading >my application (which would be a big change)? Or is this a known bug? Are you sure apple had this last fix in it's darwin codebase ? It really sounds like you ar hit by this old bug. Go and check ;-) http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/rpc/Attic/svc_tcp.c.diff?r1=1.18&r2=1.18.2.1 >We have been running this patch on a production NIS server for 2.5 weeks now. >Normally we would have ypserv die at least once a week, and often many times >a day. > >This patch treats and error from select as zeroing out the FD_SET to indicate >that no fds are ready for reading. This is safe because the rpc code >always re-inits the FDSET before calling select. --- src/lib/libc/rpc/Attic/svc_tcp.c 2000/01/27 23:06:41 1.18 +++ src/lib/libc/rpc/Attic/svc_tcp.c 2001/03/08 14:04:42 1.18.2.1 @@ -352,6 +352,7 @@ readtcp(xprt, buf, len) tv = delta; /* in case select() implements writeback */ switch (select(svc_maxfd + 1, fds, NULL, NULL, &tv)) { case -1: + FD_ZERO(fds); if (errno != EINTR) goto fatal_err; gettimeofday(&tmp1, NULL); Martin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030607101200.W44942>