On Wed, 2007-12-05 at 15:35 -0500, Joshua Brindle wrote: > Stephen Smalley wrote: > > On Wed, 2007-12-05 at 15:16 -0500, Joshua Brindle wrote: > > > >> Stephen Smalley wrote: > >> > >>> On Wed, 2007-12-05 at 14:30 -0500, Todd Miller wrote: > >>> > >>>> Paul Moore wrote: > >>>> > >>>>> The discussion for this appears to have gone quiet (at least I > >>>>> haven't seen anything else on this list). Where do things currently > >>>>> stand? > >>>>> > >>>> At this point I'd be OK with requiring equivalence and throwing an error > >>>> otherwise. I do think that this will result in usability issues that we > >>>> will have to address once people start using the caps. However, with > >>>> only > >>>> a single cap defined so far it is not really possible to know how these > >>>> will end up being used. > >>>> > >>> We could try to come up with a solution at least for allowing clean > >>> upgrades from F8 (w/o any caps) to F9 (likely w/ peer cap defined) > >>> without requiring manual user intervention for dealing with local > >>> modules. > >>> > >>> > >> This was my exact objection to using an intersection or equivalence. IMO > >> it is incompatible to require all modules to be the same and to also > >> require upgrades to work without manual intervention. > >> > >> Do you still think unioning is wrong? > >> > > > > Yes, I'm still against (automatic, default) unioning of the capabilities > > by the linker - that is clearly not a safe default. semodule could > > possibly override that behavior based on an option though, at which > > point the %post scriptlet in the policy rpm could use that option if we > > wanted to force it w/o user intervention. > > > > > > And when a user installs a new module via audit2allow they have to know > to select --ignore-stuff-the-modules-say-and-do-something-else-anyway? I > don't like this idea either. Shrug. Then we'll just go with equivalence only, and the user will have to remove local modules before upgrade. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
