On 16/02/07, Shachar Shemesh <[EMAIL PROTECTED]> wrote:
Baruch Even wrote: > If it is a process parent/child pair then you could listen on the signal > SIGCHLD and when the child exits your process will be notified by the > kernel. Well, no. The most obvious programs that will be run through privbind are daemons. Those tend (I say "tend", but it's in the specs) to fork and exit parent as a first thing. Privbind will not be the parent of the actual process doing the binds.
Ah, so that's what the "daemon mode" switch is for. Will implement it to cleanly ignore SIGCHLD then. What I intended to do, before I totally ran out of time to work on it,
was to implement a switch saying "answer X bind requests and then exit".
Already implemented in my branch of the project. The assumption is that you know how many times daemon X uses privileged
bind throughout its lifetime.
Might be a good idea to add a "--verbose" mode to send notifications of bind calls to syslog, so you can learn the behaviour of new daemons.
You'll need to wait() on the child process in the signal handler > to reap the zombie child process. > Well, the idea is that a "recv" will terminate with no data and with errno set to "EINTR" if a signal, such as SIGCHLD, arrives. This means you can just call "recv", and if it fails, check the return code, and if it's "EINTR" check whether the child has exited.
As Baruch said - it's an opening for a race condition and I'm not sure what's the advantage of this over simply catching SIGCHLD (if not in daemon mode) and exiting on that. If in daemon mode then SOCK_STREAM or SOCK_PACKETSEQ solves the "connectivity" problem.
Baruch > Shachar
--Amos
