[SSSD] Design Discussion: D-Bus responder

Jakub Hrozek jhrozek at redhat.com
Fri Apr 18 15:09:04 UTC 2014


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.

> Added: Representing SSSD configuration

* '''property''' Uint32 debug_level 
    * The name of this service. 

This ^^^^ sounds like a typo.

* '''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.

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

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?

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

> 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? 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'.

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.

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.

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

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

Thanks for the changes!



More information about the sssd-devel mailing list