I am awful at bug reporting and I apologize if I violated some sort of guidelines doing this, I didn't get a chance to read them as I'm using links and am quite disoriented http://bpaste.net/show/189633/ IS AN EXACT CLONE OF THE ATTACHMENT. Only look at that bpaste if I'm too silly to make the attachment work appropriately, as I'm aware bpastes are temporary. If my attachment is butt, please somebody reply to this bug report with the contents of the bpaste for a more permanent report :) Running semanage on this machine (semanage, semanage --help, semanage login) with any arguments or no arguments will always output a stacktrace, stacktrace is included in attachment. emerge --info was deemed irrelevant and is NOT in the attachment, however more basic information is.
Created attachment 372828 [details] http://bpaste.net/raw/189633/ copy of referenced paste
Try to re-merge the relevant packages (libsemanage/policycoreutils/libsepol)? Use nm (or similar) to check if the libsepol library file has the symbol sepol_set_policydb.
0000000000002dd0 T sepol_set_policydb It is there. On IRC I was informed it was hidden, that might uh... Be an issue.
This is what I have: ~$ nm -D /lib64/libsepol.so.1 | grep sepol_set_policydb 000000000002b8f0 T sepol_set_policydb_from_file ~$ nm -D /usr/lib64/python2.7/site-packages/selinux/audit2why.so | grep sepol_set_policydb 000000000000d4c0 T sepol_set_policydb 000000000000d500 T sepol_set_policydb_from_file In libsepol-2.2, the sepol_set_policydb function is hidden: int hidden sepol_set_policydb(policydb_t * p) { policydb = p; return 0; } In libselinux' audit2why.c however, there is still a reference to sepol_set_policydb(). From my understanding, this shouldn't be happening anymore. I'll ask upstream for more info.
Upstream mail discussion: http://thread.gmane.org/gmane.comp.security.selinux/20327
So it seems that audit2why links statically with libsepol; can you check the age difference as well as symbols in libsepol.a? ~$ ls -l /usr/lib64/libsepol.a /lib64/libsepol.so.1 -rwxr-xr-x. 1 root root 305928 Dec 4 17:32 /lib64/libsepol.so.1 -rw-r--r--. 1 root root 574256 Dec 4 17:32 /usr/lib64/libsepol.a ~$ nm /usr/lib64/libsepol.a | grep sepol_set_policydb 0000000000002c40 T sepol_set_policydb 0000000000002c80 T sepol_set_policydb_from_file ~$ ls -l /usr/lib64/python2.7/site-packages/selinux/audit2why.so -rwxr-xr-x. 1 root root 232336 Mar 4 20:05 /usr/lib64/python2.7/site-packages/selinux/audit2why.so So in my case, audit2why.so is built after libsepol.a (see dates) and libsepol.a contains the sepol_set_policydb symbol (as the symbol is available for static linking).
The cause is the fix through bug 500674 where static linking of libsepol was removed in favor of dynamic linking, but the static linking is by design. Check if audit2why.so is dynamically linking with libsepol or not. It shouldn't. I've reverted this fix through libselinux-2.2.2-r4.
libselinux-2.2.2-r4 is now stable