On 06/06/2014 04:53 AM, Sumit Bose wrote:
On Thu, Jun 05, 2014 at 10:09:54PM -0400, Dmitri Pal wrote:
> Hello,
>
> Over the time multiple tools have been developed and used to address
> different use cases around SSSD configuration.
> We now have:
> 1) SSSD that needs to read a configuration. It uses ding-libs libini_config
> for that purpose.
> libini_config was historically developed to read configuration from C
> services like SSSD.
> It is currently used by SSSD and GSS proxy
> It is not capable of modifying and saving the configuration. To be fair it
> is capable but the interfaces are not exposed at the high level API. It will
> take some (couple days or so to close this gap).
> 2) SSSD also needed to create sssd.conf at the installation time. It is
> ueasy to do it from Python this is why an SSSD config python script have
> been created. It is good at modifying the configuration and setting specific
> values at the beginning of the sssd.conf's life. It is not suited well (at
> least yet) for long term maintenance of the configuration file. It is also
> SSSD specific.
> 3) Over the time there were RFEs that suggested that sssd configuration
> should be extensible or overwritable.
> The following ticket cover that:
https://fedorahosted.org/sssd/ticket/2247
> The design has been published here
>
https://fedorahosted.org/sssd/wiki/DesignDocs/ding-libs/INIConfigMerge
> 4) There is a desire to manage SSSD over OpenLMI a cockpit in an object
> oriented way. To do that (following the standard LMI model) the following
> layring has been suggested and implemented:
>
> Consumer (OpenLMI/Cockpit) -> D-Bus interface -> ifp service (responder) ->
> augeas c api
>
> More details are here:
>
https://fedorahosted.org/sssd/wiki/DesignDocs/OpenLMIProvider
>
> 5) In the absence of the good configuration solution for the integration
> purposes, i.e. to integrate applications running on top of the system with
> SSSD as a short term solution a puppet-augeas based way of configuring
> sssd.conf was introduced the other day. The main requirements are to be able
> to modify existing configuration and more specifically change the values
> that represent a list of values.
>
> 6) From the very beginning we were hoping that there would be a way to be
> able to define the grammar of the configuration file and check it to be able
> to diagnose the config files and prevent their corruption. The idea was to
> add this capability to libini as it provides a set of nice convenience
> capabilities in comparison to Augeas. Also Augeas until not long ago was not
> included in some distors.
>
> The list above presents a spectrum of use cases and solution to those use
> cases.
> The goal of this email is to try to enumerate the use cases and constraints
> and understand how the solution for those use cases can be consolidated and
> unified and where it makes sense todo and where not. It is a goal to define
> a reasonable alignment between the technologies and provide a path forward
> to a reusable and maintanable stack.
>
> So we have the needs:
>
> 1) Read config files at run time from C (daemons and D-BUS provider)
> 2) Write config files from C (configuration interface over LMI)
> 3) Create and modify files at installation and upgade using some simple
> mean/API which can be C, python or anything else
> 4) Be able to manage configuration files in a object oriented manner with or
> without D-BUS running
> 5) Be able to augment the code file without touching it
> 6) Provide a way to validate the file
>
>
> So I see the following layering
>
> +------------------+
> | High level tools |
> +------------------+
> |
> \/
> +---------------------------+
> | Object oriented interface |
> +---------------------------+
> | |
> \/ \/
> +-----------------+ +------------------+
> | D-BUS responder | | D-BUS shim layer |
> +-----------------+ +------------------+
> | --------------------|
> | |
> \/ \/
> +-------+ +----------------+
> | C API |<-------------| File validator |
> +-------+ +----------------+
> /\ \
> | \ +--------------+
> | -------------->| Config file |
> | +--------------+
> | /\
> +----------------+ |
> | SSSD/GSS proxy | |
> +----------------+ |
> |
> +------------------+
> | SSSD Coinfig API |
> +------------------+
> /\
> |
> +--------------+
> | Simple tools |
> +--------------+
>
I have a general comment first. I'm missing the security aspect a bit.
Where are the decisions made who is allowed to write which data to the
config file? Currently only root is allowed to write to the on disk
config file and I think we should keep it this way. So the "legacy" path
via the SSSD config API is safe. I think the final decision about who
can write what to the config file should be done in the C API e.g. based
on the grammar for validation. But is it possible to get trusted
information about the origin of the request through all the layers down
to the C-API? Or do we need some kind of authentication in the C-API?
The C API is a low level library loaded into a process.
The process should have privileges to do the file modifications.
I do not think we need any authentication here.
D-BUS provides ability to check who is the requester of the method and
validating the authority of the caller should be the job of the config
responder not of the API.
bye,
Sumit
> This layout shows three distinct paths towards config file:
> 1) Old python API and tools on top (does authconfig use this path?)
> 2) Top level D-BUS api and advanced object oriented tools
> 3) C API
>
>
> We need to make several decisions at this point:
> a) How much we enhance-update-improve existing python API instead of using
> new D-BUS interface.
> IMO we should leave python API alone for foreseeable future but any new
> changes should go via the new D-BUS interface
>
> b) How we make sure that the D-BUS interface is really usable. It is not
> that light weight.
> Would be nice to be able to have a shim layer for the cases like docker
> where there might not be D-BUS or systemd. This however might not be a
> problem for us to solve. It might be a generic problem for all LMI style
> providers. A lot in D-BUS world is autogenerated so I suggest that we ask to
> be able to generate a mini D-BUS interface that would go directly from the
> interface to the logic implemented in responder. I do not know what is best.
> But I think it is a discussion to have with D-BUS guys and should be more
> general.
> For now we can assume that D-BUS is there and docker use case will be solved
> in some generic way.
>
> c) If we assume D-BUS and systemd it really makes sense to separate the
> responder in charge of configuration from other responders and make it
> started on demand when there is a real call over the D-BUS to make a config
> change. IMO this work for splitting ifp into data ifp and config ifp should
> be filed as a ticket and done as a part of 1.13 release.
>
> d) What is going to be the low level C library? We have two candidates
> libini and augeas.
> I definitely have a preference towards libini but this does not mean I am
> right. I do not have a lot of time to maintain libini. I do not see a reason
> to rip it out and replace with augeas yet. But I also do not see a reason
> why we should rely on augeas. Right now IMO it would be more work to rip
> libini and switch to augeas but over time if we do more and more augeas work
> it might be much less. I feel people are more comfortable with augeas than
> using libini and adding to it as they go. I do not know why but suspect it
> is because augeas has appeal of a more commonly used tool/interface. It is
> all about what we think is the right path. If we decide that augeas is the
> way to go then we should not invest into enhancing libini and start building
> our improvements in augeas or around augeas. If we think that libini is the
> right path because it fill give us more features, flexibility and control
> then let us make it so that I am not the only contributor to it and people
> would not have problems throwing patches at it on as needed basis.
> For me this is a very important decision. Right now I feel I am on hook to
> continue investing my scares time into libini. I think I am holding people
> back with this so I would rather come to terms and move forward whatever we
> think is best for SSSD, GSS proxy and potential other daemons that need to
> read and deal with config files.
>
>
> Thoughts?
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager IdM portfolio
> Red Hat, Inc.
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.