ZXFR

[Danny Mayer]

At 04:18 PM 11/9/00 +0000, Tomasz Lomotowski wrote:
>Danny Mayer <mayer at gis.net> wrote:
>
>> Probably the quickest way to do this is to remove gzip from 
>> your system. ZXFR requires gzip in order to work.
>> 				Danny
>
>Am I mistaken or gzip is one of commonly used compressors on unix-like
>systems? Happy hours without it. Could you tell me a bit more
>timeconsuming way?
>
	Yes, gzip is a commonly used compression utility.  However, the question was
  whether or not there was a way to get ZXFR to stop working and I supplied an
  answer that might work. I hadn't seen the bugtraq report.  The transfer
would still
  happen but the child process that gets spawned would be unable to gunzip
  the compressed file and would report a failure.

	The real problem according to the bugtraq report is that the ZXFR transfer is
  approved by named and it goes ahead and calls the transfer routines.
  Unfortunately, in this case, whoever built the software hadn't compiled
it to
  support ZXFR. The routine correctly reports that it's not supported, but
for some
  reason the cleanup piece causes the failure.  I'm not sure why.  There
are actually
  two problems here:
	1) If the code was not compiled to support ZXFR, then it should not have
approved
	    the transfer in the first place.
	2) the cleanup part shouldn't cause a failure.

	I understand that a 8.2.2-P7 will be available shortly to deal with this
problem
  properly.  The "workaround" is to recompile named with ZXFR support, by
defining
  the macro BIND_ZXFR.  I'm not sure what to do yet for WinNT systems which
don't
  usually support include compiled-in support for ZXFR.  I'll have to think
about that
  one.

			Danny