Services that can start by default policy feedback

Till Maas opensource at
Mon Feb 28 17:41:53 UTC 2011

On Mon, Feb 28, 2011 at 02:03:26PM +0000, Matthew Garrett wrote:
> On Sun, Feb 27, 2011 at 11:13:44PM +0100, Till Maas wrote:
> > On Sun, Feb 27, 2011 at 07:21:30PM +0000, Matthew Garrett wrote:
> > > No, but it does mean that what you're proposing would involve adding 
> > > functionality to Anaconda. The current situation is that the services 
> > > that are started when the respective package is installed and the 
> > > services that are enabled by default by the Fedora installer *are* the 
> > > same.
> > 
> > You wrote that Anaconda already has the code to active services, so
> > there is no additional functionality needed. Only the list of services
> > to be enabled needs to be extended.
> Anaconda obviously has the code to activate services, given that you can 
> do so with Kickstart. But there's no mechanism for a set of packages to 
> be provided in order to allow a per-spin set of defaults. You'd need to 
> write code for parsing a configuration file of some description and 
> you'd need to provide a way to get those files into each spin's Anaconda 
> image. The multipathd case is one that's explicitly special-cased in the 
> storage code.

Afaik the spins are usually live images and use a kickstart file to
enable services. The services that are enabled after the installation
from a live images are afaik the same that are started when the live
image is booted. Therefore the configuration can take place in the
kickstart file that is used to create the live image. I am not sure
whether there are different spins that are not based on live images.

> > Nevertheless, this is a lot cleaner solution that having to recommend 
> > to users of Fedora to not install packages on systems on a network or 
> > with non-admin users logged in to avoid potential security risks 
> > because services might activate themselves.
> What's the policy you actually want here? If it's "Services shouldn't 
> start by default" then your solution obviously satisfies that, but if 
> it's "Packages should not install anything that runs with elevated 
> privileges unless the user explicitly enables them" then it doesn't.

Since we are discussing about services here, my proposal regards only
services. Nevertheless I would also like for cron jobs not to be
installed automatically with a package etc. Or what is the other
behaviour you are referring to? I guess in an optimal case yum would ask
users after a service or cron job has been installed, whether it should
be activated. And there were default settings for systems. Then a
unexperienced Desktop user can use the defaults the Desktop SIG
considers to be good, but advanced users can use their own or answer the
questions to yum manually.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : 

More information about the devel mailing list