On Thu, 2006-05-18 at 13:39 +0100, Paul Howarth wrote: > Paul Howarth wrote: > > Stephen Smalley wrote: > >> On Tue, 2006-05-16 at 17:33 +0100, Paul Howarth wrote: > >>> It contains a policy module, but the module only includes file contexts. > >> > >> Clarification: it is a policy package (.pp), but the policy package > >> only includes file contexts. The module itself is just the .mod file > >> created by checkmodule; it never includes file contexts. > > > > Ah, right, thanks for the clarification. > > > >> If this is going to be common, then semodule_package and libsemanage > >> need to allow for policy packages that have no policy module. > > Is the absence of a policy module the actual cause of this error? If so, > would having a "dummy" policy module that was effectively a no-op (e.g. > by including an allow rule that was already in the base policy) be a > usable workaround? No, per Chad (via private email), the problem you encountered was actually caused by an unintended side effect of the helpful policy_module() macro in refpolicy. Since that macro expands to include require statements for all kernel classes and permissions (so that the policy writer doesn't have to manually specify them for each kernel class and permission he uses), it unfortunately can pick up requires for new classes and permissions in the refpolicy on the build system that are not yet defined in the base policy on the target system (in your case, due to not having fully updated the target system). There are some changes in progress that should help with that problem. > Should this be bugzilla-ed? I suppose there are two separate issues here: - Avoiding unnecessary dependencies in policy modules on the build system's refpolicy (of which this is only one instance). There is already more general effort in progress to introduce real interfaces into the language and module format so that modules can be truly linked against the interfaces of the base policy on the target system. - Cleanly supporting policy packages that do not include a binary policy module in the tools (e.g. semodule_package) and libraries (e.g. libsemanage, libsepol), so that they can be used to ship just file contexts or other components. I don't know of any work in progress yet on that issue, so it may make sense to bugzilla it, although it is really an upstream issue, and there isn't presently an upstream bugzilla for selinux (just the mailing list). -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
