[SSSD] INI validation design thoughts

Stephen Gallagher sgallagh at redhat.com
Wed Apr 7 17:36:37 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/07/2010 11:57 AM, Dmitri Pal wrote:
> Hi,
> 
> I was looking at the ideas that Steve vocalized yesterday for the INI
> validation.
> To recap:
> Consider using XML/XSLT/Relax NG/Schematron to do ini file validation.
> 
> I did some research on the matter and here is what I am thinking.
> What we want to accomplish is the internal validation of the INI file
> when it is loaded.
> We do not want to fork a separate process that will validate the INI file.
> Though the suggested approach generally makes sense but there is no open
> source C implementation for the Schematron that I could find.
> And even if it exists it will take time to make sure it is a part of the
> distributions we care about.

I thought it was a part of libxml2, but upon further research I see I
was mistaken.

> Libxml supports schema validation but I really do not see a big benefit
> in going this path.
> To validate an ini file the library (embeded into the application) would
> have to:
> 1) Read the schema file
> 2) Convert schema to the RelaxNG schema on the fly

I think you missed the point that I was describing having the schema
file be written directly in RelaxNG or XST, but that's irrelevant now.

> 3) Read the config file
> 4) Convert it to xml probably using XSLT
> 5) Use libxml to implement validation logic
> 
> This just sounds a bit too heavy.
> I had in mind a more customized approach
> 1) Read schema file
> 2) Read config file
> 3) Validate

This is essentially how the SSSDConfig API does things now (albeit it's
a very limited validation: we only validate that it matches the expected
Python type (str, int, etc.)

> 
...

> Here is the design that I have in mind for the INI schema definition
> file and logic related to it.
> The INI file schema definition ini file will consist of description of
> the experted configuration optioins in the INI file.
> It will consist of the sections that describe keys in the ini files and
> sections that describe rules.
> We will skip rules for now and will talk about just the sections that
> define keys.
> I think that if we implement just that we will bring a lot of value.
> 
> Any section in the schema definition file will have a unique name. This
> the name of the section not the name of the key.
> This is an important difference. Think about the name of the section as
> the name of the variable that holds an object that describes some key.
> Each key definition section would have the following possible attributes
> that describe the properties of the key and its value in the
> configuration file.
> 
> Here is an example. Say we want to describe the key "provider" in the
> section "backend" of the INI file. Here how it might look like in the
> INI schema definition:
> 
> [backendprovier]
> type = field                                 <- Optional if omitted type
> "field" is assumed. Possible values: field, rule. Rule value not
> supported in v1
> section = backend                      <- Optional, specifies what
> section the key belongs to. If omitted the "secref" key should be
> defined. See below.
> name = provider                        <- Required, must be a unique
> name within the section.
> required = yes                            <- Optional, if omitted "no"
> is assumed
> vtype = string                            <- Type of the value. Can be :
> int32, uint32, long32, ulong32, double, bool,
> list = no                                     <- Optional, if omitted
> "no" is assumed, specifies if the value is the list or not
> sep = ,;                                       <- Potential other
> symbols that can be used as list item separators - can be added later
> 
> And so on...
> Other interesting keys that came to mind:
> 
> min = 0                                     <- Min value for a numeric key
> max = 1000                              <- Max value for a nemeric key
> 

We really need to have
regex =
as an option. For example:
[ldap_uri]
type = field
vtype = string
regex = ldaps?://[\w\.]*
list = true
sep = , #How would we do space-separation? Should we even bother?


> Alternatively we can support (later) something like:
> 
> ranges = 0, 10, 20, 30               < will mean that the value should
> be in range from 0 to 10 or between 20 and 30. Might come up with some
> better syntax...
> 
> The following keys would be interesting too:
> depends = backendprovier, backendsomthingelse      <- This means that
> the key becomes required if the key backendprovier or key
> backendsomthingelse is defined.
>                                                                                          
> Notice that "backendsomthingelse" is used as a reference to another
> section in the schema.
> 
> So far all this can be handled by the INI parsing without modification.
> We some improvements and additions we can add something like this:
> 
> depends = backendprovier[foo, bar, baz] <- That would mean that the key
> becomes required only in case the value of the backendprovier is foo,
> bar or baz.
> 
> Another interesting key that we might want to define is: seclist
> seclist = yes                          <- Would mean that the value of
> the key specifies sections in the ini file. Can be used in the
> conjunction with "secprefix"
> secprefix = sometext            <-  Would mean that the name of the
> sections should be constructed by prepending this value
> 
> Potentially we can also add "secprefixref" that will point to  a key
> whose value should be added as prefix for the section names.
> Here is the example. The configuration like this:
> 
> [backends]
> domain = foo.com
> be = bar, baz
> 
> [foo.com/bar]
> one = 1
> 
> 
> Will be described with schema definition like this:
> 
> [backend_domains]
> section = backends
> name = domain
> required = yes
> vtype = string
> 
> [backend_bs]
> section = backends
> name = domain
> required = yes
> seclist = yes                      <implies list=yes and vtype = string
> secprefixref = backend_domains
> 
> [subsection_one]
> secref = backend_ds
> name = one
> vtype = int32

This example is completely unparseable to my brain. Could you please try
representing it with a real-world example, such as ldap_uri? Also, I
don't like seclist, secprefixref and secref. They are not descriptive
and it will be impossible for anyone to keep them straight.

> 
> We can get more complex as we go and find use cases we need to cover.
> As we go we will also create best practices about creating your INI files.
> For example one of the things that IMO should be prohibited in the INI
> files
> at least for now is multiple dependency on presence or value.  I mean
> things like:
> value of the key X should be present if the key Y is present and the key
> Z has value "abc".
> I envision the "rules" type section for dependencies like this. I think
> that complexity
> can be added later if ever needed.
> 
> With the schema definition like this we would be able to validate the
> following things about configuration:
> 1) The value is present when it should
> 2) The value has expected type and range
> 3) The dependencies are correct
> 
> I think that covers most of the issues we need to deal with in the INI
> files.
> Steve can we check that this grammar covers what we currently have in
> the sssd.ini?
> 

See above, but we need to add, at a minimum, support for
regular-expression handling. I'd also prefer it strongly if we could add
support for something like +=

In other words, I want to be able to say:
[id_provider]
type = field
vtype = multi
choices = local

in the core config file, but then be able to say:

[id_provider]
type = extend  #implies vtype=multi
choices = ldap

in the sssd-ldap.conf and have the resulting combined INI be effectively:

[id_provider]
type = field
vtype = multi
choices = local,ldap


This way, for things like the providers, we can provide a selection list
of options. Since otherwise, our only option would be
[id_provider]
type = field
vtype = string
regex = .*


Naturally, that's error-prone.
- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAku8wqUACgkQeiVVYja6o6PCagCfSSHOvNkLPUaAlNJj91v7aBHq
qskAn1dayukWHXnXKhUKhCJyNene6qwx
=J/IE
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list