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 05:24:45AM -0700, sumit-bose wrote:
> > 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..
> In general the GUIDs are even less informative than the SID, e.g. you cannot 
> derive the domain form it, it is just a random strings created with some 
> rules to try to avoid collisions. So I cannot see a leak here. Additionally I 
> think there is only special protection on the LDAP side on the GUID 
> attribute, e.g.  ipaUniqueID can be read anonymously.
> Only if the GUID is misused, e.g. as initial password, there would be an 
> issue but imo not on our side. 

Thank you.

Then I don't see a reason to not accept this PR. I tested it and it
seems to work:

$ dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe
org.freedesktop.sssd.infopipe.Users.FindByName string:ad...@ipa.test   
method return time=1474453460.862332 sender=:1.305 -> destination=:1.308 
serial=9 reply_serial=2
object path "/org/freedesktop/sssd/infopipe/Users/ipa_2etest/935600000"

$ dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe
string:org.freedesktop.sssd.infopipe.Users.User string:uniqueID
method return time=1474453484.184180 sender=:1.305 -> destination=:1.309 
serial=11 reply_serial=2
variant       string "4e80c946-436e-11e6-8fbd-525400f71478"

If anyone thinks having group_attributes should block this PR, I'm OK
with implementing it..

So I'll just wait a bit to see if there is any opposition and if not,
I'll push the patch..


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