https://bugzilla.balabit.com/show_bug.cgi?id=108 Gergely Nagy <algernon@balabit.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bazsi@balabit.hu |algernon@balabit.hu Status|REOPENED |ASSIGNED --- Comment #35 from Gergely Nagy <algernon@balabit.hu> 2011-09-25 13:52:12 --- Created an attachment (id=41) --> (https://bugzilla.balabit.com/attachment.cgi?id=41) Additional patch, for stricter checking Attached is a patch, that can be applied on top of the previous one: all it does is check whether libcap can parse cap_syslog, and if not, fall back to CAP_SYS_ADMIN. That's the best we can reasonably do, I believe. What this means, is that the previous patch, with this new one applied on top, should work as follows in the given situations: Compiled with sys/capability.h having CAP_SYSLOG ================================================ The binary will try to use CAP_SYSLOG, when possible, but fall back to CAP_SYS_ADMIN otherwise. This means that if the kernel supports CAP_SYSLOG, and the libcap library can parse the "cap_syslog" capability name, then syslog-ng will prefer CAP_SYSLOG. In any other case, it will fall back to CAP_SYS_ADMIN. Which means that it will work, no matter what. But if ran on a recent kernel, with an inadequate libcap library, it will print a warning to stderr during startup, and will also trigger the kernel warning (which is harmless). This cannot be avoided, except with upgrading libcap. Compiled with sys/capability.h NOT having CAP_SYSLOG ==================================================== The binary will assume that CAP_SYSLOG has the expected value, and will behave as described above. Provided that capability support is compiled in - if it isn't, syslog-ng will not fiddle with capabilities at all. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.