addressing the limitations in privbind

[Amos S. <amo...@gm...>]

Hi,

I'm sick at home today so I though that I'll try to address the two
shortcomings of privbind that we are currently aware of:

1. multi-threading - maintain a mutex in a static variable in
libprivbind.c:bind , lock it just before the sendmsg() call and release it
right after the recv() call.
Possible enhancement - the default should be NOT to use the mutex (I expect
that most application won't call bind multiple times, let alone from
multiple threads). The user can enable the use of the mutex using a "-t"
(for "threading") option, the value of the flag will be passed through an
envariable.

2. SIGPIPE on -n: add a field to the reply that the helper process sends to
libprivbind - it could be a boolean field flagging whether the server is
going to shut down after this request. If the server indicated that it's
going to shutdown then the client can cleanly call master_cleanup. Maybe
it's worth for the helper to send the count of requests left before it'll
shut down, -1 to indicate that it never will. I can only see this is worthy
for debugging scenarios.

Also I'd like to raise (again) the issue of counting bind(2) calls - I have
a hunch that it'll be useful to count successful binds and ignore
unsuccessful ones, with an option for the user to override this. The
rational is that I'd suspect servers to repeat binding only if a bind call
has failed and they want to try another port or re-try the same port after a
while, but once the bind was sucessful they won't call bind(2) any more.

Any comments?

Cheers,

--Amos