| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Instead of passing just one interface with the functions, we need to
support multiple interfaces for the InfoPipe and export them all on the
sysbus.
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new method on the bus with the following synopsis:
<method name="GetUserGroups">
<arg name="user" type="s" direction="in" />
<arg name="values" type="as" direction="out"/>
</method>
Its purpose is to return names of groups the user is a member of as a
list of strings.
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Introduces a new option called user_attributes that allows to specify
which user attributes are allowed to be queried from the IFP responder.
By default only the default POSIX set is allowed, this option allows to
either add other attributes (+attrname) or remove them from the default
set (-attrname).
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Stef Walter <stefw@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Stef Walter <stefw@redhat.com>
|
|
|
|
|
|
|
|
| |
Similar to the PAC responder, the InfoPipe uses a list of UIDs that are
allowed to communicate with the IFP responder.
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Stef Walter <stefw@redhat.com>
|
|
|
|
|
|
|
|
|
| |
We need to retrieve caller IDs for each call from the system bus. This
commit adds a new SBUS connection type that identifies system bus
connection. The connection is used in the IFP provider.
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Stef Walter <stefw@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
There is no need for client socket in IFP responder,
since it uses D-Bus for communication with clients.
Resolves:
https://fedorahosted.org/sssd/ticket/2290
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
|
|
|
|
|
|
|
|
|
| |
Related:
https://fedorahosted.org/sssd/ticket/2072
Adds the possibility for the InfoPipe responder to connect to the system bus.
At the moment, only a dummy method "Ping" is provided. The method only
accepts a single string parameter that has to be 'ping'.
|
|
Related:
https://fedorahosted.org/sssd/ticket/2072
This commit only adds the responder and the needed plumbing. No DBus
related code is in yet.
|