On Thu, 2011-01-20 at 09:26 -0800, Matthew Hall wrote:
On Thu, Jan 20, 2011 at 06:16:16PM +0100, bugzilla@bugzilla.balabit.com wrote:
--- Comment #7 from Gergely Nagy <algernon@balabit.hu> 2011-01-20 18:16:16 --- Did some more research, and this is looking to be harder and harder without some kind of version sniffing.
Using a libcap that doesn't know a thing about CAP_SYSLOG, syslog-ng will abort on 'cap_syslog=ep' on startup, regardless of what kernel is running under it (tested with stock Debian Squeeze kernel, 2.6.32+patches, no CAP_SYSLOG; and with 2.6.38-rc1 with CAP_SYSLOG). Using a patched libcap that does know about CAP_SYSLOG will succeed, on both kernels, and even if I try to verify that the process has the flag I just set, it still returns true for both kernels, regardless whether they do support CAP_SYSLOG or not.
This looks rather hopeless to me, unfortunately.
You didn't clarify the cause of the abort. Perhaps something could be done to prevent the abort from occurring? If not I suppose you are hosed.
The abort can be worked around (though it wouldn't be trivial) and retried without cap_syslog, but that wouldn't solve anything: a patched libcap would still happily set it on kernels that don't support it. Even if an unpatched libcap would set it on 2.6.38, the best we could do this way is to set both. And that would be rather pointless, as the whole idea of CAP_SYSLOG is to replace CAP_SYS_ADMIN for this purpose.
Regarding the success in the patched library, you could figure out it didn't work by getting back an error when you open the syslog device, and then try again with the admin capability set, no?
That's one of the options I'm exploring. I'm not quite sure, though, if I'd be able to set CAP_SYSLOG at that point. -- |8]