[SSSD] [INI] Ding-lIbs - Merging Configuration Snippets Installed in Different Locations (Design page)

Simo Sorce simo at redhat.com
Sun Apr 6 04:11:08 UTC 2014


On Fri, 2014-04-04 at 18:25 -0400, Dmitri Pal wrote:
> Ah you mean the two conditions:
> 
> - all files must start with a valid section header, i.e. each file has
>    to be valid ini file
> - duplicated section names are not allowed, i.e. no merging of any
> kind
>    will be done
> 
> OK so what you are suggesting is to try to avoid .merge files.
> We can check that snippets start with a valid section.
> We can check that the section name is not a dup but without .merge
> file 
> we can't specify what list this snippet should be merged into.
> I mean if the snippet creates a new provider or domain then it will
> be 
> in config but the key that lists the domains or provider would not be 
> update and this this section would not be used by the SSSD logic.
> There are sections that can just be dropped in this is why */mergesec 
> and /**/mergekey /*are optional but they are not the main use case.

I have caught up with this proposal only now, so I am sorry for jumping
in late, but I see no use for merging configurations in the sense of
combining values of a sections together from 2 files without explicit
include files.

In general it is, in general, a bad idea to try to merge arbitrary
configurations from 2 files because it is hard to mentally visualize
what will be the result and errors where sections have the same name by
mistake will cause very hard to diagnose issues.

I think in abstract it is an interesting idea, but in actual usage it
may be more pain than gain.

Include files are a different proposition altogether they are not full
sections, and can be ordered with regard to existing data from the
inclusion file so to control what gets included before/after and have an
idea of what will take precedence.
They are also generally manually controlled by admins, although we do
abuse include files in krb5.conf with sssd...

> For SSSD they actually be sort of required.

The only reason you'd need to do this for sssd is to set the domain list
in the [global] section where not only you need to merge directives, you
actually have to "merge" the values of a particular key.
This is honestly ... madness :-)

I think the solution here is to change the way sssd behaves by
augmenting the domain list by adding a key in the domain sections to
mark the enabled/disabled. The order of the domains not explicitly added
to the global list that are explicitly enabled would depend on the order
they are declared. Problem solved, no more merging needed.

> What I referred to being insecure is the fact that if you have two 
> applications X and Y being able to add augmentation to the same App
> does not mean that you trust them the same way. If you have one top
> level directory and the drop snippets in the common .d directory they
> can also mess with each other files. If they are always forced to
> their own sub-dir we can use SELinux for making sure one application
> would not mess with the config file of another application. IMO
> without this we are susceptible to virus kind of attacks. This is why
> I see it as insecure.

I think  this goes too far, normally generic applications cannot drop
configurations files 'live', usually the stuff that drop configuration
snippets is either the package manager (implicitly trusted, as it can
change *anything*) or it is a highly privileged management tool that
is also trusted by the admins.
In general I cannot think of a case where you would ever allow a "less"
trusted application to change main configuration data of a higher
privileged app. In those cases you would probably always manage
configurations separately with explicit invocations of the configuration
library on the specific files, and careful filtering of the inputs under
much stricter rules.

In short I think you can keep things a lot simpler and achiever useful
results faster by imposing better restrictions on the architecture that
will actually make the library better for admins, even thought it would
be theoretically less flexible.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list