Description of problem: The FC4 init only tries to load policy.n and policy.(n-1) before giving up, so it will halt the system at boot (if enforcing) when updating to a kernel that supports a policy version that is 2 or more beyond the one that shipped in the distro release. There is a kernel patch pending that will cause users to hit that condition if/when they update to a kernel including that patch (likely 2.6.19). Version-Release number of selected component (if applicable): 2.85-39 How reproducible: Every time Steps to Reproduce: 1. Create a system that only has policy.N 2. Boot a kernel that reports (N+2) via /selinux/policyvers 3. Actual results: init exits and the kernel panics Expected results: init keeps searching until it finds policy.N and loads it (kernel provides full backward compatibility with all older versions back to Linux 2.6.0) Additional info:
Created attachment 133579 [details] patch to sysvinit to continue searching for older policy versions
Dave, are we going to get a kernel like this anytime soon? Note that FC4 is going to legacy RSN and won't get kernel updates.
Possibly it won't get kernel updates from RH, but users may still build newer kernels. The recent udev discussion - http://marc.theaimsgroup.com/?l=linux-kernel&m=115432571210598&w=2 - suggests that we can't just argue that it is a legacy distro and not supported. If we can get an update to init pushed well in advance of when 2.6.19 comes out, then most users will likely have already updated to it by then, or at least it will be available to them. The kernel itself is providing all the necessary compatibility support here; it is just init that is not trying hard enough. The same issue arose for FC3 with 2.6.14, and it also was just handled as a (soon to legacy, not supported) issue IIRC, which did break some FC3 users who were building their own kernel.org kernels.
Actually, that thread is about the kernel breaking userspace... taken at that level, the kernel change shouldn't break the policy loading. Of course, in this case the userspace is pretty dumb. 1) Can you compile the kernel to say 'support only policy version X'? 2) I'm assuming the libselinux policy loader in current distributions has this fixed?
1) Not presently w/o patching the definition of POLICYDB_VERSION_MAX. I suppose we could make that value configurable via kernel config option. 2) Yes, it is fixed in FC5 and going forward via the libselinux policy loader, which further takes advantage of newer libsepol interfaces (whereas the trivial patch for SysVinit that I attached to this bug doesn't rely on the newer libselinux or libsepol support).
Moving to legacy, I didn't get this ready in time - apologies.
Created attachment 133877 [details] kernel patch to make /selinux/policyvers configurable This is a kernel patch that I plan to upstream before the actual version change to make the version reported by /selinux/policyvers optionally configurable, so that it can be adjusted downward for legacy userland. Then one can build a kernel that reports 19 and keeps /sbin/init working for FC4. Might not be a bad idea to apply the sysvinit patch anyway just to make it more resilient, but up to whoever maintains it for legacy.
The kernel change in question was pushed into -mm and should go into 2.6.19 It still would be smart to make init a bit more intelligent, there will be a reasonable workaround from the kernel side of things to support this situation before it becomes a problem.
I'm going to close this as won't fix. People building their own kernels should be able to read the kconfig messages on how to avoid this issue.