[SSSD] [PATCH] IFP: Add GetUserAttrs call

Stef Walter stefw at redhat.com
Fri Apr 25 08:34:58 UTC 2014


On 24.04.2014 13:24, Jakub Hrozek wrote:
> On Thu, Apr 24, 2014 at 12:59:45PM +0200, Stef Walter wrote:
>>> [PATCH 3/6] IFP: Add utility functions Adds a number of utility
>>> functions, most importanly ifp_req_create(). The ifp_req is a
>>> structure that will be passed along with the ifp request and contains
>>> the sbus request and some ifp-specific data, like caller ID or the
>>> responder context.
>>
>> dbus_bus_get_unix_user() blocks. Is that fine in this case?
>>
>> What we really want is to be able to get this information asyncronously
>> and fill it in the sbus_request before dispatching a given method call
>> to the handler. We would also cache this information on sbus_connection.
> 
> Hi Stef,
> 
> thanks a lot for the review!
> 
> Do you know if dbus_bus_get_unix_user does any Name Service Switch calls
> that could potentially go over network? Blocking on local IO would be OK
> I think, but not if we risk blocking on network IO.
> 
> Can you suggest how should I get the UID info asynchronously? I agree
> with the rest of your comments and will fix the issues..

If you look at dbus_bus_get_unix_user, it's just running a DBus method
calling to the system bus.

So essentially you would do this in the sssd_dbus_connection dispatch
code. If you don't have unix credentials for the sender cached, then you
perform that DBus method call back to the bus asking for it, get it,
cache it, and only then dispatch the method.

kdbus fixes this. But until then this is the robust way to accomplish this.

I imagine sssd_dbus_connection would have a flag saying whether it's
running on the system bus or not. And would enable this behavior.

Stef



More information about the sssd-devel mailing list