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

Dmitri Pal dpal at redhat.com
Wed Apr 2 03:51:23 UTC 2014


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 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.


>
> 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.
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.


>
> 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.

>
> 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.


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.




More information about the sssd-devel mailing list