[SSSD] Conceptual question

Simo Sorce simo at redhat.com
Fri Apr 20 13:44:06 UTC 2012


On Thu, 2012-04-19 at 20:05 -0400, Stephen Gallagher wrote:
> On Thu, 2012-04-19 at 19:48 -0400, Dmitri Pal wrote:
> 
> > The question is about the ALLOW and DETECT options. As a result of the
> > merge operation using those options one can end up with more than one
> > section with the same name or more than one key with the same name
> > inside the same section. The result will be a merged config with
> > potential duplicates but in case of ALLOW there will be no errors while
> > in case of DETECT there will be some merge errors (not implemented yet)
> > that can be printed later to provide the information about what is wrong
> > with the config.
> > 
> > The ALLOW mode does not make much sense for SSSD but in general case it
> > might be useful. However current interface that deals with querying the
> > configuration and fetching configuration data does not have a way to
> > deal with the values that can have more then one value. Duplicate values
> > would not cause any trouble they are just not accessible via existing
> > interface. The interface that is available is open for changes anyways
> > so there is not problem to extend it to support access to the dup keys
> > (if needed), however it is extra work and it is not clear whether it is
> > actually needed or not.
> > 
> > I think we need to finish the DETECT mode. It has a lot of value.
> > It is ALLOW mode that I am on the fence about.
> > 
> 
> To the best of my knowledge, there are no INI parsers out there that
> allow for multi-valued keys.

I have such a need right now for gss-proxy :-)

>  In the event that two keys have the same
> value, different parsers offer one of three solutions:
> 1) Throw a parse error
> 2) First one listed in the file wins
> 3) Last one listed in the file wins (most common).

4) return list of strings :)

> So I really don't think there's much value to implementing either the
> ALLOW or DETECT options. We don't want ini_config to be writing files
> that other parsers may be unable to read (or in the common case will be
> functionally identical to OVERWRITE, since last one usually wins). It's
> best if our output always guarantees single-valued keys.

Yes this is an important concern, in general you do not want to create
multi-valued attributes because of a merge, during merges usually one
file overrides the other.

> > So the question is what to do in this situation.
> > 
> > I see several options:
> > 1) Decide that allowing duplicates is a bad idea and we will not going
> > to support it so wipe out ALLOW option
> 
> I'm in favor of scrapping the ALLOW and DETECT options.

yeah for merging probably it is better.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list