Red Hat Bugzilla – Bug 201242
init only tries to load policy.n and policy.(n-1) before giving up
Last modified: 2007-04-18 13:46:54 EDT
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):
Steps to Reproduce:
1. Create a system that only has policy.N
2. Boot a kernel that reports (N+2) via /selinux/policyvers
init exits and the kernel panics
init keeps searching until it finds policy.N and loads it
(kernel provides full backward compatibility with all older versions back to
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 -
- 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
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.