[Bug 108] New: 2.6.38+ will require CAP_SYSLOG (CAP_SYS_ADMIN not enough)
https://bugzilla.balabit.com/show_bug.cgi?id=108 Summary: 2.6.38+ will require CAP_SYSLOG (CAP_SYS_ADMIN not enough) Product: syslog-ng Version: 3.2.x Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi@balabit.hu ReportedBy: arekm@maven.pl Type of the Report: enhancement Estimated Hours: 0.0 2.6.38+ kernels (linus git) reports: [ 9.890305] WARNING: at kernel/printk.c:430 do_syslog+0x427/0x452() [ 9.890318] Hardware name: 2764CTO [ 9.890320] Attempt to access syslog with CAP_SYS_ADMIN but no CAP_SYSLOG (deprecated and denied). when syslog tries to do syslogging. Additionally I'm geting: [root@t400 ~]# /usr/sbin/syslog-ng -f /etc/syslog-ng/syslog-ng.conf Error opening file for reading; filename='/proc/kmsg', error='Operation not permitted (1)' Error initializing source driver; source='s_sys', id='s_sys#0' Error initializing message pipeline; which likely is due to the same problem. Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=... -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #1 from Arkadiusz Miśkiewicz <arekm@maven.pl> 2011-01-19 18:17:40 --- Solution used in PLD/Linux: http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/syslog-ng/cap_syslog.patch -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
On Wed, Jan 19, 2011 at 06:17:40PM +0100, bugzilla@bugzilla.balabit.com wrote:
--- Comment #1 from Arkadiusz Miśkiewicz <arekm@maven.pl> 2011-01-19 18:17:40 --- Solution used in PLD/Linux: http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/syslog-ng/cap_syslog.patch
+ sscanf(uts.release, "%d.%d.%d", &x, &y, &z); + kernel_version = LINUX_VERSION(x, y, z); That patch is not resilient in format changes in the string. If I take stuff out or add weird stuff then *.scanf functions will corrupt the stack. It would be better to use a regex with capture groups and check for the right count of them, then pass that to the version macro. Matthew.
On Wed, 2011-01-19 at 09:35 -0800, Matthew Hall wrote:
On Wed, Jan 19, 2011 at 06:17:40PM +0100, bugzilla@bugzilla.balabit.com wrote:
--- Comment #1 from Arkadiusz Miśkiewicz <arekm@maven.pl> 2011-01-19 18:17:40 --- Solution used in PLD/Linux: http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/syslog-ng/cap_syslog.patch
+ sscanf(uts.release, "%d.%d.%d", &x, &y, &z); + kernel_version = LINUX_VERSION(x, y, z);
That patch is not resilient in format changes in the string.
If I take stuff out or add weird stuff then *.scanf functions will corrupt the stack.
It would be better to use a regex with capture groups and check for the right count of them, then pass that to the version macro.
I'd suggest another approach (though, I've yet to figure out if it is possible): try to detect whether CAP_SYSLOG is supported, and use it over CAP_SYS_ADMIN if it is, then fall back to CAP_SYS_ADMIN. This would have the advantage of not requiring kernel version sniffing, which can be misleading. My guess would be that if cap_set_proc() fails with CAP_SYSLOG set, then we can fall back to CAP_SYS_ADMIN. But like I said, this is unverified, untested, and so on. I just don't trust version sniffing in any shape or form. -- |8]
On Wed, Jan 19, 2011 at 06:57:15PM +0100, Gergely Nagy wrote:
On Wed, 2011-01-19 at 09:35 -0800, Matthew Hall wrote:
On Wed, Jan 19, 2011 at 06:17:40PM +0100, bugzilla@bugzilla.balabit.com wrote:
--- Comment #1 from Arkadiusz Miśkiewicz <arekm@maven.pl> 2011-01-19 18:17:40 --- Solution used in PLD/Linux: http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/syslog-ng/cap_syslog.patch
+ sscanf(uts.release, "%d.%d.%d", &x, &y, &z); + kernel_version = LINUX_VERSION(x, y, z);
That patch is not resilient in format changes in the string.
If I take stuff out or add weird stuff then *.scanf functions will corrupt the stack.
It would be better to use a regex with capture groups and check for the right count of them, then pass that to the version macro.
I'd suggest another approach (though, I've yet to figure out if it is possible): try to detect whether CAP_SYSLOG is supported, and use it over CAP_SYS_ADMIN if it is, then fall back to CAP_SYS_ADMIN.
This would have the advantage of not requiring kernel version sniffing, which can be misleading.
My guess would be that if cap_set_proc() fails with CAP_SYSLOG set, then we can fall back to CAP_SYS_ADMIN. But like I said, this is unverified, untested, and so on.
I just don't trust version sniffing in any shape or form.
Good point indeed. I didn't think about what happens when people like RH, Debian, or Ubuntu backport things. Better just to try it, and set errno. However what happens if the user space headers on a box are missing the CAP_SYSLOG macro but the kernel has a backport to support CAP_SYSLOG? Matthew.
Good point indeed.
I didn't think about what happens when people like RH, Debian, or Ubuntu backport things.
Better just to try it, and set errno.
However what happens if the user space headers on a box are missing the CAP_SYSLOG macro but the kernel has a backport to support CAP_SYSLOG?
From what I've seen elsewhere, '#define CAP_SYSLOG 34' (or whatever number the cap has) is the way to go.
-- |8]
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #2 from Gergely Nagy <algernon@balabit.hu> 2011-01-19 22:04:29 --- Created an attachment (id=34) --> (https://bugzilla.balabit.com/attachment.cgi?id=34) Untested patch that tries CAP_SYSLOG before CAP_SYS_ADMIN The attached patch attempts to set CAP_SYSLOG, and only sets CAP_SYS_ADMIN if that failed. While it hasn't been tested on 2.6.38, at least it doesn't seem to cause any ill side-effects on earlier kernels. Treat it as completely untested, though, just for safety's sake. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 Sujith <m.sujith@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.sujith@gmail.com --- Comment #3 from Sujith <m.sujith@gmail.com> 2011-01-20 09:22:34 --- The patch doesn't fix the issue, I applied this over syslog-ng v3.2 and tested with kernel v2.6.38-rc1. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #4 from Arkadiusz Miśkiewicz <arekm@maven.pl> 2011-01-20 09:29:48 --- First patch (pld) works here. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #5 from Sujith <m.sujith@gmail.com> 2011-01-20 09:58:16 --- Well the pld patch doesn't apply for v3.2, I think ? -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #6 from Arkadiusz Miśkiewicz <arekm@maven.pl> 2011-01-20 13:33:49 --- True. The bug exists in all syslog-ng version but I marked only last one in bugzilla version field. pld patch is for 3.0.9 actually. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 Gergely Nagy <algernon@balabit.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #34 is|0 |1 obsolete| | --- Comment #7 from Gergely Nagy <algernon@balabit.hu> 2011-01-20 18:16:16 --- (From update of attachment 34) 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. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
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. 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? Matthew.
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]
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #8 from Sujith <m.sujith@gmail.com> 2011-01-20 18:29:06 --- Yes indeed. It's unfortunate that a kernel upgrade should break userspace. Maybe this can be reported to lkml ? -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 Gergely Nagy <algernon@balabit.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |algernon@balabit.hu --- Comment #9 from Gergely Nagy <algernon@balabit.hu> 2011-01-20 18:35:23 --- There's still a few options I can explore. But if all else fails, I'll see if the people over at lkml can help. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #10 from Sujith <m.sujith@gmail.com> 2011-01-20 18:43:49 --- Sure, but users who can't update the userspace are left with a broken setup. They either have to wait for the distribution to fix it, or compile and install a package themselves. The kernel has a policy of not breaking existing userspace apps, such regressions are frowned upon. IMHO, this merits a revert of the the kernel commit that introduced this breakage. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 Balázs Németh <balazs.nemeth@balabit.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |balazs.nemeth@balabit.com --- Comment #11 from Balázs Németh <balazs.nemeth@balabit.com> 2011-02-02 09:29:51 --- Another patch for this issue can be found in Archlinux's bug system (https://bugs.archlinux.org/task/22555?getfile=6297) Fyi: I have found this reference in Gentoo's bug system here: https://bugs.gentoo.org/show_bug.cgi?id=352682 If this is not going to help anyway, then sorry for the noise. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #12 from Gergely Nagy <algernon@balabit.hu> 2011-02-02 10:54:27 --- (In reply to comment #11)
Another patch for this issue can be found in Archlinux's bug system (https://bugs.archlinux.org/task/22555?getfile=6297)
The ArchLinux patch is the same that I attached earlier here, and I'm not too happy with it for quite a few reasons.
Fyi: I have found this reference in Gentoo's bug system here: https://bugs.gentoo.org/show_bug.cgi?id=352682
If this is not going to help anyway, then sorry for the noise.
I'll post to LKML about the issue today (again), and having a few links to show that this is a real problem, experienced by multiple unrelated parties will certainly help the cause. Thanks for the links! -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #13 from Gergely Nagy <algernon@balabit.hu> 2011-02-03 17:06:44 --- Good news! It looks like this will be dealt with on kernel side: for 2.6.38, CAP_SYS_ADMIN will continue working, later on, a sysctl will be set, which controls whether we need CAP_SYSLOG or CAP_SYS_ADMIN, and that's reasonably easy to query, and adapt to. Once the kernel folk figure this out and the patch lands in the kernel, I will prepare a syslog-ng patch that checks the sysctl setting, and acts accordingly. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #14 from Gergely Nagy <algernon@balabit.hu> 2011-02-11 10:15:19 --- CAP_SYS_ADMIN will continue to work in the future, CAP_SYSLOG will be an alternative (ref.: https://lkml.org/lkml/2011/2/10/331). I think this bug can be safely closed, as 2.6.38 will not break syslog-ng. If we want to transition to CAP_SYSLOG at some point (which in my opinion, we should), a new bug can be opened, to start with a clean sheet. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #15 from Sujith <m.sujith@gmail.com> 2011-02-11 10:54:34 --- Glad to hear that userpace won't be broken after all. Thanks ! -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #16 from Balazs Scheidler <bazsi@balabit.hu> 2011-02-22 15:22:58 --- 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? I'd love to be prepared for a future kernel change and work with as less privileges as possible. Currently, CAP_SYS_ADMIN is enabled, which is a rather big capability. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
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.
https://bugzilla.balabit.com/show_bug.cgi?id=108 Matt Weatherford <mbw@u.washington.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mbw@u.washington.edu -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #18 from Matt Weatherford <mbw@u.washington.edu> 2011-06-11 22:21:42 --- My syslog-ng.conf file works perfectly on another Debian Squeeze system that is 32-bit and uses the standard linux kernel shipped with Squeeze. This system has a compiled 2.6.38-5 kernel. This is the error and backtrace I see in the dmesg: [2744459.505379] ------------[ cut here ]------------ [2744459.505391] WARNING: at kernel/printk.c:288 do_syslog+0x71/0x38c() [2744459.505393] Hardware name: IBM System x -[7870AC1]- [2744459.505394] Attempt to access syslog with CAP_SYS_ADMIN but no CAP_SYSLOG (deprecated). [2744459.505396] Modules linked in: ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs ext2 dm_mod joydev usbhid hid nfs lockd nfs_acl auth_rpcgss sunrpc ipv6 autofs4 ipmi_si ipmi_devintf ipmi_msghandler loop snd_pcm snd_timer snd i2c_i801 i2c_core evdev shpchp pci_hotplug soundcore snd_page_alloc processor button cdc_ether usbnet mii thermal_sys pcspkr tpm_tis tpm tpm_bios serio_raw sd_mod uhci_hcd mptsas mptscsih mptbase ehci_hcd bnx2 scsi_transport_sas scsi_mod usbcore be2net [last unloaded: scsi_wait_scan] [2744459.505432] Pid: 7947, comm: syslog-ng Not tainted 2.6.38.5 #3 [2744459.505433] Call Trace: [2744459.505438] [<c10310c4>] ? warn_slowpath_common+0x6a/0x7b [2744459.505440] [<c1031f73>] ? do_syslog+0x71/0x38c [2744459.505443] [<c103113b>] ? warn_slowpath_fmt+0x28/0x2c [2744459.505446] [<c1031f73>] ? do_syslog+0x71/0x38c [2744459.505453] [<c10f2f85>] ? kmsg_open+0x10/0x12 [2744459.505455] [<c10ebc33>] ? proc_reg_open+0x82/0xeb [2744459.505458] [<c10f2f64>] ? kmsg_release+0x0/0x11 [2744459.505463] [<c10b5726>] ? __dentry_open+0x136/0x211 [2744459.505465] [<c10b589b>] ? nameidata_to_filp+0x3a/0x45 [2744459.505467] [<c10ebbb1>] ? proc_reg_open+0x0/0xeb [2744459.505471] [<c10bf296>] ? finish_open+0x72/0xff [2744459.505474] [<c10c0dea>] ? do_filp_open+0x16c/0x54b [2744459.505477] [<c10b9a10>] ? cp_new_stat64+0xee/0x100 [2744459.505480] [<c10c87ee>] ? alloc_fd+0x4f/0xb1 [2744459.505483] [<c10b5515>] ? do_sys_open+0x41/0xbd [2744459.505485] [<c10b55d5>] ? sys_open+0x1e/0x23 [2744459.505491] [<c12b5cd1>] ? syscall_call+0x7/0xb [2744459.505493] ---[ end trace ac2802b879950ea6 ]--- -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 Christian Kujau <lists@nerdbynature.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lists@nerdbynature.de --- Comment #19 from Christian Kujau <lists@nerdbynature.de> 2011-06-12 05:07:55 --- Still there with syslog-ng v3.1.3 (compiled against libcap-2.19-3) and Linux 3.0-rc2, with the following, rather scary warning: Attempt to access syslog with CAP_SYS_ADMIN but no CAP_SYSLOG (deprecated). ------------[ cut here ]------------ WARNING: at /usr/local/src/linux-2.6-git/kernel/printk.c:322 Modules linked in: therm_adt746x aes_generic sd_mod firewire_sbp2 scsi_mod arc4 b43 mac80211 i2c_powermac cfg80211 NIP: c0034190 LR: c0034190 CTR: 00000000 REGS: eea07c80 TRAP: 0700 Not tainted (3.0.0-rc2-00251-g7f45e5c-dirty) MSR: 00029032 <EE,ME,CE,IR,DR> CR: 22082442 XER: 20000000 TASK = ef2fd1d0[1444] 'syslog-ng' THREAD: eea06000 GPR00: c0034190 eea07d30 ef2fd1d0 0000005e 00000001 c00331d4 00000000 00000002 GPR08: 00000000 ef2fd1d0 c005b278 00000001 48082428 100653a0 00000000 10016228 GPR16: ffffffff 10004e68 00000000 00000000 00000000 ffffffe9 00000000 00000000 GPR24: 107f2144 c0126524 eef543c0 c0126558 00000000 00000000 c057bd78 00000001 NIP [c0034190] do_syslog+0x11c/0x638 LR [c0034190] do_syslog+0x11c/0x638 Call Trace: [eea07d30] [c0034190] do_syslog+0x11c/0x638 (unreliable) [eea07d90] [c0126578] kmsg_open+0x20/0x30 [eea07da0] [c01198c8] proc_reg_open+0xac/0x190 [eea07dd0] [c00c310c] __dentry_open+0x158/0x2bc [eea07df0] [c00d4520] do_last+0x1d8/0x724 [eea07e30] [c00d5b90] path_openat+0xe4/0x410 [eea07e90] [c00d5fdc] do_filp_open+0x44/0xb0 [eea07f10] [c00c2ea8] do_sys_open+0x104/0x1e8 [eea07f40] [c0012214] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xfacd008 LR = 0xfaccfb8 Instruction dump: 3bc0ffff 4800af39 2f830000 41beff74 3fc0c058 3bdebd78 881e04b8 2f800001 419eff54 3c60c04b 38638a24 483cccd9 <0fe00000> 38000001 981e04b8 4bffff38 ---[ end trace 5166675c35e74c71 ]--- -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 Matthias Runge <mrunge@fedoraproject.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrunge@fedoraproject.org --- Comment #20 from Matthias Runge <mrunge@fedoraproject.org> 2011-07-03 21:20:31 --- Whats the status of this ticket? There is an updated version of syslog-ng-3.2.4 for fedora 15 using --enable-linux-caps https://admin.fedoraproject.org/updates/syslog-ng-3.2.4-6.fc15 It could be installed on fedora-15 using yum --enablerepo=updates-testing install syslog-ng (or using update instead of install, when syslog-ng is already installed) -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #21 from Gergely Nagy <algernon@balabit.hu> 2011-07-03 21:36:51 --- Created an attachment (id=39) --> (https://bugzilla.balabit.com/attachment.cgi?id=39) Fix backported to 3.2. It's fixed in the 3.3 (and 3.4) tree: http://git.balabit.hu/?p=bazsi/syslog-ng-3.3.git;a=commitdiff;h=a0f212f3c97e... I backported it to 3.2, the (untested) patch is attached. It is also available from the bz/108/cap_syslog branch of my syslog-ng 3.2 git repo: http://git.balabit.hu/?p=algernon/syslog-ng-3.2.git;a=shortlog;h=bz/108/cap_... -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 Jose Oliveira <jpo@di.uminho.pt> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jpo@di.uminho.pt --- Comment #22 from Jose Oliveira <jpo@di.uminho.pt> 2011-07-04 06:39:45 --- (In reply to comment #21)
Created an attachment (id=39) --> (https://bugzilla.balabit.com/attachment.cgi?id=39) [details] Fix backported to 3.2.
---[snip]---
I backported it to 3.2, the (untested) patch is attached. It is also available from the bz/108/cap_syslog branch of my syslog-ng 3.2 git repo: http://git.balabit.hu/?p=algernon/syslog-ng-3.2.git;a=shortlog;h=bz/108/cap_...
Gergely, The above syslog-ng 3.2 patch still has problems. In Fedora 15 systems the daemon fails to restart (RPM upgrade) and manually starting it produces the following error: -------- syslog-ng: Error parsing capabilities: cap_net_bind_service,cap_net_broadcast,cap_net_raw,\ cap_dac_read_search,cap_dac_override,cap_chown,cap_fowner=p cap_syslog=ep -------- Regards, jpo -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #23 from Gergely Nagy <algernon@balabit.hu> 2011-07-04 08:21:46 --- (In reply to comment #22)
(In reply to comment #21)
Created an attachment (id=39) --> (https://bugzilla.balabit.com/attachment.cgi?id=39) [details] [details] Fix backported to 3.2.
---[snip]---
I backported it to 3.2, the (untested) patch is attached. It is also available from the bz/108/cap_syslog branch of my syslog-ng 3.2 git repo: http://git.balabit.hu/?p=algernon/syslog-ng-3.2.git;a=shortlog;h=bz/108/cap_...
Gergely,
The above syslog-ng 3.2 patch still has problems. In Fedora 15 systems the daemon fails to restart (RPM upgrade) and manually starting it produces the following error: -------- syslog-ng: Error parsing capabilities: cap_net_bind_service,cap_net_broadcast,cap_net_raw,\ cap_dac_read_search,cap_dac_override,cap_chown,cap_fowner=p cap_syslog=ep --------
Interesting... That suggest it doesn't recognise cap_syslog=ep, which is weird. I'll see what I can do. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #24 from Gergely Nagy <algernon@balabit.hu> 2011-07-08 12:36:31 --- (In reply to comment #23)
(In reply to comment #22)
(In reply to comment #21)
Created an attachment (id=39) --> (https://bugzilla.balabit.com/attachment.cgi?id=39) [details] [details] [details] Fix backported to 3.2.
---[snip]---
I backported it to 3.2, the (untested) patch is attached. It is also available from the bz/108/cap_syslog branch of my syslog-ng 3.2 git repo: http://git.balabit.hu/?p=algernon/syslog-ng-3.2.git;a=shortlog;h=bz/108/cap_...
Gergely,
The above syslog-ng 3.2 patch still has problems. In Fedora 15 systems the daemon fails to restart (RPM upgrade) and manually starting it produces the following error: -------- syslog-ng: Error parsing capabilities: cap_net_bind_service,cap_net_broadcast,cap_net_raw,\ cap_dac_read_search,cap_dac_override,cap_chown,cap_fowner=p cap_syslog=ep --------
There's something broken on Fedora, I believe. Including <sys/capability.h> results in CAP_SYSLOG being defined, the kernel knows it too, so g_process_check_cap_syslog() will return TRUE, and we assume that libcap knows about the capability aswell (since sys/capability.h belongs to libcap-devel). But it doesn't. Fedora seems to have libcap 2.17, while CAP_SYSLOG was introduced in 2.20. And there's a discrepancy between the headers (which suggest CAP_SYSLOG is supported) and libcap. I can modify the patch to fall back to cap_sys_admin=ep in case libcap does not support cap_syslog, but then we'd get the kernel warning again. The proper course of action would be to fix Fedora: either by upgrading libcap, or fixing the headers to not define CAP_SYSLOG (but then we're back to kernel warnings...). In any case, in an up-to-date environment, where both the kernel and libcap support cap_syslog, my backport works. But if libcap doesn't support it, there's nothing syslog-ng can do. To reiterate: the patch can handle the case where syslog-ng is compiled against a libcap that has cap_syslog, and ran on a kernel that doesn't, it can properly fall back to cap_sys_admin if libcap doesn't support it (and it doesn't lie), even if the kernel does. But it can't possibly handle the case where sys/capability.h tells us it's supported, the kernel knows about it, but the libcap library doesn't. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #25 from Matthias Runge <mrunge@fedoraproject.org> 2011-07-08 12:40:47 --- (In reply to comment #24)
There's something broken on Fedora, I believe. Including <sys/capability.h> results in CAP_SYSLOG being defined, the kernel knows it too, so g_process_check_cap_syslog() will return TRUE, and we assume that libcap knows about the capability aswell (since sys/capability.h belongs to libcap-devel).
But it doesn't. Fedora seems to have libcap 2.17, while CAP_SYSLOG was introduced in 2.20. And there's a discrepancy between the headers (which suggest CAP_SYSLOG is supported) and libcap. I can modify the patch to fall back to cap_sys_admin=ep in case libcap does not support cap_syslog, but then we'd get the kernel warning again.
Yeah, I've just found fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=689752 (about libcap version 2.20 released)
The proper course of action would be to fix Fedora: either by upgrading libcap, or fixing the headers to not define CAP_SYSLOG (but then we're back to kernel warnings...).
In any case, in an up-to-date environment, where both the kernel and libcap support cap_syslog, my backport works. But if libcap doesn't support it, there's nothing syslog-ng can do.
I understand. Thank you. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 Balazs Scheidler <bazsi@balabit.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution| |FIXED Status|NEW |RESOLVED --- Comment #26 from Balazs Scheidler <bazsi@balabit.hu> 2011-07-14 13:22:35 --- The backport integrated to 3.2/master. Thanks Gergely. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 Matthias Runge <mrunge@fedoraproject.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED | Status|RESOLVED |REOPENED --- Comment #27 from Matthias Runge <mrunge@fedoraproject.org> 2011-07-15 09:09:23 --- (In reply to comment #26)
The backport integrated to 3.2/master.
Thanks Gergely.
Applying above patch to my fedora build results in [root@mrungexp ~]# syslog-ng syslog-ng: Error parsing capabilities: cap_net_bind_service,cap_net_broadcast,cap_net_raw,cap_dac_read_search,cap_dac_override,cap_chown,cap_fowner=p cap_syslog=ep rpm -q libcap libcap-2.17-2.fc15.x86_64 I know, this version is outdated.... syslog-ng without this patch starts fine... -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #28 from Gergely Nagy <algernon@balabit.hu> 2011-07-15 10:11:04 --- (In reply to comment #27)
(In reply to comment #26)
The backport integrated to 3.2/master.
Thanks Gergely.
Applying above patch to my fedora build results in
[root@mrungexp ~]# syslog-ng syslog-ng: Error parsing capabilities: cap_net_bind_service,cap_net_broadcast,cap_net_raw,cap_dac_read_search,cap_dac_override,cap_chown,cap_fowner=p cap_syslog=ep
rpm -q libcap libcap-2.17-2.fc15.x86_64
I know, this version is outdated....
syslog-ng without this patch starts fine...
That's expected. The patch assumes that libcap's version and <sys/capability.h> are in sync, which on Fedora, they're not. The workaround is to disable capabilities until libcap is upgraded to a newer version. Alternatively, I can prepare a patch that falls back to CAP_SYS_ADMIN in this case, but that'll result in a kernel warning, and we're back to square one. There's already a bug filed at redhat's bugzilla to include a newer libcap: https://bugzilla.redhat.com/show_bug.cgi?id=689752 -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #29 from Matthias Runge <mrunge@fedoraproject.org> 2011-07-15 11:17:39 --- (In reply to comment #28)
syslog-ng without this patch starts fine...
That's expected. The patch assumes that libcap's version and <sys/capability.h> are in sync, which on Fedora, they're not. The workaround is to disable capabilities until libcap is upgraded to a newer version.
Ok, thanks for the clarification. I'll remove capabilities until libcap is upgraded.
Alternatively, I can prepare a patch that falls back to CAP_SYS_ADMIN in this case, but that'll result in a kernel warning, and we're back to square one.
no, we should get this fixed in fedora.
There's already a bug filed at redhat's bugzilla to include a newer libcap: https://bugzilla.redhat.com/show_bug.cgi?id=689752
-- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #30 from Jose Oliveira <jpo@di.uminho.pt> 2011-08-07 03:55:49 --- Gergely, We finally managed to get libcap updated to version 2.22 in Fedora 15 (actually for every Fedora version >= 14) but I'm still seeing the same problem that I reported in comment #22. Could you give it another look? Thanks in advance, jpo PS - More info: https://bugzilla.redhat.com/show_bug.cgi?id=718439 (comments >= 5) -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #31 from Arkadiusz Miśkiewicz <arekm@maven.pl> 2011-09-10 19:43:32 --- One small note. ret = prctl(PR_CAPBSET_READ, CAP_SYSLOG); approach for detection will fail on vserver patched kernel. vserver patch (for 2.6.35 as example) used the same capability number as CAP_SYSLOG uses now thus test above will think CAP_SYSLOG is available while in reality some vserver CAP was tested. PLD uses this additional patch as workaround: http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/syslog-ng/cap_syslog-vserve... -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #32 from Gergely Nagy <algernon@balabit.hu> 2011-09-10 20:13:44 ---
We finally managed to get libcap updated to version 2.22 in Fedora 15 (actually for every Fedora version >= 14) but I'm still seeing the same problem that I reported in comment #22.
Could you give it another look?
Sorry for the long response time, I only just managed to get back to this issue. I'm now running a 3.0.0 kernel, with CAP_SYSLOG and all that, and I can't reproduce the problem. If I downgrade my kernel, that's still detected correctly, and syslog-ng falls back to CAP_SYS_ADMIN. I'll see if I can try again on a Fedora system sometime soon, but can't promise anything, I'm afraid. (In reply to comment #31)
One small note.
ret = prctl(PR_CAPBSET_READ, CAP_SYSLOG);
approach for detection will fail on vserver patched kernel. vserver patch (for 2.6.35 as example) used the same capability number as CAP_SYSLOG uses now thus test above will think CAP_SYSLOG is available while in reality some vserver CAP was tested.
PLD uses this additional patch as workaround: http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/syslog-ng/cap_syslog-vserve...
Version sniffing is something I hate, with a passion. I'd rather teach the init script (if possible) to detect vserver, and either disable capabilities, or override the caps on the command line. I'm not quite sure if that'd work, but I'd rather make capability overrides from the commandline work properly, than use version sniffing. One issue with version sniffing is, that if the kernel begins to use a two part version (which as far as I understand, is still something they want to do), the parsing will fail, and syslog-ng will end up trying to use CAP_SYS_ADMIN and trigger the kernel warning. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #33 from Arkadiusz Miśkiewicz <arekm@maven.pl> 2011-09-10 20:27:09 ---
PLD uses this additional patch as workaround: http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/syslog-ng/cap_syslog-vserve...
Version sniffing is something I hate.
Well, version checking in *.c or init script is still version checking (especially if you can't detect vserver in reliable way).
One issue with version sniffing is, that if the kernel begins to use a two part version
It will work fine with this patch even for 2 part kernel version. Anyway this patch isn't intended for upstream. It's just a reference for other people with this issue. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 --- Comment #34 from Gergely Nagy <algernon@balabit.hu> 2011-09-10 20:33:39 --- (In reply to comment #33)
PLD uses this additional patch as workaround: http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/syslog-ng/cap_syslog-vserve...
Version sniffing is something I hate.
Well, version checking in *.c or init script is still version checking (especially if you can't detect vserver in reliable way).
I was thinking more along the lines of detecting vserver, without version sniffing. But alas, if it cannot be reliably detected, then your patch is probably the easiest route.
One issue with version sniffing is, that if the kernel begins to use a two part version
It will work fine with this patch even for 2 part kernel version.
Right, my bad. I misread the if. Sorry!
Anyway this patch isn't intended for upstream. It's just a reference for other people with this issue.
It *might* be worthy of upstream inclusion. I suppose there's a reasonable number of people using the vserver patch, where the CAP_SYSLOG detection will fail. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=108 Balázs Németh <balazs.nemeth@balabit.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|balazs.nemeth@balabit.com | -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
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.
https://bugzilla.balabit.com/show_bug.cgi?id=108 Balazs Scheidler <bazsi@balabit.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bazsi@balabit.hu Resolution| |FIXED Status|ASSIGNED |RESOLVED --- Comment #36 from Balazs Scheidler <bazsi@balabit.hu> 2011-10-23 09:20:21 --- I've applied the patch in this bugreport, closing. commit 5afe42abe1be685a4714c691b277c24617438578 Author: Gergely Nagy <algernon@balabit.hu> Date: Sun Sep 25 13:43:33 2011 +0200 gprocess: Implement stricter CAP_SYSLOG checking. Some distributions ship libcap with headers generated from the kernel sources, instead of the headers of libcap itself, resulting in the headers and the library diagreeing about what capabilities are supported. For this reason, before deciding whether CAP_SYSLOG is supported, verify that libcap can actually parse it, and fall back to CAP_SYS_ADMIN if it can't. The benefit of this is that even if ran on such a system, syslog-ng will still continue to work (albeit triggering a kernel warning) instead of terminating. Signed-off-by: Gergely Nagy <algernon@balabit.hu> -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (3)
-
bugzilla＠bugzilla.balabit.com
-
Gergely Nagy
-
Matthew Hall