<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 04/04/2014 07:39 AM, Sumit Bose
      wrote:<br>
    </div>
    <blockquote cite="mid:20140404113945.GR11404@localhost.localdomain"
      type="cite">
      <pre wrap="">On Tue, Apr 01, 2014 at 11:51:23PM -0400, Dmitri Pal wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 04/01/2014 05:26 AM, Sumit Bose wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">On Fri, Mar 28, 2014 at 09:08:33PM -0400, Dmitri Pal wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">Hello,

Please review:
<a class="moz-txt-link-freetext" href="https://fedorahosted.org/sssd/wiki/DesignDocs/ding-libs/INIConfigMerge">https://fedorahosted.org/sssd/wiki/DesignDocs/ding-libs/INIConfigMerge</a>
</pre>
          </blockquote>
          <pre wrap="">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 .&lt;conf_file_name&gt;.merge.conf . But I would
suggest to drop the '.' because the merging rules are part of the
configuration and should not be hidden.
</pre>
        </blockquote>
        <pre wrap="">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
</pre>
      </blockquote>
      <pre wrap="">
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.

</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
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.</pre>
    </blockquote>
    <br>
    I will. I am waiting for other comments to accumulate so that I can
    make changes in one shot.<br>
    <br>
    <blockquote cite="mid:20140404113945.GR11404@localhost.localdomain"
      type="cite">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <pre wrap="">

</pre>
        <blockquote type="cite">
          <pre wrap="">
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__].
</pre>
        </blockquote>
        <pre wrap="">
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.
</pre>
      </blockquote>
      <pre wrap="">
How does the application dictates it? Only by the source code or can
this be modified by the main config file as well?</pre>
    </blockquote>
    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.<br>
    <br>
    <br>
    <br>
    <blockquote cite="mid:20140404113945.GR11404@localhost.localdomain"
      type="cite">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
        <blockquote type="cite">
          <pre wrap="">
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/*
</pre>
        </blockquote>
        <pre wrap="">
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.
</pre>
      </blockquote>
      <pre wrap="">
no, there is no merge logic at all, see the two conditions below.</pre>
    </blockquote>
    <br>
    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.<br>
    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.<br>
    <br>
    <blockquote cite="mid:20140404113945.GR11404@localhost.localdomain"
      type="cite">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <pre wrap="">

</pre>
        <blockquote type="cite">
          <pre wrap="">
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
</pre>
        </blockquote>
        <pre wrap="">

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.
</pre>
      </blockquote>
      <pre wrap="">
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.</pre>
    </blockquote>
    <br>
    Ah you mean the two conditions:<br>
    <pre wrap="">- 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
</pre>
    <pre wrap="">
</pre>
    <p wrap="">OK so what you are suggesting is to try to avoid .merge
      files.<br>
      We can check that snippets start with a valid section.<br>
      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.<br>
      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.<br>
      There are sections that can just be dropped in this is why <strong><em>mergesec
          and </em></strong><strong><em>mergekey </em></strong>are
      optional but they are not the main use case. For SSSD they
      actually be sort of required.<br>
    </p>
    <p wrap=""><br>
      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.<br>
    </p>
    <br>
    <blockquote cite="mid:20140404113945.GR11404@localhost.localdomain"
      type="cite">
      <pre wrap="">

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.</pre>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote cite="mid:20140404113945.GR11404@localhost.localdomain"
      type="cite">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <pre wrap="">
</pre>
        <blockquote type="cite">
          <pre wrap="">
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/*.
</pre>
        </blockquote>
        <pre wrap="">
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.
</pre>
      </blockquote>
      <pre wrap="">
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?</pre>
    </blockquote>
    <br>
    I expect that the snippets are dropped at install time or can be
    managed by a user manually if he has corresponding privileges.<br>
    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.<br>
    <br>
    <blockquote cite="mid:20140404113945.GR11404@localhost.localdomain"
      type="cite">
      <pre wrap="">

How shall the file-system permission look like for the directory, config
snippets and .merge.conf file?</pre>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote cite="mid:20140404113945.GR11404@localhost.localdomain"
      type="cite">
      <pre wrap="">

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.</pre>
    </blockquote>
    <br>
    Good point will add that to the page.<br>
    <br>
    <br>
    <br>
    Are there any other comments or opinions?<br>
    <br>
    <blockquote cite="mid:20140404113945.GR11404@localhost.localdomain"
      type="cite">
      <pre wrap="">

bye,
Sumit


</pre>
      <blockquote type="cite">
        <pre wrap="">

So bottom line, I mostly disagree that what you propose to solve is
a design goal.

Thanks
Dmitri

</pre>
        <blockquote type="cite">
          <pre wrap="">
bye,
Sumit

</pre>
          <blockquote type="cite">
            <pre wrap="">-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
<a class="moz-txt-link-abbreviated" href="http://www.redhat.com/carveoutcosts/">www.redhat.com/carveoutcosts/</a>



_______________________________________________
sssd-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sssd-devel@lists.fedorahosted.org">sssd-devel@lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/sssd-devel">https://lists.fedorahosted.org/mailman/listinfo/sssd-devel</a>
</pre>
          </blockquote>
          <pre wrap="">_______________________________________________
sssd-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sssd-devel@lists.fedorahosted.org">sssd-devel@lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/sssd-devel">https://lists.fedorahosted.org/mailman/listinfo/sssd-devel</a>
</pre>
        </blockquote>
        <pre wrap="">

-- 
--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

_______________________________________________
sssd-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sssd-devel@lists.fedorahosted.org">sssd-devel@lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/sssd-devel">https://lists.fedorahosted.org/mailman/listinfo/sssd-devel</a>
</pre>
      </blockquote>
      <pre wrap="">_______________________________________________
sssd-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sssd-devel@lists.fedorahosted.org">sssd-devel@lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/sssd-devel">https://lists.fedorahosted.org/mailman/listinfo/sssd-devel</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.</pre>
  </body>
</html>