[SSSD] Design Discussion: D-Bus responder

Pavel Březina pbrezina at redhat.com
Fri Apr 18 15:37:00 UTC 2014


On 04/18/2014 05:09 PM, Jakub Hrozek wrote:
> On Fri, Apr 18, 2014 at 04:32:40PM +0200, Pavel Březina wrote:
>> On 02/24/2014 12:32 PM, Pavel Březina wrote:
>>> https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
>>
>> Hi,
>> I made some changes to the design, that I find helpful in my thesis. Namely:
>>
>
> === Representing users on the bus ===
>      * '''object path''': /org/freedesktop/sssd/infopipe/Users/$user
>
> $user should probably be $UID, likewise for $group, the identifier
> should be $GID.

$user still may refer to id, I just wanted to put the object paths into 
design. But I renamed it for better clarification.

>> Added: Representing SSSD configuration
>
> * '''property''' Uint32 debug_level
>      * The name of this service.
>
> This ^^^^ sounds like a typo.

Fixed.

> * '''property''' String default_domain_suffix
>      * The default domain suffix
>
> I don't think the default_domain_suffix is strictly needed, hardly
> anyone is using it (and I think we should discourage using it). But I'm
> not too much against publishing this property on the bus, eventually, we
> should publish them all (or most) anyway.

OK. I think we can drop that for now.

>> Added: Representing SSSD processes on the bus
>
> === Representing SSSD processes on the bus ===
>      This API should provide methods for basic operations with SSSD processes.
>           ^^^
>        I think you should explicitly say "Interface" here to make it
>        clear what DBus concept you're talking about.

Done.

> I think 'Component' is a good generalization of both responder and
> provider.
>
> Why is there no return code, for Enable and Disable though? Is there
> nothing that can fail? I agree that enabling already enabled service
> (same for disabled) should be a noop, but can there be some internal error?

Error should be expressed via D-Bus error system, not with an output 
parameter. Thus no return value is needed.

> What is the exact semantics of Enable and Disable? (see my other
> question about the enabled property below).

Modify either "services" or "domains" lists.

>> Added: Representing service objects on the bus
>
> I'm not sure about the 'enabled' boolean. How would you express a
> disabled service in sssd.conf? By having a section but not including the
> service in the 'services' list?

Yes. For domains respectively.

Note that we're planning on moving away
> from that model to one where any service and domain that would have a
> section would automatically be 'enabled'.

That we will need to change the code when this is done.

> When I started reading the document, I thought of 'enabling' a service
> as both creating the section and including the service name in the
> 'services' list. Then, when we obsolete the 'services' list, enabling a
> service would be the same as just creating the section.

At the moment you don't need to have the section created to enable the 
service, so it should just temper with the services list.

Just creating a section will not suffice, because you would need to 
delete the section to disable it will all set options. But that's 
another discussion. I need it to work with current SSSD. We will deal 
with new concept when it is current.

> How do you plan on dealing with options that are specific to a single service
> (ie PAM-specific options) ? Would there simply be another responder-specific
> property? I would be OK with that, I'm just trying to assess the plan.

Yes, responder specific properties sounds doable to me.

>> Added new properties: Representing domain objects on the bus
>
> I think we should add id_provider, auth_provider, access_provider etc to
> the list of default properties.

Yes. I'm thinking of array of key=value pairs so you don't have to amend 
the properties for every new provider. What do you think?

> Please use 'Array' instead of 'List', we should stick to the DBus
> nomenclature.

Done.




More information about the sssd-devel mailing list