[PATCH] build: allow configuring filter policy to be used in the init files

[Dan Williams]

On Wed, 2018-04-11 at 10:15 +0200, Aleksander Morgado wrote:
> On Wed, Apr 11, 2018 at 4:10 AM, Dan Williams <dcbw at redhat.com>
> wrote:
> > On Tue, 2018-04-10 at 15:08 +0200, Aleksander Morgado wrote:
> > > Distributions wanting to use a different filter policy than the
> > > DEFAULT one were advised to patch themselves the corresponding
> > > init
> > > files.
> > > 
> > > We now allow doing this directly at configure time by using a new
> > > `--with-filter-policy=[POLICY]' option that accepts one of
> > > "default",
> > > "strict", "paranoid" or "whitelist-only".
> > > 
> > > The suggested policy for standard distributions is "strict".
> > > ---
> > > 
> > > Hey,
> > > 
> > > Would this new configure switch be enough to avoid needing to
> > > patch
> > > the service file in each distribution?
> > 
> > So this would mostly work, except that if a specific user wants to
> > change their policy after install, they would now fail RPM
> > verification
> > because the systemd unit files are not config files.
> > 
> 
> Ohhh right
> 
> > What Fedora typically does here would be something like:
> > 
> > EnvironmentFile=/etc/sysconfig/ModemManager
> > Exec=/usr/sbin/ModemManager --filter-policy=$FILTER_POLICY
> > 
> > and then install an /etc/sysconfig/ModemManager with:
> > 
> > FILTER_POLICY=strict
> > 
> > and mark /etc/sysconfig/ModemManager as %config in the RPM.
> > 
> > That allows the user to change the policy from the distro default
> > via
> > /etc/sysconfig/ModemManager and still maintain package integrity
> > with
> > "rpm -V".
> > 
> > Obviously this doesn't work for the D-Bus service file, but I guess
> > we
> > could have a wrapper script that sources the env file and then runs
> > MM
> > with the right parameters.
> > 
> > Or, for a distro-independent solution, a real config file...
> > 
> 
> Maybe it's time we ship a config file? These different policy configs
> probably deserve it.
> What do others think?

Yeah, we probably should just do this.

Dan