[PATCH] IFP: Add GetUserAttrs call
by Jakub Hrozek
Hi,
the attached patches upstream functionality that mod_lookup_identity has
been using for a while, but which we couldn't push to master due to the
pending sbus changes. Now that these are accepted, it's time to merge
the DBus methods themselves. Previously, mod_lookup_identity relied on a
private branch with quite a bit of ad-hoc code.
Please note that when the work in progress to expose users, groups and
domains is merged as well, this interface will become obsolete in favor
of the objects. But we shouldn't let a released version of
mod_lookup_identity rely on unreleased sssd code any longer. Moreover,
all patches except the last one will be used even later on and there's
no fixed timeline on converting mod_lookup_identity.
[PATCH 1/6] SBUS: two trivial style fixes
SSIA
[PATCH 2/6] SBUS: Add a convenience function
Adds a convenience function that constructs a DBusError internally and
as such can be used to mark an sbus request as failed without having
to create a DBusError instance by the caller. The error message must be
either allocated on top of dbus_req or a constant, DBus itself doesn't
copy the error message! This is reflected in the doxygen docstring.
[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.
[PATCH 4/6] IFP: use a list of allowed_uids for authentication
Similar to the PAC responder, the InfoPipe uses a list of UIDs that are
allowed to communicate with the IFP responder.
[PATCH 5/6] IFP: Initialize negative cache timeout
In order to avoid hitting the back end with repetitive requests, the
InfoPipe responder needs a negative cache, too. This patch follows the
convention set by other responders, where the negative cache timeouts are
read from the [nss] section. This is not ideal, however, and ticket #2318
tracks moving the configuration to the [ifp] section primarily.
The timeout is also a separate parameter in the NSS context. We should
consider moving it to the negcache context instead (#2317).
[PATCH 6/6] IFP: Add GetUserAttrs call
Adds a DBus method that allows the caller to retrieve attributes of a
user. The synopsis of the call is as follows:
<method name="GetUserAttr">
<arg type="s" name="user" direction="in"/>
<arg type="as" name="attr" direction="in"/>
<arg type="a{sv}" name="values" direction="out"/>
</method>
The return value is an array (one attribute per array member) of
dictionaries. The key of the dictionary is the attribute name, the value
is a variant containing the attribute values as strings.
If an attribute does not exist or is not permitted to be read, no error
is returned. If the users does not exist, the method returns an error.
In future patches this function will be marked as obsolete in favor of
object-oriented approach.
ifp_user_get_attr_unpack_msg is a separate function to allow extending
it in a later patch.
The function to check the cache validity duplicates quite a bit of code
with the NSS responder. The refactoring would be nice to get done along
with #843. I have a patch in my private branch, but it's not complete,
sorry.
9 years, 11 months
[PATCH] SPEC: Remove duplicate sssd_ifp.
by Lukas Slebodnik
ehlo
I wanted to test dbus with sss(ifp responder). but I had a problem with
starting sssd. It was small problem with upstream packaging.
[sssd] [monitor_service_init] (0x0400): Initializing D-BUS Service
[sssd] [mt_svc_exit_handler] (0x0040): Child [ifp] exited with code [3]
[sssd] [mt_svc_exit_handler] (0x0010): Process [ifp], definitely stopped!
[sssd[ifp]] [sysbus_init] (0x0040): DBus error message: Connection ":1.522"
is not allowed to own the service "org.freedesktop.sssd.infopipe" due to
security policies in the configuration file
[sssd[ifp]] [ifp_process_init] (0x0020): Failed to connect to the system message bus
[sssd[ifp]] [sss_responder_ctx_destructor] (0x0400): Responder is being shut down
The file sssd_ifp was installed by two subpackages: sssd-common and sssd-dbus
I din't have instaled file org.freedesktop.sssd.infopipe.conf, because it is
in package sssd-dbus. Missing conf file caused problem with starting
the ifp service.
Simple patch is attached.
LS
9 years, 11 months
[PATCH] DBus: Automatic pack/unpack of method handler arguments
by Stef Walter
Here's the next set of DBus patches. This implements automatic packing
and unpacking of arguments for method handlers.
This means adding a handler to a vtable is now type safe and checked by
the compiler. Type safe reply xxx_finish() are also generated. Together
these avoid the complexity and the pitfalls of building and parsing DBus
messages via varargs (such as dbus_bool_t != bool).
Handlers have their pack/unpack method handlers automatically generated
unless they have this annotation in their DBus XML definition:
<annotation name="org.freedesktop.sssd.RawHandler" value="true"/>
Only simple argument types, and arrays of them are supported. More
complex arguments can continue to be handled via the "RawHandler"
annotation. sbus_codegen will force you to add this annotation for
methods that have complex arguments. In later work we could add commit
for more complex, but common arguments such as dictionaries.
Because so many of the internal sssd DBus methods do strange things with
their arguments, I haven't migrated them to automatic packing and
unpacking of arguments. They are all now marked with the above
"RawHandler" annotation. At some point someone could pick through these
and see which ones are candidates for moving away from "RawHandler".
You can find this as a branch here:
https://github.com/stefwalter/sssd/commits/dbus-invoke
Cheers,
Stef
9 years, 11 months
[PATCH] SBUS: Generate introspection from the interface meta
by Jakub Hrozek
The attached patch implements introspecting the sbus interfaces as
tracked by #2234.
There is one part of the patch I dislike, but I wanted to get other
opinions, too -- the discard_const in sbus_message_handler(). I was
going back and forth on whether sbus_introspect() should be an sbus
handler like the other handlers or whether I should special case it (and
then pass the interface directly and not through a void pointer).
Special casing the introspection might be a bit cleaner, but would cause
some duplication in sbus_message_handler().
The other question I have is whether there should be a way to mark an
interface as not introspectable? I can't think of a reason, so by
default all interfaces can be introspected.
The introspection also doesn't generate DocString annotations yet, I
will send a patch for that separately.
9 years, 11 months
[PATCH] Backport extending the LDAP maps to 1.11
by Jakub Hrozek
Hi,
this time it's not a straight cherry-pick but a rebase, because starting
with 1.10 the LDAP provider files were split bit differently. But the
code itself is the same, just moved elsewhere.
The attached patches also include fixes we found after we pushed the
original patches.
9 years, 11 months