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. -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
