[SSSD] INI validation design thoughts

Dmitri Pal dpal at redhat.com
Wed Apr 7 20:14:08 UTC 2010


Stephen Gallagher wrote:
> On 04/07/2010 04:02 PM, Dmitri Pal wrote:
> > 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...
>
>
> Dmitri, the ENTIRE POINT of doing this is because we need to support
> third-party backends, and we have no advance knowledge of what
> configurations they will need. If this is not a v1 feature, it's not
> even a v1 solution.
>
> >>
> >>>> 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
> >>> ...
>
> That is completely unacceptable on many, many levels. Not the least of
> which is that this would be completely forbidden by RPM packaging rules.
> Any third-party backend would have its own package, and packaging rules
> forbid two files owning or modifying the same config file. That's the
> lion's share of the reason for drop-directory configurations: so that
> plugins don't need to modify the global configuration.
>
> Futhermore, it's impossible to guarantee that if you installed two
> third-party backends that you can uninstall them and get back into a
> clean state.
>
> No, we absolutely need to have the ability for third-party backends to
> have their own completely self-sufficient configuration.
>

Then we will just not have it at all for now.
Sorry. I can't commit to doing something of this complexity
in a reasonable time.

_______________________________________________
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