[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