[PATCH] AUTOFS: terminate array after the last entry
by Lukas Slebodnik
ehlo,
If LDAP entries have more then one attribute "automountKey"
automount map will be skipped and error message will be printed to log files
and sssd_be will crash.
DEBUG(SSSDBG_MINOR_FAILURE, "Malformed entry, skipping\n");
The output array with automount maps will contain uninitialized pointers
because array was terminated after the expected count of entries and not
after the last successfully retrieved entry
Resolves:
https://fedorahosted.org/sssd/ticket/2288
How to reproduce crash?
You need to have more than two automountKey attributes in LDAP entry
for automount map.
Attached patch fix crash only in sssd_be. (There was another crash
in automount client)
LS
10 years
[PATCH] Re-add the InfoPipe server plumbing
by Jakub Hrozek
Hi,
I've been working on re-adding a public DBus API to SSSD lately, based on
Stephen's InfoPipe code. While I'm not finished yet, the interface is also
important to Pavel's OpenLMI thesis, so I'll be sending the patches for
review as the individual subtasks are finished and rebased on top of Stef's
recent patches.
Attached are two patches that I think are ready to be reviewed and merged
with some minor exceptions or questions. The review would be a good
opportunity to solve those.
[PATCH 1/2] IFP: Re-add the InfoPipe server
This commit only adds the responder and the needed plumbing. No DBus
related code is in yet.
With this patch, I was wondering whether to build the code by default, or
only when --enable-experimental-features is set until the whole feature is
finished?
Also, with the current code, all responders spawn a client socket now, but
this responder listens on the system bus instead. I created
https://fedorahosted.org/sssd/ticket/2290 for this purpose -- Pavel, feel
free to take it.
[PATCH 2/2] IFP: Connect to the system bus
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'.
To test, you can call the Ping method like this:
dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe
/org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.Ping
'string:Ping'
Or test that the code can catch wrong options:
dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe
/org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.Ping
'string:sdf'
I'll be sending next round of patches later this week. Hopefully this would
unblock Pavel's work.
10 years
Planning the 1.11.5 release
by Jakub Hrozek
I think the 1.11 branch has accumulated a critical mass of fixes, so I'd
like to release 1.11.5 on Monday (to let the dust settle a bit).
Is anyone opposed to that idea?
The only remaining fix I'd like to see in is #2293 which Lukas has a
patch for.
10 years
[PATCH] Download the list of subdomains from the forest root
by Jakub Hrozek
Hi,
as described in https://fedorahosted.org/sssd/ticket/2285, we need to
download the list of trusted domains from the forest root, because only
the forest root knows the full list of domains. The leafs only store
itself and the forest root.
Initially, I wanted to use the Global Catalog, but it turned out not all
attributes we care about are present in the GC, such as the flatName. So
the attached patch connects directly to the LDAP port of the forest root
in case the SSSD is not enrolled with a forest root already.
There is one bit of code duplication that both callers
of ad_subdom_ad_ctx_new set the newly created ad_id_ctx as a pvt
pointer of the sdap domain on success. Initially I moved that logic
to ad_subdom_ad_ctx_new but later I realized that the sdom handling in
ad_subdom_ad_ctx_new is strange (we just read the sdom from the newly
created ad_id_ctx, not from the 'parent' and never use it afterwards..) and
I'd like to fix this properly with a follow up patch.
Thanks for review.
10 years