[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Security policy oversight needed?



On Thu, 2009-11-19 at 09:14 -0500, Owen Taylor wrote:
> This idea comes up a lot - that we can make Fedora packages be
> uncontroversial raw material, and then make the hard decisions at the
> spin level. (I'm speaking more generally than this particular issue.)
> 
> It doesn't work practically: configuration for packages needs to live
> with the package. Putting gigantic amounts of configuration into the 
> %post of a kickstart file quickly becomes unmanageable. And the idea
> that we make configuration changes in the %post of the kickstart really
> falls part badly once people start upgrading their install to the next
> version of Fedora.

For the particular issue of PolicyKit policy there is no reason at all
not to have the entire policy (for the entire system) in one package per
spin.  The design of PolicyKit 1.0 makes this really easy.

> It doesn't work statistically: people in general don't get upset about
> decisions made about the desktop because they aren't using a desktop.
> They get upset because they *are* using a desktop and have a different
> vision for that detail.

This is one of the reasons I think policies each need to be handled
centrally, each with a specific documented goal.

> It doesn't work out conceptually: you can't escape having to make
> decisions. If the only vision we have is how the Desktop spin works,
> then what policy goes into the package?

The packages should ship with a "multi-user server"-type policy, i.e. a
restrictive one -- this could even be set out in the packaging
guidelines if need be.

> Practically speaking it will be
> the configuration that was designed for the desktop spin, with various
> random changes and missing pieces where people yelled a lot on
> fedora-devel-list. That's not a coherent operating system. (And it's a
> bad basis for spins other than the Desktop spin.)

Each of the policy packages should override all of the available policy,
IMHO.

Tim.
*/

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]