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/INIConfigMergeI 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 isyes, 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 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.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 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.
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 doneI 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.
- 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.
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?
How shall the file-system permission look like for the directory, config snippets and .merge.conf file?
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.
bye, SumitSo bottom line, I mostly disagree that what you propose to solve is a design goal. Thanks Dmitribye, 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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel_______________________________________________ sssd-devel mailing list sssd-devel@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
-- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc.