[syslog-ng] [Bug 108] 2.6.38+ will require CAP_SYSLOG (CAP_SYS_ADMIN not enough)

[bugzilla at bugzilla.balabit.com]

https://bugzilla.balabit.com/show_bug.cgi?id=108





--- Comment #17 from Gergely Nagy <algernon at 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.