On Fri, 2006-05-19 at 08:03 -0400, Stephen Smalley wrote: > 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. A possible workaround for that might be for a package to conflict with selinux-policy versions older than the one it was built against. Is there a convenient way of finding the selinux-policy version short of doing an rpm query? > > 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). OK I'll bugzilla it, but which component should I use? Paul. -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
