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