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

Dmitri Pal dpal at redhat.com
Fri Apr 4 22:25:59 UTC 2014


On 04/04/2014 07:39 AM, Sumit Bose wrote:
> On Tue, Apr 01, 2014 at 11:51:23PM -0400, Dmitri Pal wrote:
>> On 04/01/2014 05:26 AM, Sumit Bose wrote:
>>> On Fri, Mar 28, 2014 at 09:08:33PM -0400, Dmitri Pal wrote:
>>>> Hello,
>>>>
>>>> Please review:
>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/ding-libs/INIConfigMerge
>>> I would like to start with a few general comments.
>>>
>>> About .merge.conf. I think the name has to contain the name of the
>>> original config file, because there might be multiple different config
>>> files in the same directory. I you really want to keep the '.' at the
>>> beginning I would suggest .<conf_file_name>.merge.conf . But I would
>>> suggest to drop the '.' because the merging rules are part of the
>>> configuration and should not be hidden.
>> Dot at the beginning just to differentiate that it is a service file
>> rather than the main config file.
>>
>> I am not sure you understood the approach I took. The assumption is
> yes, I'm sorry, I didn't read carefully enough. I was under the
> assumption that the .merge.conf will be on the same level as the main
> config file and not in the config sub-directory.
>
>> that in a directory can be only snippets related to one main file.
>> For example it is expected that in /etc/sssd.d directory there will
>> be snippets of SSSD and not any other file.
>> I also find it wrong that different applications have access to the
>> same directory. This way they can step on each other.
>> Instead I suggest that if we have application X and application Y
>> augmenting SSSD config they will create sub directories under
>> /etc/sssd.d
>> /etc/sssd.d/X
>> /etc/sssd.d/Y
>> and put their snippets into these sub-directories. It is expected
>> that they can have augmentation to different sections of the main
>> file but only one declaration file. This is why I do not see a
>> reason to add a name to the file.
> I see. You should add this to the 'Proposed convention' section of the
> design page. Having sub-directories per application makes it easier to
> install the .merge.conf and the file with the config snippets.

I will. I am waiting for other comments to accumulate so that I can make 
changes in one shot.

>
>>
>>> Additional I could imagine that people would like to have the merging
>>> rules in the master config file, e.g. in special sections like
>>> [__section_name_MERGE_RULES__].
>> This is covered by the rules.
>> The main application actually dictates whether overwrite is allowed
>> or not. It either allows it or not and snippets declare whether they
>> would want to overwrite if the application allows overwrites.
> How does the application dictates it? Only by the source code or can
> this be modified by the main config file as well?
I assume it is something that application either hard codes or defines 
as a startup argument. IMO it does not belong in the config file itself.



>
>> I am not ready to go to the complexity of SSSD saying: you can
>> augment one section but not another. This is going too far.
>> This can be a future RFE if someone asks about it in future.
>>> I think currently most application which support having parts of the
>>> configuration in separate files use the following scheme. They have a
>>> central config file, e.g. /conf_path/app.conf, at a hardcoded
>>> (changeable with command line options) place and a directory
>>> /conf_path/add.d.  What the application reads as configuration can be
>>> seen as the result of
>>>
>>> cat /conf_path/app.conf /conf_path/add.d/*
>> This is a very bad merge logic. It is last in wins. INI supports
>> this merge logic as one of options but it is not default and I do
>> not think it should be.
> no, there is no merge logic at all, see the two conditions below.

AFAIU (and may be I just do not understand what you mean with the cat 
command above) the output of the cat command will create a unified 
stream of data that can be used as an input to the parser.
If the parser is not smart then it will just read and overwrite the data 
that was create earlier in the stream if there is a dup key or section. 
In libini_config you can actually control it and define how to deal with 
this situation and say whether you are allowed to have dup keys and 
sections or not.

>
>>
>>> I would suggest to add this scheme as a default mode if no merge config
>>> file is available with the following 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
>>
>> I do not like the current approach.
>> IMO current approach is too primitive and insecure (and thus wrong).
>> The whole point is to prevent applications from stepping on each
>> other and updating main config file when they are not entitled to.
> It is primitive, but why it is insecure? With the two conditions above
> the main config file cannot be updated, only new sections can be added,
> and applications cannot step on each other, because duplicated section
> names will lead to an error.

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. For 
SSSD they actually be sort of required.


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.


>
> My point is not about merging but supporting what imo is currently the
> main use case for a directory with config snippets. I think this might
> help the adoption by other projects if they see that libini provides a
> simple interface for their current use case. Later on they will learn
> about the more advanced features and will use them it they make sense
> for their project.

IMO it is a big leap anyways. We have applicatiosn we care about: SSSD 
and GSS proxy that use ding libs. IMO having this new convention in 
those is OK. Others already have a solution. Moving to ding-libs will be 
a leap anyways. I think it is OK to not be compatible with the current 
approach and establish a new more secure subdirectory based way of 
dropping snippets.

>
>>> I think this will cover the majority of use cases without defining the
>>> merging rules explicitly. And it would be possible to do this with the
>>> current API, i.e. applications must be only linked against the new
>>> version of libini to make use of configuration files in
>>> /conf_path/add.d/*.
>> This is not that simple. They would have to change anyways so it is
>> not a design goal to try to convert these applications.
>> IMO providing a clear merge logic and discretion is the key.
>> It makes sense for our security related applications, it is much
>> more important to satisfy their needs than to make a generic
>> library.
>>
>>  From the SELinux POV it would be better to force applications that
>> try to add to augment main config file to create sub directories
>> under "mainfile".d.
> Do I understand correctly that the config snippets shall not only be
> created at install time, but modified by the application itself at
> runtime? Or do you mean the user level that e.g. a user with the SELinux
> role appXadm_r is allowed to edit files in a special directory related
> to application X?

I expect that the snippets are dropped at install time or can be managed 
by a user manually if he has corresponding privileges.
But I am more concerned about applications stepping on each other. If 
user gets involved he can do anything he wants but he controls the system.

>
> How shall the file-system permission look like for the directory, config
> snippets and .merge.conf file?

Good question. I assume they should be created readable only by the user 
that is the application us usually running under. For SSSD it will be 
root. For some other application it might be that application.

>
> Can you add some examples, either generic or specific for SSSD or
> gssproxy, which show the main config file, config snippets and
> .merge.conf first and then the resulting combined configuration? They
> can be re-used later in unit tests as well.

Good point will add that to the page.



Are there any other comments or opinions?

>
> bye,
> Sumit
>
>
>>
>> So bottom line, I mostly disagree that what you propose to solve is
>> a design goal.
>>
>> Thanks
>> Dmitri
>>
>>> bye,
>>> Sumit
>>>
>>>> -- 
>>>> Thank you,
>>>> Dmitri Pal
>>>>
>>>> Sr. Engineering Manager for IdM portfolio
>>>> Red Hat Inc.
>>>>
>>>>
>>>> -------------------------------
>>>> Looking to carve out IT costs?
>>>> www.redhat.com/carveoutcosts/
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> sssd-devel mailing list
>>>> sssd-devel at lists.fedorahosted.org
>>>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>>> _______________________________________________
>>> sssd-devel mailing list
>>> sssd-devel at lists.fedorahosted.org
>>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>>
>> -- 
>> --
>> Thank you,
>> Dmitri Pal
>>
>> Sr. Engineering Manager IdM portfolio
>> Red Hat, Inc.
>>
>> _______________________________________________
>> sssd-devel mailing list
>> sssd-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20140404/cf3ee425/attachment.html>


More information about the sssd-devel mailing list