On 04/06/2014 12:11 AM, Simo Sorce wrote:
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.
I disagree with several points here, sorry.
1) I agree that it would have been better if sssd.conf had a different
semantics about the domains. But the situation right now is that the
domains are listed. I agree we can go to your model but in reality there
then will be more code and more logic in SSSD to actually identify which
sections are domains and which are not. I am proposing to make it a part
of the library so that we implement it once and SSSD does not need to
change and write more custom code. The amount of code and complexity
will be same it is just where you put it.
Another thing is that domains is not the only option the provider list
is constructed the same way. There is now two things that you have to
change in the sssd.conf. IMO it is too much.
2) Include files are bad because they require you to modify the main
config file. The use case I want to be able to support is that you can
add domains without touching the main configuration file. Say you have a
base image that you deploy and then you have some snippets that you drop
in when you deploy things. Whether the configuration snippets are
dropped in by an application or they are dropped by config tool like
Puppet or they are created as part of Kickstart/Cloud-init or some other
scripts run by orchestration software does not matter. What matters is
that they should extend the configuration without touching the main
file. That eliminates the include file approach altogether.
3) The question about merges comes again and again and IMO it is the
time to get serious about it.
I explicitly said that there are several rules that would prevent issues
that you are concerned about.
a) There is not overwrite between snippets so any collision would cause
an error. It will be recorded and snippet will be ignored.
b) We can force the snippets to have sections though strictly it is not
required but we can do it if people think that it is 100% necessary.
c) There was a use case when person actually wanted to replace a
section. In case of SSSD we probably do not want that but library should
allow it. Merge logic already supports this so it is a question of a
flag passed to an existing call - no extra code or complexity.
In case of SSSD the rule would be (at least by default for now) that
sections can only be unique and can can be added with no overwrite. Any
colliding snippet that collides with a section in the main file will be
recorded and ignored because SSSD should be able to start and work
without the augmentations.
d) I actually think that merging values, i.e. adding a value to the list
like in the list of the domains or providers is not a bad thing. It will
allow us to avoid interpreting what each section is about by
introspecting it. It will also avoid having stale sections that actually
do not have any meaning or value. Moving forward when we have syntax
validation we will be able to define and validate that the desired key
and section are actually a list that is extensible. I had this in mind
but this is outside of scope of the current proposal.
Bottom line:
We have use case that require merges, we have SSSD with its semantics.
The proposal covers both cases. If you think that sub dirs is a bad is a
bad idea I will budge but I think it is a mistake.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.