[SSSD] INI validation design thoughts

Stephen Gallagher sgallagh at redhat.com
Wed Apr 7 20:10:23 UTC 2010


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

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.

- -- 
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/

iEYEARECAAYFAku85q8ACgkQeiVVYja6o6Mh4gCfZA2g4lwTcD9iPLsYQLKfRZat
HZoAmwSDMCN9Zy6h8tdjyGGkBKOUgzld
=5JLH
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list