I am somewhat reluctant to include such a patch, so you need external tools to actually set the fd up,
For me, the ability to use an external tool to create the socket is a benefit, not a burden. I do it even where there is no privilege separation issue, because I don't think individual servers should all duplicate the same common functions; I want to rely on syslog-ng to handle syslog and socketexec to handle setting up sockets.
and it does not handle reloads.
Yes, it's broken that way. And thanks for pointing it out, because it would have caused me grief. The fix looks simple enough, though: use dup() to provide syslog-ng something to close while the user's socket remains unmolested.
I would rather use some kind of dynamic capability management. (e.g. a minimal set of syslog-ng would run as root, while the actual message processing would happen in a restricted part.
That would close the window of vulnerability substantially, but is still in a different league from a program that you don't give privileges to at all. And it adds to syslog-ng the complexity of understanding the privilege system on whatever system it's running on. Not all of them do the classic uid zero/nonzero thing. (I have some that use Linux capabilities, and the program that execs syslog-ng knows what to do with them). -- Bryan Henderson San Jose, California