On Mon, 2008-05-12 at 10:53 -0400, Stephen Smalley wrote:
On second thought is that even possible? As I recall selinux-policy-targeted rpm is installed about 128/129 packages when I do my livecd create. That means that we didn't even have an 'inside chroot' policy to check against for the vast majority of this operation. I'd assume that building the appropriete mock buildroot would have the same problem. Wonder how people would feel about really hacking up the buildroot creator to force install selinux stuff first and then run the full install transaction set....
For a normal install, anaconda has to set down an initial file contexts file and load a policy to get things started IIRC - otherwise rpm wouldn't be able to label the files it sets down prior to installing selinux-policy*.
It uses the policy from outside the chroot until things are put into the chroot. This "works" for the anaconda case as we don't really fully[1] support installing a different environment than what your install images are built with
Jeremy
[1] We've actually done a lot of work to make this more supported, but SELinux is actually now the big blocker that I know of due to this reasoning. At least for things which count as similar, for certain values of that.
Or disable context validation altogether in userspace in that instance.
Anyone have suggestions on how to go about this?
Absence of any /selinux/context at all should automatically do that.
Or create some kind of "identity" node in the selinuxfs filesystem that is transaction-based like the existing selinuxfs nodes and always returns whatever was written to it, then bind mount that on top of /selinux/context.
I did get that out of using a plain file and using O_TRUNC in libselinux eventually.
Yes, but I don't see how requiring the use of a hacked-up libselinux is any better or more workable.