Summary: | sys-apps/policycoreutils with dev-libs/libpcre-8.35 - segmentation fault in /usr/sbin/setfiles | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Lari Korpi <lari.korpi> |
Component: | SELinux | Assignee: | Sven Vermeulen (RETIRED) <swift> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gentoo-bugzilla, perfinion, quantheory, selinux |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | selinux-utils | ||
Package list: | Runtime testing required: | --- | |
Attachments: | upstream patch to include pcre version |
Description
Lari Korpi
2014-07-07 13:07:04 UTC
I can confirm I had the same issue with libpcre-8.35 Before: matchpathcon /etc/ /etc system_u:object_r:etc_t After: matchpathcon /etc/ /etc system_u:object_r:lib_t To get my system back to a usable state I needed to run: FEATURES=-selinux emerge -av =libpcre-8.33 then emerge -av =libpcre-8.33 I had the same issue. I had to mask =dev-libs/libpcre-8.35 and re-emerge libpcre with FEATURES="-selinux", then again normally, to get my system back on track. A workaround is to rebuild the *.bin files in /etc/selinux/*/contexts/files: ~# cd /etc/selinux/strict/contexts/files ~# rm *.bin ~# sefcontext_compile file_contexts ~# sefcontext_compile file_contexts.homedirs ~# sefcontext_compile file_contexts.local This isn't a good permanent solutino though, we need to find a way to either rebuild the *.bin files when libpcre does an update, patch userland so it ignores invalid *.bin files, remove *.bin files when libpcre updates, or something else. (In reply to Sven Vermeulen from comment #3) > A workaround is to rebuild the *.bin files in /etc/selinux/*/contexts/files: > > ~# cd /etc/selinux/strict/contexts/files > ~# rm *.bin > ~# sefcontext_compile file_contexts > ~# sefcontext_compile file_contexts.homedirs > ~# sefcontext_compile file_contexts.local > > This isn't a good permanent solutino though, we need to find a way to either > rebuild the *.bin files when libpcre does an update, patch userland so it > ignores invalid *.bin files, remove *.bin files when libpcre updates, or > something else. Is it possible to do those steps in pkg_postinst in the libpcre ebuild? It wouldn't be that pretty but it seems like it should work if pcre is the only package that causes the problem. If the .bin files are not required then the safest would be to only rm *.bin and force a rebuild of the package to rebuild. Let's ask ;) @base-system - one of SELinux' packages (selinux-base) compiles regular expressions into binary files for speed enhancements (which for gentoo don't give major benefit, but other distributions do). However, when libpcre is updated, it seems that this binary representation becomes invalid. The code doesn't like that, and segfaults. A workaround is to remove the binary compiled files when libpcre is updated, like in the pkg_postinst phase: if use selinux ; then rm -f /etc/selinux/*/contexts/files/file_contexts*.bin fi The SELinux userspace falls back to the non-compiled files then, and everything works. If we try to fix this elsewhere, we have the problem that /any/ package installation fails due to the segmentation fault. In the mean time I'm trying to figure out where the segfault occurs so the command can be caught and handled correctly... I managed to get a proper backtrace after rebuilding enough things with debugging symbols. I have the core file, should I upload it here? I am not sure yet if the bug is in libpcre or libselinux. I need to look more, but in the mean time here is the backtrace. I have backed up the .bin files from the old and new pcre versions and can reliably trigger the segfault by running: # setfiles -vF /etc/selinux/strict/contexts/files/file_contexts /home/jason/.config/libvirt/qemu/lib/ setfiles reset /home/jason/.config/libvirt/qemu/lib/ context staff_u:object_r:xdg_config_home_t->root:object_r:user_home_dir_t Segmentation fault (core dumped) It is segfaulting on this file: # ls -alZ /home/jason/.config/libvirt/qemu/lib/capabilities.monitor.sock srwxr-xr-x. 1 jason users staff_u:object_r:xdg_config_home_t 0 Mar 11 16:18 /home/jason/.config/libvirt/qemu/lib/capabilities.monitor.sock= (gdb) bt #0 0x00000309ecc210b9 in match_ref (offset=64000, eptr=0x3da93388ee5 "/jason/.config/libvirt/qemu/lib/capabilities.monitor.sock", length=-1, md=0x3da93388c10, caseless=0) at /var/tmp/portage/dev-libs/libpcre-8.35/work/pcre-8.35/pcre_exec.c:169 #1 0x00000309ecc283d2 in match (eptr=0x3da93388ee5 "/jason/.config/libvirt/qemu/lib/capabilities.monitor.sock", ecode=0x309eda9cedc <Address 0x309eda9cedc out of bounds>, mstart=0x3da93388ee5 "/jason/.config/libvirt/qemu/lib/capabilities.monitor.sock", offset_top=0, md=0x3da93388c10, eptrb=0x0, rdepth=0) at /var/tmp/portage/dev-libs/libpcre-8.35/work/pcre-8.35/pcre_exec.c:2751 #2 0x00000309ecc3b848 in pcre_exec (argument_re=0x309eda9ce2a, extra_data=0x309ed92a440, subject=0x3da93388ee5 "/jason/.config/libvirt/qemu/lib/capabilities.monitor.sock", length=57, start_offset=0, options=0, offsets=0x0, offsetcount=0) at /var/tmp/portage/dev-libs/libpcre-8.35/work/pcre-8.35/pcre_exec.c:6941 #3 0x00000309ed66380d in lookup (rec=0x33370282f0, key=0x3da93388ee0 "/home/jason/.config/libvirt/qemu/lib/capabilities.monitor.sock", type=49645) at label_file.c:645 #4 0x00000309ed65e339 in selabel_lookup_common (rec=0x33370282f0, translating=0, key=0x3da93388ee0 "/home/jason/.config/libvirt/qemu/lib/capabilities.monitor.sock", type=49645) at label.c:218 #5 0x00000309ed65e49b in selabel_lookup_raw (rec=0x33370282f0, con=0x3da93388f70, key=0x3da93388ee0 "/home/jason/.config/libvirt/qemu/lib/capabilities.monitor.sock", type=49645) at label.c:251 #6 0x0000003334ad94fc in match (name=0x3da93388ee0 "/home/jason/.config/libvirt/qemu/lib/capabilities.monitor.sock", sb=0x333704c0f0, con=0x3da93388f70) at restore.c:101 #7 0x0000003334ad95e6 in restore (ftsent=0x333704c060, recurse=1) at restore.c:109 #8 0x0000003334ad9d55 in apply_spec (ftsent=0x333704c060, recurse=1) at restore.c:289 #9 0x0000003334ad9f6b in process_one (name=0x3337028c30 "/home/jason/.config/libvirt/qemu/lib/", recurse_this_path=1) at restore.c:349 #10 0x0000003334ada215 in process_one_realpath (name=0x3337028c30 "/home/jason/.config/libvirt/qemu/lib/", recurse=1) at restore.c:409 #11 0x0000003334ada139 in process_glob (name=0x3da9338a67a "/home/jason/.config/libvirt/qemu/lib/", recurse=1) at restore.c:388 #12 0x0000003334ad90a5 in main (argc=4, argv=0x3da9338a3b8) at setfiles.c:439 Checking with upstream @ http://marc.info/?l=selinux&m=140491890602694&w=2 Reassigning; going to split this bug and create a separate one for libpcre and base-system. Created attachment 380502 [details, diff]
upstream patch to include pcre version
This patch provided by upstream adds in pcre version in the format.
The patch can be tested by placing it in /etc/portage/patches/sys-libs/libselinux (as we has epatch_user in our ebuilds). It does require that the *.bin files are once removed, I would add that to the libselinux ebuilds' pre_inst.
After exploring many options, I've decided to do with the following... 1. sys-libs/libselinux-2.3-r1 will be made available, which contains the upstream patch, and which will also recompile the *.bin files in /etc/selinux/*/contexts/files in the pkg_postinst() phase so that the old format (which might trigger segfaults) is no longer available on the system. 2. Post a message to SELinux users (blog-post and wiki) that the *.bin files can be removed to work around the failure currently. I decided not to update libpcre to remove the *.bin files (which was an option) because libpcre is already stabilized for most architectures (so would need a revision bump and again stabilization period) and it is a work-around. For stable users, the issue is already there. sys-libs/libselinux-2.3-r1 has been made available libselinux-2.2.2-r5 has the same fix & workaround in it. *** Bug 517284 has been marked as a duplicate of this bug. *** Bug 517284 mentions that a pcre upgrade after libselinux-2.2.2-r5 was installed still gave breakage. I'll check if the sefcontext_compile in libselinux is or isn't performed as that *should* have prevented the failure... Both 2.2.2-r5 and 2.3 have been stabilized. |