https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #17 from Gergely Nagy <algernon@balabit.hu> 2011-02-22 15:40:20 --- (In reply to comment #16)
Hm.. could anyone come up with a patch that validates if libcap knows about CAP_SYSLOG (perhaps configure time should suffice), and if it does it either checks the sysctl file, or the behaviour at runtime and adapts syslog-ng accordingly?
There is no sysctl file, and I'm not even sure there will be, as some of the bigger names on the kernel list were quite against it. There's a whole lot of problems regarding CAP_SYSLOG and how libcap and capabilities work in general: - libcap supporting CAP_SYSLOG is binary compatible with libcap not supporting it. Thus, it is possible to run a syslog-ng compiled against a CAP_SYSLOG-enabled libcap on a system where libcap does not know about the flag. The problem is, that in the beginning, we set our initial flags with cap_from_text(), which does NOT know about CAP_SYSLOG if libcap is too old. Setting CAP_SYSLOG later, by its number is not an issue. - Even if libcap supports CAP_SYSLOG, that does not guarantee that the kernel does too.
I'd love to be prepared for a future kernel change and work with as less privileges as possible.
The best option would be to probe for CAP_SYSLOG at startup time, and use CAP_SYSLOG if it's sufficient. That solves all the problems with basing this around the libcap version. In the end, the best option would be to either require a recent libcap for compilation, or conditionally define CAP_SYSLOG, and then probe for the capability at startup time. I'll probably be able to come up with a patch that does this last suggestion. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.