[SSSD] [DESIGN DISCUSSION] Configuring SSSD

Sumit Bose sbose at redhat.com
Fri Jun 6 08:53:29 UTC 2014


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?

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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list