[SSSD] INI validation design thoughts

Dmitri Pal dpal at redhat.com
Wed Apr 7 20:02:56 UTC 2010


Stephen Gallagher wrote:
> On 04/07/2010 02:46 PM, Dmitri Pal wrote:
> > See below
> >> 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?
> >>
> > We can look into regex validation. Do not see big deal here.
> > Will be a special function though. Can be added incrementally
> > in a separate patch and handled as a separate task
> > (within v1 validation functionality).
>
> > As for separators I imply that space is always a valid separator.
> > Those would be additional separators we can check.
>
> I think it makes sense to NEVER use space as a separator, so that the
> use of a separator then becomes explicit and unambiguous. (And it's
> possible to add human-readable spaces around a separator)
>
> > Adding comma to the list for example would not generate an error and
> > would parse list:
> > foo bar baz
> > the same way as
> > foo,bar,baz
> > or
> > foo, bar, baz
>
> > There was a bug recently about the similar issue.
> > Multiple separators for a list is already baked into the parsing logic.
>
>
> My concern is for the possibility of options where you specify
> foo bar, baz
>
> Because with your proposal, this is always translated to:
> (foo, bar, baz), when what they really wanted was (foo bar, baz)
>
> Right now in the SSSD there aren't any cases like this, but we're trying
> to build libini_config for general consumption. I don't think we're out
> of line requiring an explicit separator. Additionally, we can add
> another rule that whitespace surrounding a separator is not included in
> the value.
>
> So name = value1\s\s\s,\svalue2 would become ('value1', 'value2') and
> not ('value1 ', ' value2')
>

I kind of disagree with the whole approach.
If you want spaces inside the value you need to make the string quoted.

Something like

value = "fist value", "second value"

This is currently not supported but would be easy to add when needed.
But again we are talking about the ini files and explicitly multi value
lists.
It is not a good practice to have spaces in the multi value lists anyways.
And I do not want people to encourage doing it.
In case of single value the inner spaces are preserved but leading
and trailing ones are trimmed.

By default right now spaces around separators are treated as separators
and trimmed.
This is how it already works.

That means that:
foo , , bar
value will be processed as list of two items.
However not long ago I added a patch that would allow one to treat this
case as
the list of three items: foo, <empty string> and bar
And we can add a specifier for the in the schema.

My point that the rule of thumb is:
* Spaces are always a separator
* Spaces are always trimmed
* Sequences are treated as:
* Any sequence of separators is counted as one separator (option 1)
* Non space separators are counted as separate separators and value
between them is treated as ans empty value (option 2)


> >> [snip]
> >>
> >> 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.
> > But this is what we have in sssd.conf
>
> > I am talking about the:
>
> > services = nss, pam
>
> > Services attribute is a section list meaning that the nss and pam
> > sections need to be defined.
> > Another example of the section list is the "domains" attribute.
>
> > domains = redhat.com
>
> > But the sections are actually named:
>
> > [domain/redhat.com]
> > ...
>
> > So to describe it one would say:
> > [domais_def]
> > name = domains
> > section = sssd
> > seclist = yes
> > secprefix = domain
>
> > Now imagine that "domain" is actually not a constant but a value of
> > another key in the ini file.
> > Then we would have to use some kind of the reference.
> > That would be something like "secprefref". But currently it is not used
> > so we can skip it for now.
>
> > So based on the definition of the "domains" key the sections that should
> > be present in the INI file
> > should be constructed as the value of the key in the actual ini file
> > prepaneded with the word
> > "domain". So how I can say that a key should belong to such a
> > dynamically defined section?
> > This is where the "secref" is going to be used. See example at the end
> > of the mail.
>
>
> > We will need to come up with some better "implication" rules and
> > describe it.
> > For example: if vtype is defined it should be implied that this is a
> > field. If the regex is defined then it should imply vtype = string and
> > so on.
> > But this we can do and build as we go.
> > One lesson for this is to write good doc as you go.
>
>
> >> [snip]
> >>
> >> 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
> >>
> > I do not understand what you are trying to say here.
> > I think I missed one other key that I wanted to include: values (or may
> > be "choices" as you suggested)
>
> > choices = local, ldap
>
> > would mean that the value for the key can be only one from the list.
> > If the list = yes for such value, it would mean that each of the
> > values for the key in the real ini file should be one of those.
> > For example:
> > is schema:
>
> > [family]
> > name = family
> > section = building
> > list = yes
> > vtype = string
> > choices = Dad, Mom, Son, Daughter
>
> > In the config file:
> > family = Mom, Son, Son <- will be Ok
>
> > family = Mom, Sister, Son <- will will generate and error because
> > "Sister" is not a valid value
>
>
> I think you missed my point. I was talking about the case where you want
> to have a limited set of choices for an option, but you want the set of
> choices to be extensible by a secondary schema file. For example, I want
> to have sssd.schema to handle all the options that are available for the
> SSSD itself, and then I want to have a directory (sssd.schema.d)
> containing files like sssd-local.schema, sssd-ldap.schema.
>
> In sssd.schema, I'd have:
> [id_provider]
> type = field
> vtype = multi
> choices =
>
> In sssd.schema.d/sssd-local.schema, I'd have:
> [id_provider]
> type = extend
> choices = local
>
> In sssd.schema.d/sssd-ldap.schema, I'd have:
> [id_provider]
> type = extend
> choices = ldap
>
>
>
> Then, in sssd.conf I would be able to provide:
> [domain/mydomain]
> id_provider = ldap
>
> But if I provided:
> [domain/mydomain]
> id_provider = nosuchprovider
>
> I should get a parse error because that's not one of the acceptable
> choices.
>

Wow!
I think you are adding complexity out of proportion here.
Something like this can be added for sure but I do not see a big use case.
Why the main schema can't be modified with the extensions?
I think you are going way beyond what is needed at the beginning.
You are probably thinking about the third party back ends adding
their configurations into the sssd.conf.
I think we should start by just requiring modifications to the schema file
and then if that does not work out add extensibility as you suggest.

IMO too much for a v1 of the INI validation. Sounds more like a v3
feature...

>
>
> >> 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 = .*
> >>
> > So I think what you are trying to say is:
>
> > (in schema)
>
> > [domais_def]
> > name = domains
> > section = sssd
> > seclist = yes
> > secprefix = domain
>
> > [id_provider]
> > name = provider
> > secref = domains_def
> > vtype = string
> > list = yes
> > choices = local, ldap
>
> Hopefully I made myself clear above, but just in case: 'list = yes' here
> would be wrong. I don't want id_provider to accept a list of values, I
> want it to have a single value chosen from a list that may have been
> constructed and extended from multiple different files.

Then it is just

[id_provider]
name = provider
secref = domains_def
vtype = string
choices = local, ldap

And if there is a third party provider he would have to add things
to the same schema file and modify it.

choices = local, ldap, rsa <- Example of the rsa adding itself into the
schema

IMO it is a trivial scripting exercise (using augeas or just plain
sed+grep)
to check if the rsa schema data is blended or not and blend it into the
file
if it is not yet.


As I said - nice idea but too much complexity out of box.

>
> > (will mean that)
>
> > The key "provider" will have a string value from the provided
> > choice of "local, ldap" and will belong to the section that will be
> > dynamically
> > constructed from the value of the key "domains" in section "sssd" using
> > prefix "domains"
>
> > [sssd]
> > domains = somewhere.com
> > ...
>
> > [domain/somewhere.com]
> > provider = ldap
> > ...
>
>
>
>
>
>
>
>
_______________________________________________
sssd-devel mailing list
sssd-devel at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the sssd-devel mailing list