[stunnel-users] stunnel automatically listening to extra ports: BAD

Fri Jan 11 23:06:02 CET 2008

> [You forgot to cc: the list]

Oops sorry thanks... my other lists do that automatically :)

>> All this is in a *nix, right?

Yes. RHEL5.

> The following is an educated guess:
>
> Open connections are open file descriptors, and fork()/exec() do not
> close open file descriptors. Thus, stunnel is inheriting the open
> connection. And, since it knows nothing about it, it does not close it
> or anything like that. So it's not that it activelly listens on it,
> but only that it does not bother to stop. You might check this theory
> by trying to connect to the port *after* apache is shut down. If I'm
> right you should get no answer at all.

I don't know a lot about sockets programming, but I am not sure this  
makes sense... I don't WANT stunnel to stop listening to those ports;  
rather it shouldn't ever start. stunnel has a config file, so I'd  
expect it to only listen to the ports it was told to listen to, which  
is 4449.

I run lots of child processes from php and none of them end up  
listening to port 80/443 once the server exits.

Although, now that I think about it, I am not sure I daemonize any  
processes from a php script...

But still I think that stunnel is actively listening on these ports.  
Forked processed just don't inherit sockets from parents AFAIK....

> So, the solution is to have the file descriptors close when exec'ing
> stunnel. PHP or apache might have some option somewhere to do that
> (look for "close on exec" or something similarly named), but if not,
> you might have to write some sort of wrapper to do it. It's a messy
> thing, because AFAIK there's no clean way to do it short of
>
>  for (i = 0; i < [some-hopefuly-large-enough-value]; i++)
>   close(i);

Yeah that couldn't be a good idea...

I am open to using stunnel in a different way.

I suppose that I could just set it up in init.d to run on boot, but  
was hoping to not have to deal with another initd process for ease of  
management...

Thanks for any ideas.

Alan