[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sssd-devel
Subject:    Re: [SSSD] Design Discussion: Domains, users and groups over D-Bus
From:       Pavel Březina <pbrezina () redhat ! com>
Date:       2015-01-29 10:26:03
Message-ID: 54CA0ABB.9010301 () redhat ! com
[Download RAW message or body]

On 01/28/2015 08:56 PM, Jakub Hrozek wrote:
> On Wed, Jan 28, 2015 at 02:00:59PM -0500, Pavel Brezina wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Jakub Hrozek" <jhrozek@redhat.com>
> > > To: sssd-devel@lists.fedorahosted.org
> > > Sent: Wednesday, January 28, 2015 12:22:09 PM
> > > Subject: Re: [SSSD] Design Discussion: Domains, users and groups over D-Bus
> > > 
> > > On Wed, Jan 28, 2015 at 10:28:34AM +0100, Pavel Březina wrote:
> > > > On 01/14/2015 04:19 PM, Pavel Březina wrote:
> > > > > On 01/12/2015 03:51 PM, Pavel Březina wrote:
> > > > > > On 12/16/2014 02:26 PM, Pavel Březina wrote:
> > > > > > > https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
> > > > > > 
> > > > > > I created a new design page to reduce size and increase readability in
> > > > > > the original one. I would like to keep DBusResponder page mainly as a
> > > > > > crossroad with links to other pages in the future so it is not swamped
> > > > > > with too many details on everything.
> > > > > > 
> > > > > > I will replace user and group design in DBusResponder with the following
> > > > > > link if you agree:
> > > > > > 
> > > > > > https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
> > > > > > 
> > > > > > It should cover everything we agreed on. If not, please tell me and I
> > > > > > will add it.
> > > > > 
> > > > > New iteration is available at:
> > > > > https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
> > > > 
> > > > I think we should rethink the object paths. Currently it contains only $UID
> > > > information which should be unique across all domain. Therefore we relay on
> > > > sysdb_getpwuid, however, this function still requires domain.
> > > > 
> > > > We can either iterate over all domains and use the first match, or we can
> > > > add domain information into the object path:
> > > > 
> > > > /ifp/Users/$domain/$uid
> > > 
> > > Is it about the object path only?
> > > 
> > > From application perspective, the UID might be the only input data they have
> > > (think file ownership), we should provide a mean to retrieve a user
> > > based on this data only. The fact that we use 'domains' is not
> > > interesting for applications.
> > 
> > Yes, it is only about the domain path. The object path can be obtained by uid
> > search with Users.FindByID(id), not domain is required there.
> > 
> > We can iterate through all the domains in the getters, but having the domain as a \
> > part of an object path is simply more convenient. 
> > 
> > > I don't have a problem with adding domain to the path, after all, the
> > > user is not supposed to construct the paths himself, he ought to use the
> > > Find() methods. But I think we shouldn't require the domain to be an
> > > input parameter.
> > 
> > I'm also thinking about more complex and more object oriented interface usage. \
> > Something like: 
> > ifp.Users.ListByName on /ifp/Users
> > ifp.Users.ListByName on /ifp/$domain/Users
> > 
> > The later can replace ListByDomainAndName(domain, filter, limit) method.
> > 
> > User object path can then look like: /ifp/$domain/Users/$uid
> > 
> > But that is probably too complex and overthought. What do you think?
> 
> I don't think this is required, meh :-)
> 
> The only thing that comes to mind wrt the object path is that the object
> path might be the identifier that we use for object caching. But then I
> don't suppose subdomains can be renamed with the current code at all..

OK. I amended the design page to reflex /ifp/Users/$DOMAIN/$UID object path.

_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel


[prev in list] [next in list] [prev in thread] [next in thread]