semanage dies whenever called, immediately, complains about sepol_set_policydb not existing in audit2why.so
I was informed emerge --info would be useless
Nevertheless basic info:
AMD64 PC x86_64 kernel running selinux and PaX
ACCEPT_KEYWORDS="amd64 ~amd64"
PYTHON_TARGETS="python2_7 python3_3"
USE_PYTHON="2.7 3.3"

Stacktrace caused by semanage:
550 Ti PC ~ # semanage
Traceback (most recent call last):
  File "/usr/lib/python-exec/python2.7/semanage", line 27, in <module>
    import seobject
  File "/usr/lib64/python2.7/site-packages/seobject.py", line 27, in <module>
    import sepolicy
  File "/usr/lib64/python2.7/site-packages/sepolicy/__init__.py", line 11, in <module>
    import sepolgen.interfaces as interfaces
  File "/usr/lib64/python2.7/site-packages/sepolgen/interfaces.py", line 24, in <module>
    import access
  File "/usr/lib64/python2.7/site-packages/sepolgen/access.py", line 35, in <module>
    from selinux import audit2why
ImportError: /usr/lib64/python2.7/site-packages/selinux/audit2why.so: undefined symbol: sepol_set_policydb

IRC Logs:
15:13 -!- Irssi: #gentoo-hardened: Total of 186 nicks [8 ops, 0 halfops, 37 voices, 141 normal]
15:13 -!- Channel #gentoo-hardened created Sun Nov 26 01:42:49 2006
15:13 -!- Irssi: Join to #gentoo-hardened was synced in 1 secs
15:13 < jokleinn> http://bpaste.net/show/189606/
15:13 < jokleinn> Still trying to resolve my issue :(
15:14 -!- vinky [~vinky@81-230-177-246-no98.tbcn.telia.com] has joined #gentoo-hardened
15:15 <@Zorry> SwifT: ^^
15:15 < jokleinn> That traceback is sprayed out whenever i use semanage
15:15 < jokleinn> even semanage --help
15:15 <@SwifT> my first guess would be that libsepol isn't built for python 2.7?
15:16 < jokleinn> I'll take a look
15:16 <@SwifT> but I'm in an online trustee meeting for the moment, so can't put all effort on it  yet
15:18 < jokleinn> libsepol-2.2 is built for python 2.7 and 3.3
15:18 -!- Praise [~Fat@unaffiliated/praise] has quit [Ping timeout: 240 seconds]
15:19 < jokleinn> SwifT: I appreciate the assistance though, I won't bother you at your meeting :)
15:20 <@SwifT> well, sepol_set_policydb should be provided by libsepol-2.2. Lemme quikcly check which lib it provides
15:21 <@SwifT> grep sepol_set_policydb /usr/lib64/libsepol.so gives a match here
15:21 <@SwifT> is that the case on your system as well?
15:21 < jokleinn> yes sir
15:21 -!- Kiju [kiju@unaffiliated/kiju] has joined #gentoo-hardened
15:22 < jokleinn> Want emerge --info?
15:22 <@SwifT> no, that wouldn't give anything useful afaik
15:22 <@SwifT> hmm
15:22 < jokleinn> k
15:22 <@SwifT> are you running with SELinux in enforcing mode?
15:22 < jokleinn> permissive
15:24 < jokleinn> could a selinux kernel option or having a selinux related package built with the audit use flag be causing this?
15:24 <@SwifT> anything in the audit logs? selinux  utilities are selinux-aware, so might already give issues even though it's not enforcing
15:25 <@SwifT> it's not really audit-realted... audit2why is a library to convert avc denials into "possible" policy rules
15:25 <@SwifT> we should try and figure out why it can't find the sepol_* symbol
15:26 <@SwifT> perhaps you can use strace to see if it loads the libsepol.so file (and if not, if it gives an error of any kind)?
15:27 < jokleinn> I've been following the selinux install guide and as such have not reached the configuration for audit logs (unless they're automatic) but /etc/init.d/auditd is running somehow
15:28 < jokleinn> I'm still at install 1b, and i need semanage to add a user to a selinux user
15:28 <@SwifT> audit config is automatic yes
15:28 < jokleinn> strace
15:28 < jokleinn> oops
15:29 < jokleinn> where would the default audit logs location be :)
15:29 < jokleinn> sorry for being a nerd and having no idea how to work selinux yet
15:29 <@SwifT> you say you're at 1b - where exactly?
15:29 < jokleinn> code listing 2.14
15:29 <@SwifT> 'cause 1b is the last "part"
15:29 < jokleinn> Define the Admintrator Accounts
15:30 <@SwifT> hmm
15:30 <@SwifT> if you switch to python 3.3, do you get the same issue?
15:30 < jokleinn> with eselect?
15:31 <@Zorry> yes
15:31 < jokleinn> I've already tried to do that, I've even recompiled for python 3.3 (portage tells me it's unsupported and won't let me go through)
15:31 < jokleinn> neither worked for self-explanatory reasons
15:31 <@SwifT> grrr
15:32 <@SwifT> okay - default audit logs -> /var/log/audit (you can query selinux logs through "ausearch -m avc -ts recent")
15:32 <@SwifT> and the strace stuff, is something like this: "strace -f -s 256 -o strace.log <command>" and wgetpaste strace.log
15:33 < jokleinn> gonna have to emerge whatever owns strace )I'm a big boy and can do that myself); audit logs are http://bpaste.net/show/189620/
15:33 < jokleinn> as far as i can tell unrelated
15:34 < jokleinn> wait nvm
15:34 < jokleinn> it's not letting it read the .so?
15:35 <@SwifT> dunno - that's not something I can say from the audit logs (those only speak about /etc/portage access, and they're allowed due to permissive anyway)
15:36 < jokleinn> alright
15:38 < jokleinn> sepol_set_policydb /is/ in the audit2why.so
15:38 < jokleinn> maybe the python script is using it wrong?
15:39 <@SwifT> the script should be alright
15:39 <@SwifT> audit2why.so refers to sepol_set_policydb; the definition of it should be in libsepol.so
15:40 <@SwifT> see if you can use the ~arch versions of libsepol/libsemanage
15:40 <@SwifT> there are a few fixes in there and I was about to stabilize those the next few days anyway
15:41 < jokleinn> I've been using the ~amd64's
15:41 < jokleinn> libsepol.so has sepol_set_policydb_from_file but not just sepol_set_policydb
15:43 <@SwifT> hmm, good catch
15:43 <@SwifT> looked over that, lemme see
15:44 < jokleinn> also libsepol latest (2.2) is stable, i don't see an ~amd64 anywhere :(
15:44 < jokleinn> is that in an overlay?
15:44 <@SwifT> looks like sepol_set_policydb is defined as "hidden"
15:44 <@SwifT> no, everything is in the tree - it could be that libsepol is fully stable
15:45 <@SwifT> it's mostly libselinux iirc that is ~arch (don't have the list at hand for the moment)
15:45 < jokleinn> how would one have sepol_set_policydb exposed
15:46 <@SwifT> perhaps we're looking into the wrong things - perhaps audit2why shouldn't be called to begin with?
15:47 < jokleinn> from selinux import audit2why
15:47 < jokleinn> second last import in the traceback
15:47 <@SwifT> yeah, and the entire backtrace are all basic imports
15:49 < jokleinn> update sepolgen?
15:50 < jokleinn> was worth a shot
15:50 <@SwifT> i have no idea
15:50 < jokleinn> this is pretty awful
15:50 < jokleinn> i haven't found a human on google with a similar error
15:51 <@SwifT> can you bug-report it for me? I'll probably need to dig through the code of libsemanage/policycoreutils/libsepol to find out all this
15:51 <@SwifT> might want to copy/paste this IRC convo in it as well ;)
15:51 <@SwifT> I need to go now again :(
15:51 < jokleinn> ok bye bb