[195] in Zephyr_Comments
security problems with XSETROOT and zmail
daemon@ATHENA.MIT.EDU (bjaspan@ATHENA.MIT.EDU)
Sat Apr 1 17:24:28 1989
From: <bjaspan@ATHENA.MIT.EDU>
Date: Sat, 1 Apr 89 17:24:07 EST
To: raeburn@ATHENA.MIT.EDU
Cc: zephyr-comments@ATHENA.MIT.EDU, jik@ATHENA.MIT.EDU, jh@ATHENA.MIT.EDU,
In-Reply-To: Ken Raeburn's message of Sat, 1 Apr 89 16:53:45 EST <8904012153.AA11421@PROMETHEUS.MIT.EDU>
>This is presumably not compatible with the XSETROOT stuff..
correct, completely incompatible. But then it has been shown that the current method is EXTREMELY dangerous... zmail
doesn't have that problem (it may have others, but I can't think of any.)
>I doubt it would scale well...
Here's how it works: when a connection is made with a zrecv, zsend forks a child that sends the file and then
dies. So, 1) there isn't a file descriptor overlap problem, but of course if the OS limit of requests comes
in to fast things will not work well, 2) the person running zsend can end up with LOTS of little zsends which
can drive the load way up. (I mentioned exactly this problem in the man page.)
So the answer is: yes, it will work for broadcast/subscription, albeit within limits. It puts the load on
the person doing the sending instead of the zephyr servers (which I consider a big plus, especially for things
like XSETROOT.)
By the way, there are options to zsend that control problem #2 listed above, such as how many requests will be
accepted, how long to wait before assuming no more are forthcoming, etc.
Barr3y
