On Thu, 2008-05-15 at 14:36 -0400, Stephen Smalley wrote:
On Wed, 2008-05-14 at 16:38 -0400, Eric Paris wrote:
^M Installing: kbd ##################### [126/129] ^M Installing: kernel ##################### [127/129] ^M Installing: selinux-policy ##################### [128/129] ^M Installing: selinux-policy-targeted ##################### [129/129]
All of this still went smoothly...
libsemanage.dbase_llist_query: could not query record value
No idea where this is coming from
Maybe a table was empty. Might want to look under etc/selinux/targeted within the chroot.
Without any helpful input I've still been banging my head against this wall, cleaned up a bunch of stuff in how the livecd-tools make images, wrote some policy (going to need to redo it) and it seems like I'm building images at least now. Remember all of this is building F10 images on F10, I'm not trying to handle the 'illegal' context stuff at all, let just make that clear.
Anyway, I'm still getting a couple of ?error? messages
Installing: kbd ##################### [126/129] Installing: selinux-policy ##################### [127/129] Installing: selinux-policy-targeted ##################### [128/129] libsemanage.dbase_llist_query: could not query record value /usr/sbin/semanage: Invalid prefix user /usr/sbin/semanage: Invalid prefix user
Installing: kernel ##################### [129/129] Only root can do that. e2fsck 1.40.9 (27-Apr-2008) Pass 1: Checking inodes, blocks, and sizes
but I'm about to try to boot one of these things and see what happens. Anyone have hints on what to look for with the above error messages? As usual I don't know what a 'table' is in this context :)
The invalid prefix user is another artifact of semanage/seobject.py trying to check something against the host's policy rather than checking against the target policy just due to lack of adequate libsemanage interfaces. Calls to is_selinux_mls_enabled() and security_check_context() need to be turned into libsemanage calls.
The could not query record value one is too generic. Might help to get a snapshot of the /etc/selinux/targeted tree that it built and see what's there. Or possibly patching libsemanage to give more useful output, but it's a bit hard due to abstraction layers there.
BTW, are you doing all of this with the patch for rpm_execcon that I sent you? If so, I should likely commit that upstream.