The attached patch adds libsmbclient to the makefiles, in preparation for adding libsmbclient calls to the gpo-smb code. This patch depends on a previously submitted patch ("Add ad_gpo unit test"), which has not yet been pushed to master.
The InfoPipe code in master only supports a single interface per
responder, which obviously doesn't play well with our grand plans.
Pavel, I know you have different plans with multiple interfaces for the
public SBUS interfaces, but are you OK with pushing this patch to 1.12
and continuing with improvements later on? If so, please file a ticket
with some description so that we don't forget. Thanks!
The attached patch addresses a previous discussion about incorporating private samba functionality into the gpo code. The consensus was:
* Don't link to private samba libraries!
* If possible, use equivalent sssd functions
* Else, re-implement (i.e. essentially copy) the samba functions in the sssd codebase
There were three functions that the GPO code was using from libsamba-security, and this patch replaces them with sssd equivalents or samba re-implementations as follows:
* samba's string_to_sid() replaced with sss_idmap_sid_to_smb_sid()
* samba's dom_sid_equal() reimplemented in 35 lines
* samba's ndr_pull_security_descriptor() reimplemented in 445 lines (placed in separate ad_gpo_ndr.c file b/c of size)
This patch depends on a previously submitted patch ("AD: LDAP component of GPO-based access control"), which has not yet been pushed to master, but is expected to do so in the near future.
the attached patchset implement the
org.freedesktop.DBus.Properties.Get() interface for properties of
primitive types and arrays of primitive types (except for array of bools
as DBus bool is of different size than C-sized bool).
Getters are always synchronous, mostly to allow sane GetAll processing.
The getters also never error out, but rather return a default value.
The first two patches add utility functions, one by me and one by Pavel
that make it easier to return a primitive type or an array in a variant.
I wish the DBus library itself had a helper like this...
Patch 3/6 just allows the messages to be passed through to the IFP
The whole patchset is based on Stef's WIP branch and expands on it, that's
patch 4/6. There is a setter stub that, while not finished, is not
harmful either and can be expanded on later.
Patch 5/6 is the meat of the whole patchset. It implements the sbus
codegen to generate getter functions based on the XML description of the
interface and adds unit test for all the supported types and all
supported arrays. Pavel was kind enough to contribute several bugfixes
for this patch -- thank you!
Patch 6/6 is a bugfix by Pavel, one that I agree with, you can consider
the patch acked by me.
The next patch I'm going to send will implement a 'raw property getter'
that would allow the interface developer to return complex values for a
the attached patches add utility functions that allow the InfoPipe
responder to reply with an object path, escaped if needed.
The ifp_reply_objpath() function was initially in my tree, but Pavel
improved it quite a bit and fixed some bugs, so the patch should be
attributed to him. I'm also fine with his code...Pavel, can you
ack^Wreview the other two?
we have a segfault in master caused by the ldap attribute map extension
patches. The attached patch fixes the segfault.
I'm not happy with how the current sdap_attr_map is represented, so I
I would like to use getpwnam() to find the POSIX user for a given
Kerberos principal. To achieve this I have to change the
regular-expression we use to split the user name into name and domain
components because we use '@' as a delimiter here and Kerberos
principals contain an '@' as well.
My idea is to allow an '@' in the name part so that 'a@b@c' is split
into the name part 'a@b' and the domain part 'c'. A name containing an
'@' will then be considered as a Kerberos principal by SSSD and used
accordingly. If the domain is not known and the Kerberos principal
should be searched in all known domains a single '@' at the end, e.g.
'a@b@' shall indicate that the argument is a Kerberos principal.
I would like to know if you agree with this approach, if you have
concerns and other suggestions?
As a side node. While looking at this I found some oddities in the
current regular-expressions. E.g. currently '@' is not allowed in the
name part, but in the domain part when '@' is the separator. This leads
to a splitting of 'a@b@c' to name 'a' and domain 'b@c'. For AD-style
names with '\' as a separator '@' is allowed in names, i.e. 'a\b@c' will
be result in name 'b@c' and domain 'a' (so in theory I could use this
scheme to send a Kerberos principal to SSSD, but for me this looks even
stranger than my suggestion above, it hard to use on the command-line
and does not solve the case where the domain is not known). I will try
to fix those inconsistencies as well.
We had discussed doing a minor release for ding-libs in the May 2014 timeframe, which would include support for initializing ini_config from a memory buffer (which is useful for gpo-smb work). Is this still on track for May 2014?