URL: https://github.com/SSSD/sssd/pull/21
Title: #21: IFP: expose user and group unique IDs through DBus

pbrezina commented:
On 09/20/2016 01:13 PM, Jakub Hrozek wrote:
> 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...

AFAIK we use whitelist for user attributes.

> 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 
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

Reply via email to