URL: https://github.com/SSSD/sssd/pull/21 Title: #21: IFP: expose user and group unique IDs through DBus
jhrozek commented: """ On Tue, Sep 20, 2016 at 03:11:59AM -0700, Pavel Březina wrote: > On 09/19/2016 02:26 PM, tequeter wrote: > > Yes, I considered creating a |group_attributes| instead. However it > > would have taken more refactoring to avoid duplicating the > > |user_attributes| code than I was comfortable with for a first contribution. > > > > I went for uniqueID (GUID) instead of SIDs for three reasons: > > > > * |uniqueID| has a meaningful value both in IPA and AD, so it'll be > > useful to more users. > > * SIDs can change over time in multi-domain configurations. > > * GUIDs are supposedly world-unique, while SIDs can collide in forest > > configurations. > > I think we can accept this patch. > > user_attributes is meant mostly for custom attributes that are not > downloaded by sssd by default and sssd is not aware of their content. > Since this attribute is managed by sssd it is better to have control > over it by publishing it directly. > > It is also useful to have access to SID/GUID since it is far better > concept than UNIX ID No argument here :) > and we should make it easily accessible for > application developers. The only last thing I'm wondering is if there is any information leak in exposing these information. On one hand, the IFP interface is normally only accessible to root. On the other hand, currently it's all-or-nothing, right? We either publish all information or none... With the SIDs we already have a library thay pretty much anyone can call and retrieve the SID for ID. But not for GUIDs.. CC @sbose-rh for another opinion.. """ See the full comment at https://github.com/SSSD/sssd/pull/21#issuecomment-248272085
_______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
