[SOLVED] Portage not emerging after system update

[reb85]

Hello everybody,

I am running a Gentoo Hardened server, with PAX and SELinux (permissive mode).
A couple of days ago I performed a system upgrade by running emerge -avNDu world. Portage started emerging a set of about a hundred packages. It correctly emerge glibc, kernel-headers, gcc, coreutils, perl, and python. Right after correctly emerging libpcre, portage got unable to merge any additional package. Even trying to update gentoo-sources, for instance, resolves into an error.

The issue seems to be in the install phase, not in the compialtion phase.

Here enclosed an example of emerging gentoo-sources:

[perfinion]

Hi,

Did you recently switch to SELinux?
also, do you have install-xattr on your system by any chance? (qlist -Iv install-xattr)

can you try re-building the context files too:

[reb85]

Hello,

I do not have install-xattr installed.
Anyway, I ran the commands you suggested, and was able to correctly install gentoo-sources. I will now try with the other packages.

I read about sefcontext_compile. I suppose the error I got was related to the one reported here: http://blog.siphos.be/2013/07/rebuilding-selinux-contexts-with-sefcontext_compile/, but I do not fully understand the problem. May I ask you to elaborate on the issue? In particular, are you aware of any other situation/package that might get broken upon update?

By the way, no, I did not switch to SELinux recently. I think I started using it about 8 months ago, and made a couple of system updates before getting this problem.

Thank you for your help.

[Sven Vermeulen]

SELinux works with labels on all resources in order to enforce its policy. For files, those labels are put inside extended attributes of the file (i.e. on the file system). But labeling files requires some "knowledge" of which label to put on which file. For this, a file context "library" of sorts is maintained. This is the default_contexts file inside /etc/selinux/strict/contexts/files/ and it uses regular expressions to allow marking labels with a wide set of files without needing to iterate on each and every file that might ever exist.

Now, regular expression support can be implemented with a wide range of libraries. One of these is PCRE (Perl-Compatible Regular Expressions), provided through libpcre. The SELinux utilities use libpcre to match regular expressions with the real paths, but made a (silly or not) design mistake of optimizing the regular expressions by running them through libpcre, and then storing the memory buffers of the (compiled) regular expressions (by libpcre) on disk. These are the *.bin files inside /etc/selinux/strict/contexts/files/. Through the *.bin files, the SELinux tools just need to load those files back to memory and they have access to the regular expressions, all readily compiled.

That works fine, until libpcre is updated and has internally updated its memory structures. These internal structures are (boring for the outsider) things like switching from 32-bit integers to 64-bit integers, reshuffling variable orders, using unsigned characters instead of signed characters and what not. Basically code optimizations for libpcre. These changes however make the binary memory dumps invalid, because they were generated with the "old" libpcre, and are now loaded with the new libpcre.

The result is that libpcre tries to read what it considers to be its own memory, notices that it is corrupt, and segfaults.

For Gentoo (and Portage) this means that every operation related to (re)labeling files (which is something that happens either behind the scenes automatically, or is triggered during installations by Portage to make sure all files have the right label) results in a segmentation fault, and thus the installations fail.
_________________
Please add "[solved]" to the initial topic title when it is solved.

[Sven Vermeulen]

[reb85]

Thank you very much for the explanations.

Cheers!!!