Re: misc/18947 (ftpd lacks a per host limit of simultaneous connections)

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

The following reply was made to PR misc/18947; it has been noted by GNATS.

From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: misc/18947 (ftpd lacks a per host limit of simultaneous
 connections)
Date: Sun, 14 Mar 2010 17:24:59 -0400

 Since I implemented such a limit system on a few daemons in the past, I
 took a brief look at the ftpd code.
 
 In the code I previously adapted to support such limits, only daemon
 mode was supported and as such it was easy to use a global shared hash
 table in a MAP_ANON region along with flock(2).  Other cases were
 multithreaded so it was even easier.
 
 Allowing inetd introduces performance penalties and complexity for this
 scenario, I think.  From what I see, the current per-class connections
 limits is calculated via count_users() which actually uses a file of
 PIDs.
 
 Following a similar route, I guess that it'd be possible (and
 simplest), to implement per-address limits using a file as well, using
 dbopen(3)/hash(3) to store per-address information such as a
 connection/refcount.  Alternatively, instead of only storing the pid_t
 in the pids file, it'd be possible to store pid_t+address but running
 through the set testing for every match would be suboptimal.
 
 Other alternatives would be using a second mmap(2)d shared file
 implementing a hash table, or sysvipc, but I doubt that this would
 really be better than bdb for real use, and it would be more complex to
 implement, some code actually duplicating what bdb might be doing.
 
 Apart from chosing the way this hash table should be stored and
 accessed, since ftpd supports several address families, I think that
 some address-family specific code will have to be used, because the
 address size is different for each family, and this is what we should
 be hashing.  It'd also be possible to serialize the address to string
 before hashing using inet_ntop(3) or equivalent, costing a few more
 cycles...
 
 In a better world, it'd probably be possible to adapt all local daemons
 to support such policies by sharing a lightweight database daemon
 replacing or supplementing utmp and allowing sophisticated and
 efficient user WHO queries, internally using a library with a decent C
 API to also do queries from C... :)  But we don't currenty have this.
 -- 
 Matt