Article delegate-en/1207 of [1-5169] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
search
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
[Reference:<_A1204@delegate-en.ML_>]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: Portrange for passive FTP (not supported)
19 Jun 2001 06:23:33 GMT feedback@delegate.org (Yutaka Sato)


On 06/17/01(07:56) you dirk laurijssen <piucabdyi-dyd2yvga65xr.ml@ml.delegate.org> wrote
in <_A1204@delegate-en.ML_>
 |> Basically, FTP-DeleGate with -PX option (port number X for control
 |> connection) creates a data connection with a port number X-1.
 |> Thus it should be enough to open X and X-1 so that FTP-DeleGate can
 |> accepts those ports.
 |
 |What if the -PX is a range of ports? Will delegate still use the port
 |connected on by the client -1 to open a datachannel ?

What FTP-DeleGate does is getting the port number X of the current
control connection then making a data connection trying to bind it
to the port number X-1, in "src/inets.c:bind_ftp_data()".
Thus the answer can be yes, but it may not work because a connection
to the port number X from a client can be accepted by a FTP-DeleGate
as both control and data connection undeterministically.


 |>  |Currently the delegate (setupPASV in inets.c I believe)  doesn't support
 |>  |this, though it seems like an interesting feature to me.
 |>
 |> To tell the truth, there are at least two problems about the current
 |> implementation.   Firstly, DeleGate does not retry to get X-1 port when
 |> it failed to get it.  It can be a problem when used with a little heavy
 |> accesses.  Secondly, if the port number X of the control connection is
 |> privileged one, the FTP-DeleGate must run with OWNER=root to bind the
 |> data connection to X-1.
 |
 |If a process wants to use a lowport it has to be root, there is no way
 |besides that,

If DeleGate dynamically alternates its effective UID while keeping
its real UID as root, DeleGate can run with effective UID=root only
when it is necessary.  (But keeping real UID as root, i.e. leaving
root user's potential, can be dangerous...)

 |but isn't it feasible to have delegate check on the port-assigning,
 |like for instance first X-1, if this fails X-2, etc... ?

I think the very location appropriate to do such port-assinging is
the kernel of OS.  Extending bind() and accept() system call to ease
multi-ports handling will make application level proxies be more
efficient and increases what they can do.

Cheers,
Yutaka
--
  @ @ Yutaka Sato <y.sato@delegate.org> http://www.delegate.org/y.sato/
 ( - ) National Institute of Advanced Industrial Science and Technology (AIST)
_<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan

  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
@_@V