On Tue, 2008-05-13 at 10:36 -0400, Eric Paris wrote:
I'm not sure you need anything there; as I've said, is_selinux_enabled() will just fall back to checking /proc/filesystems for selinuxfs as the authoritative indicator of whether or not SELinux is enabled.
But we have other problems without /selinux mounted inside the chroot (and this is without the rpm_execcon patch which I'm about to put in, does rpm statically or dynamically link?) :(
Looks like rpm and rpmi are dynamically linked. Don't know if there is a static version somewhere for bootstrapping.
New, Interesting and different at least:
Installing: selinux-policy ##################### [128/129] Installing: selinux-policy-targeted ##################### [129/129] libsemanage.dbase_llist_query: could not query record value libsepol.policydb_write: policy version 15 cannot support MLS
I assume this is because there isn't an selinux/policyvers?
Yes, but all of this flows from the fact that semodule/libsemanage are trying to actually load a new policy. Which they wouldn't if we completely faked that SELinux was disabled within the chroot by making a fake /proc/filesystems. But allegedly that breaks rpm? Which I don't fully understand as it should just check whether SELinux is enabled prior to chroot'ing and keep using that saved enabled status throughout IMHO. Or if you invoked semodule with -n it wouldn't try to reload.
If all else fails, I suppose you could create a /selinux/policyvers and /selinux/mls to try to appease it. And maybe still a /dev/null link as /selinux/load to appease policy load.
libsepol.policydb_to_image: could not compute policy length libsepol.policydb_to_image: could not create policy image SELinux: Could not downgrade policy file /etc/selinux/targeted/policy/policy.23, searching for an older version. SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.23: No such file or directory /usr/sbin/load_policy: Can't load policy: No such file or directory
Yes, trying to load policy is the root problem here. So ideally we'd just disable that altogether as above or failing that fake it as above.
ERROR:dbus.proxies:Introspect error on :1.3:/org/freedesktop/Hal/Manager: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
That might just be a bug in the host policy, not allowing something that ought to be allowed and that only happens to get triggered here.
/sbin/restorecon reset /dev/stderr context unconfined_u:object_r:file_t:s0->system_u:object_r:device_t:s0 /sbin/restorecon reset /dev/stdin context unconfined_u:object_r:file_t:s0->system_u:object_r:device_t:s0 /sbin/restorecon reset /dev/random context unconfined_u:object_r:file_t:s0->system_u:object_r:random_device_t:s0
That may make sense given that udev manages device node labels for us these days. But /dev/stderr is just a symlink to /proc/self/fd/2 anyway, right?
There were actually a whole lot less when the restorecon ran through (still a bunch but a lot less), so I think that part is better.
After the restorecon finished and before the e2fsck I got:
Only root can do that.
Anyone have ideas what that might have been?
mount would do that if it didn't think it was running as root.