Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On Thu, 09 Oct 2014, Martin Kosek wrote: On 10/09/2014 01:02 PM, Alexander Bokovoy wrote: On Thu, 09 Oct 2014, Alexander Bokovoy wrote: On Thu, 09 Oct 2014, Martin Kosek wrote: On 10/09/2014 09:33 AM, Ludwig Krispenz wrote: all the issues I found are fixed, for me it's ACK On 10/08/2014 07:50 PM, Alexander Bokovoy wrote: On Tue, 07 Oct 2014, Ludwig Krispenz wrote: Hi Alex, I have a question regarding cbdata.target. It is/was a reference to the pblock used to generate a new dn, but now in idview_replace_target_dn(&cbdata.target,...) it can be newly allocated and should be freed, so I think there should be a return code indicating if it was allocated or not. Yes, good catch. I've fixed this and other issues raised in the review. I also fixed an issue with an initial lookup by an override. If someone does a search by an override, we would replace uid|cn= by uid= if it exists and by otherwise -- for groups we don't have ipaOriginalUid as they don't have uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if there is no entry in the map cache, the search will return nothing, the entry will be staged for lookup through SSSD. In the original version lookup in SSSD didn't take ipaAnchorUUID into account, so the entry would not be found at all. I did add a call to do sid2name first and then use the name to perform actual SSSD lookup. Works nicely now. New patch for slapi-nis is attached. Great! What is the next step? If Nalin (CCed) is OK with the slapi-nis changes as well, it would be great to have that pushed there. Alexander, do you plan to do any other changes in slapi-nis in scope of FreeIPA 4.1? When the changes are ready, it would be nice to get slapi-nis released so that we can bump FreeIPA slapi-nis requires. No more changes are planned right now. If Nalin would grant me write access to slapi-nis.git on fedorahosted.org, I can handle release in Fedora already. Never say never. The moment I've sent this email, I've realized I need to fix https://bugzilla.redhat.com/show_bug.cgi?id=1130131 The patch is sent in a separate email. Seen that, thanks! BTW what about #4435 Trusted AD users are not resovable in netgroups #4403 [RFE] compat tree: show AD members of IPA groups do you see this also as something that would fit in slapi-nis in 4.1? I don't think I'll be able to fix them before 4.1. Netgroups support requires to create additional configuration and in theory could be simple but needs a lot of care (escaping of embedded string delimiters). Additionally, netgroups will not yet work with views properly, this is something that requires more time. AD members of IPA groups needs more work too as we have no means yet to pick up and resolve ipaExternalMember in slapi-nis. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On 10/09/2014 01:02 PM, Alexander Bokovoy wrote: > On Thu, 09 Oct 2014, Alexander Bokovoy wrote: >> On Thu, 09 Oct 2014, Martin Kosek wrote: >>> On 10/09/2014 09:33 AM, Ludwig Krispenz wrote: all the issues I found are fixed, for me it's ACK On 10/08/2014 07:50 PM, Alexander Bokovoy wrote: > On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >> Hi Alex, >> >> I have a question regarding cbdata.target. It is/was a reference to the >> pblock used to generate a new dn, but now in >> idview_replace_target_dn(&cbdata.target,...) it can be newly allocated >> and >> should be freed, so I think there should be a return code indicating if >> it >> was allocated or not. > Yes, good catch. > > I've fixed this and other issues raised in the review. > > I also fixed an issue with an initial lookup by an override. If someone > does a search by an override, we would replace uid|cn= by > uid= if it exists and by > otherwise -- for groups we don't have ipaOriginalUid as they don't have > uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if > there is no entry in the map cache, the search will return nothing, the > entry will be staged for lookup through SSSD. > > In the original version lookup in SSSD didn't take ipaAnchorUUID into > account, so the entry would not be found at all. I did add a call to > do sid2name first and then use the name to perform actual SSSD lookup. > > Works nicely now. > > New patch for slapi-nis is attached. >>> >>> Great! What is the next step? If Nalin (CCed) is OK with the slapi-nis >>> changes >>> as well, it would be great to have that pushed there. >>> >>> Alexander, do you plan to do any other changes in slapi-nis in scope of >>> FreeIPA >>> 4.1? When the changes are ready, it would be nice to get slapi-nis released >>> so >>> that we can bump FreeIPA slapi-nis requires. >> No more changes are planned right now. If Nalin would grant me write >> access to slapi-nis.git on fedorahosted.org, I can handle release in Fedora >> already. > Never say never. The moment I've sent this email, I've realized I need > to fix https://bugzilla.redhat.com/show_bug.cgi?id=1130131 > > The patch is sent in a separate email. Seen that, thanks! BTW what about #4435 Trusted AD users are not resovable in netgroups #4403 [RFE] compat tree: show AD members of IPA groups do you see this also as something that would fit in slapi-nis in 4.1? Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On Thu, 09 Oct 2014, Alexander Bokovoy wrote: On Thu, 09 Oct 2014, Martin Kosek wrote: On 10/09/2014 09:33 AM, Ludwig Krispenz wrote: all the issues I found are fixed, for me it's ACK On 10/08/2014 07:50 PM, Alexander Bokovoy wrote: On Tue, 07 Oct 2014, Ludwig Krispenz wrote: Hi Alex, I have a question regarding cbdata.target. It is/was a reference to the pblock used to generate a new dn, but now in idview_replace_target_dn(&cbdata.target,...) it can be newly allocated and should be freed, so I think there should be a return code indicating if it was allocated or not. Yes, good catch. I've fixed this and other issues raised in the review. I also fixed an issue with an initial lookup by an override. If someone does a search by an override, we would replace uid|cn= by uid= if it exists and by otherwise -- for groups we don't have ipaOriginalUid as they don't have uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if there is no entry in the map cache, the search will return nothing, the entry will be staged for lookup through SSSD. In the original version lookup in SSSD didn't take ipaAnchorUUID into account, so the entry would not be found at all. I did add a call to do sid2name first and then use the name to perform actual SSSD lookup. Works nicely now. New patch for slapi-nis is attached. Great! What is the next step? If Nalin (CCed) is OK with the slapi-nis changes as well, it would be great to have that pushed there. Alexander, do you plan to do any other changes in slapi-nis in scope of FreeIPA 4.1? When the changes are ready, it would be nice to get slapi-nis released so that we can bump FreeIPA slapi-nis requires. No more changes are planned right now. If Nalin would grant me write access to slapi-nis.git on fedorahosted.org, I can handle release in Fedora already. Never say never. The moment I've sent this email, I've realized I need to fix https://bugzilla.redhat.com/show_bug.cgi?id=1130131 The patch is sent in a separate email. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On Thu, 09 Oct 2014, Martin Kosek wrote: On 10/09/2014 09:33 AM, Ludwig Krispenz wrote: all the issues I found are fixed, for me it's ACK On 10/08/2014 07:50 PM, Alexander Bokovoy wrote: On Tue, 07 Oct 2014, Ludwig Krispenz wrote: Hi Alex, I have a question regarding cbdata.target. It is/was a reference to the pblock used to generate a new dn, but now in idview_replace_target_dn(&cbdata.target,...) it can be newly allocated and should be freed, so I think there should be a return code indicating if it was allocated or not. Yes, good catch. I've fixed this and other issues raised in the review. I also fixed an issue with an initial lookup by an override. If someone does a search by an override, we would replace uid|cn= by uid= if it exists and by otherwise -- for groups we don't have ipaOriginalUid as they don't have uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if there is no entry in the map cache, the search will return nothing, the entry will be staged for lookup through SSSD. In the original version lookup in SSSD didn't take ipaAnchorUUID into account, so the entry would not be found at all. I did add a call to do sid2name first and then use the name to perform actual SSSD lookup. Works nicely now. New patch for slapi-nis is attached. Great! What is the next step? If Nalin (CCed) is OK with the slapi-nis changes as well, it would be great to have that pushed there. Alexander, do you plan to do any other changes in slapi-nis in scope of FreeIPA 4.1? When the changes are ready, it would be nice to get slapi-nis released so that we can bump FreeIPA slapi-nis requires. No more changes are planned right now. If Nalin would grant me write access to slapi-nis.git on fedorahosted.org, I can handle release in Fedora already. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On 10/09/2014 09:33 AM, Ludwig Krispenz wrote: > all the issues I found are fixed, for me it's ACK > > On 10/08/2014 07:50 PM, Alexander Bokovoy wrote: >> On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >>> Hi Alex, >>> >>> I have a question regarding cbdata.target. It is/was a reference to the >>> pblock used to generate a new dn, but now in >>> idview_replace_target_dn(&cbdata.target,...) it can be newly allocated and >>> should be freed, so I think there should be a return code indicating if it >>> was allocated or not. >> Yes, good catch. >> >> I've fixed this and other issues raised in the review. >> >> I also fixed an issue with an initial lookup by an override. If someone >> does a search by an override, we would replace uid|cn= by >> uid= if it exists and by >> otherwise -- for groups we don't have ipaOriginalUid as they don't have >> uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if >> there is no entry in the map cache, the search will return nothing, the >> entry will be staged for lookup through SSSD. >> >> In the original version lookup in SSSD didn't take ipaAnchorUUID into >> account, so the entry would not be found at all. I did add a call to >> do sid2name first and then use the name to perform actual SSSD lookup. >> >> Works nicely now. >> >> New patch for slapi-nis is attached. Great! What is the next step? If Nalin (CCed) is OK with the slapi-nis changes as well, it would be great to have that pushed there. Alexander, do you plan to do any other changes in slapi-nis in scope of FreeIPA 4.1? When the changes are ready, it would be nice to get slapi-nis released so that we can bump FreeIPA slapi-nis requires. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
all the issues I found are fixed, for me it's ACK On 10/08/2014 07:50 PM, Alexander Bokovoy wrote: On Tue, 07 Oct 2014, Ludwig Krispenz wrote: Hi Alex, I have a question regarding cbdata.target. It is/was a reference to the pblock used to generate a new dn, but now in idview_replace_target_dn(&cbdata.target,...) it can be newly allocated and should be freed, so I think there should be a return code indicating if it was allocated or not. Yes, good catch. I've fixed this and other issues raised in the review. I also fixed an issue with an initial lookup by an override. If someone does a search by an override, we would replace uid|cn= by uid= if it exists and by otherwise -- for groups we don't have ipaOriginalUid as they don't have uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if there is no entry in the map cache, the search will return nothing, the entry will be staged for lookup through SSSD. In the original version lookup in SSSD didn't take ipaAnchorUUID into account, so the entry would not be found at all. I did add a call to do sid2name first and then use the name to perform actual SSSD lookup. Works nicely now. New patch for slapi-nis is attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On Tue, 07 Oct 2014, Ludwig Krispenz wrote:
Hi Alex,
I have a question regarding cbdata.target. It is/was a reference to
the pblock used to generate a new dn, but now in
idview_replace_target_dn(&cbdata.target,...) it can be newly allocated
and should be freed, so I think there should be a return code
indicating if it was allocated or not.
Yes, good catch.
I've fixed this and other issues raised in the review.
I also fixed an issue with an initial lookup by an override. If someone
does a search by an override, we would replace uid|cn= by
uid= if it exists and by
otherwise -- for groups we don't have ipaOriginalUid as they don't have
uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if
there is no entry in the map cache, the search will return nothing, the
entry will be staged for lookup through SSSD.
In the original version lookup in SSSD didn't take ipaAnchorUUID into
account, so the entry would not be found at all. I did add a call to
do sid2name first and then use the name to perform actual SSSD lookup.
Works nicely now.
New patch for slapi-nis is attached.
--
/ Alexander Bokovoy
From 1c2e7caa3e1c11cc0bc0d8477a0c27308ca8506b Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy
Date: Tue, 29 Jul 2014 12:04:34 +0300
Subject: [PATCH] Add support for FreeIPA ID views
FreeIPA ID views allow to override POSIX attributes for certain
users and groups.
A support is added to allow using specific ID view when serving
compatibility tree. Each user or group entry which has an override
in the view is amended with the overridden values from the view
before served out to the LDAP client.
A view to use is specified as a part of base DN:
cn=,cn=views,cn=compat,$SUFFIX
where cn=compat,$SUFFIX is the original compatibility tree base DN.
Each entry, when served through the view, gets new DN rewritten to
specify the view. Additionally, if override in the view changes
uid (for users) or cn (for groups) attribute, the entry's RDN is changed
accordingly.
For groups memberUid attribute is modified as well in case there is an override
in the view that changes uid value of that member.
FreeIPA ID views support overrides for users of trusted Active Directory
domains.
In case of a trusted AD domain's user or group is returned via compatibility
tree,
view overrides are applied in two stages:
1. SSSD applies default view for AD users
2. slapi-nis applies explicitly specified (host-specific) view
on top of the entry returned by SSSD
Thus, slapi-nis does not need to apply default view for AD users and if there
are
no host-specific views in use, there is no need to specify a view in the base
DN,
making overhead of a default view for AD users lower.
---
configure.ac | 14 ++
doc/ipa/sch-ipa.txt | 93
src/Makefile.am | 4 +
src/back-sch-idview.c | 392 ++
src/back-sch-nss.c| 111 +++---
src/back-sch.c| 71 +++--
src/back-sch.h| 38 +
7 files changed, 692 insertions(+), 31 deletions(-)
create mode 100644 src/back-sch-idview.c
diff --git a/configure.ac b/configure.ac
index 84b84d1..71dbdc7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -383,6 +383,20 @@ if test "x$use_nsswitch" != xno ; then
AC_DEFINE(USE_NSSWITCH,1,[Use nsswitch API to lookup users and groups
not found in the LDAP tree])
fi
+use_idviews=true
+AC_ARG_WITH(idviews,
+ AS_HELP_STRING([--with-idviews], [Use FreeIPA ID views to override
POSIX IDs of users and groups]),
+ use_idviews=$withval,use_idviews=yes)
+if test "x$use_idviews" = xyes ; then
+ AC_MSG_RESULT([FreeIPA ID views support is enabled])
+ AC_DEFINE(USE_IPA_IDVIEWS,1,[Use FreeIPA ID views to override POSIX
attributes of users and groups per view.])
+ AC_DEFINE(IPA_IDVIEWS_ATTR_ANCHORUUID, ["ipaAnchorUUID"],[FreeIPA attr
unique pointer for id overrides])
+ AC_DEFINE(IPA_IDVIEWS_ATTR_ORIGINALUID, ["ipaOriginalUid"],[FreeIPA
attr original uid value for user id overrides])
+else
+ AC_MSG_RESULT([FreeIPA ID views support is disabled])
+fi
+AM_CONDITIONAL([USE_IPA_IDVIEWS], [test "x$use_idviews" != xno])
+
mylibdir=`eval echo "$libdir" | sed "s,NONE,${ac_default_prefix},g"`
mylibdir=`eval echo "$mylibdir" | sed "s,NONE,${ac_prefix},g"`
case "$server" in
diff --git a/doc/ipa/sch-ipa.txt b/doc/ipa/sch-ipa.txt
index b5a585b..f560580 100644
--- a/doc/ipa/sch-ipa.txt
+++ b/doc/ipa/sch-ipa.txt
@@ -87,3 +87,96 @@ on IPA masters.
As 'system-auth' PAM service is not used directly by any other application, it
is safe to use it for trusted domain users via compatibility path.
+
+== Support for ID views ==
+
+When FreeIPA 4.1 is in use, Schema compatibility plugin can be configured to
+override POSIX attributes according to an identity view (ID View) which
+contains overrides for users and groups.
+
+The overrides are managed by FreeIPA separately for users and groups:
+
+* managem
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
Hi Alex, I have a question regarding cbdata.target. It is/was a reference to the pblock used to generate a new dn, but now in idview_replace_target_dn(&cbdata.target,...) it can be newly allocated and should be freed, so I think there should be a return code indicating if it was allocated or not. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On 10/07/2014 05:00 PM, Alexander Bokovoy wrote: On Tue, 07 Oct 2014, thierry bordaz wrote: On 10/01/2014 06:16 PM, Alexander Bokovoy wrote: Hi! Attached are patches to add support of FreeIPA ID views to Schema compatibility plugin (slapi-nis). There are two patches for FreeIPA and a separate patch for slapi-nis. Patches can be applied independently; if old slapi-nis is installed, it will simply work with new configuration but do nothing with respect to answering to requests using host-specific ID views. I included documentation on how slapi-nis ID views feature supposed to work, available in slapi-nis/doc/ipa/ipa-sch.txt. Any comments and fixes are welcome. There are no additional tests in slapi-nis to cover compat trees, we have multiple tests in FreeIPA for this purpose, will be run as part of FreeIPA CI effort. FreeIPA patches add ACIs for accessing ID view-applied entries over compat tree. They also include additional configuration; this configuration is needed to properly resolve ID view overrides when creating compat entries. A second FreeIPA patch adds support to override login shell. This part was missing from the original patchset by Tomas. For trusted AD users one needs patches to SSSD 1.12.2, made by Sumit Bose. There is also a regression (fixed by Sumit as well) that prevents authentication of AD users over PAM which affects authentication over compat tree. With the patch from Sumit authentication works again, both with ID view and without it. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hi Alexander, Just a minor remark about idview_get_overrides. It does an internal search of the views and keep the returned views into cbdata->overrides. Later the entries will be freed. Internal search may also return referral arrays (usually freed by slapi_free_search_results_internal). In case cn=views container contains referral entries you may need to free them. What would be a reason to return these referrals in IPA case? This code is IPA-specific and we don't have any referrals for the tree or backend we are dealing with. I agree it would be good to do in general but how that is relevant to the specific use case? You are right, this is IPA-specific and we control the fact that there is no referral entries there. Also, I have a concern about performance. My understanding is that for each search, backend_search_cb allocates a new cbdata with uninitialized 'overrides'. So it will trigger the internal search idview_get_overrides. Most of the time those overrides rules have not been updated, so idview_get_overrides will retrieve the same entries. Wouldn't it be possible to 'cache' those entries (to prevent the internal search), and just clear those entries if a mod/add/del happen one them ? I was thinking about using this approach but rejected it for several reasons, primary due to lack of development time. We can do a lot of refactoring on how slapi-nis currently uses RAM to store all compat entries at the same time; the current approach with ID overrides tries to not complicate that logic. We agreed with Simo to do performance optimizations at a later stage. Ok. I fully agree. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On Tue, 07 Oct 2014, thierry bordaz wrote: On 10/01/2014 06:16 PM, Alexander Bokovoy wrote: Hi! Attached are patches to add support of FreeIPA ID views to Schema compatibility plugin (slapi-nis). There are two patches for FreeIPA and a separate patch for slapi-nis. Patches can be applied independently; if old slapi-nis is installed, it will simply work with new configuration but do nothing with respect to answering to requests using host-specific ID views. I included documentation on how slapi-nis ID views feature supposed to work, available in slapi-nis/doc/ipa/ipa-sch.txt. Any comments and fixes are welcome. There are no additional tests in slapi-nis to cover compat trees, we have multiple tests in FreeIPA for this purpose, will be run as part of FreeIPA CI effort. FreeIPA patches add ACIs for accessing ID view-applied entries over compat tree. They also include additional configuration; this configuration is needed to properly resolve ID view overrides when creating compat entries. A second FreeIPA patch adds support to override login shell. This part was missing from the original patchset by Tomas. For trusted AD users one needs patches to SSSD 1.12.2, made by Sumit Bose. There is also a regression (fixed by Sumit as well) that prevents authentication of AD users over PAM which affects authentication over compat tree. With the patch from Sumit authentication works again, both with ID view and without it. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hi Alexander, Just a minor remark about idview_get_overrides. It does an internal search of the views and keep the returned views into cbdata->overrides. Later the entries will be freed. Internal search may also return referral arrays (usually freed by slapi_free_search_results_internal). In case cn=views container contains referral entries you may need to free them. What would be a reason to return these referrals in IPA case? This code is IPA-specific and we don't have any referrals for the tree or backend we are dealing with. I agree it would be good to do in general but how that is relevant to the specific use case? Also, I have a concern about performance. My understanding is that for each search, backend_search_cb allocates a new cbdata with uninitialized 'overrides'. So it will trigger the internal search idview_get_overrides. Most of the time those overrides rules have not been updated, so idview_get_overrides will retrieve the same entries. Wouldn't it be possible to 'cache' those entries (to prevent the internal search), and just clear those entries if a mod/add/del happen one them ? I was thinking about using this approach but rejected it for several reasons, primary due to lack of development time. We can do a lot of refactoring on how slapi-nis currently uses RAM to store all compat entries at the same time; the current approach with ID overrides tries to not complicate that logic. We agreed with Simo to do performance optimizations at a later stage. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On 10/01/2014 06:16 PM, Alexander Bokovoy wrote: Hi! Attached are patches to add support of FreeIPA ID views to Schema compatibility plugin (slapi-nis). There are two patches for FreeIPA and a separate patch for slapi-nis. Patches can be applied independently; if old slapi-nis is installed, it will simply work with new configuration but do nothing with respect to answering to requests using host-specific ID views. I included documentation on how slapi-nis ID views feature supposed to work, available in slapi-nis/doc/ipa/ipa-sch.txt. Any comments and fixes are welcome. There are no additional tests in slapi-nis to cover compat trees, we have multiple tests in FreeIPA for this purpose, will be run as part of FreeIPA CI effort. FreeIPA patches add ACIs for accessing ID view-applied entries over compat tree. They also include additional configuration; this configuration is needed to properly resolve ID view overrides when creating compat entries. A second FreeIPA patch adds support to override login shell. This part was missing from the original patchset by Tomas. For trusted AD users one needs patches to SSSD 1.12.2, made by Sumit Bose. There is also a regression (fixed by Sumit as well) that prevents authentication of AD users over PAM which affects authentication over compat tree. With the patch from Sumit authentication works again, both with ID view and without it. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hi Alexander, Just a minor remark about idview_get_overrides. It does an internal search of the views and keep the returned views into cbdata->overrides. Later the entries will be freed. Internal search may also return referral arrays (usually freed by slapi_free_search_results_internal). In case cn=views container contains referral entries you may need to free them. Also, I have a concern about performance. My understanding is that for each search, backend_search_cb allocates a new cbdata with uninitialized 'overrides'. So it will trigger the internal search idview_get_overrides. Most of the time those overrides rules have not been updated, so idview_get_overrides will retrieve the same entries. Wouldn't it be possible to 'cache' those entries (to prevent the internal search), and just clear those entries if a mod/add/del happen one them ? thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On 10/07/2014 01:32 PM, Alexander Bokovoy wrote:
On Tue, 07 Oct 2014, Alexander Bokovoy wrote:
On Tue, 07 Oct 2014, Ludwig Krispenz wrote:
On 10/07/2014 12:39 PM, Alexander Bokovoy wrote:
On Tue, 07 Oct 2014, Ludwig Krispenz wrote:
On 10/07/2014 12:12 PM, Alexander Bokovoy wrote:
On Tue, 07 Oct 2014, Ludwig Krispenz wrote:
Hi Alex,
slapi_attr_set_valueset() calls slapi_valueset_set_valueset(),
but this does not free the existing values,
Here is the problem, I cannot free original values as
slapi_attr_get_valueset() returns a copy and I never can get
access to
the original Slapi_ValueSet.
good point.
I only can get access to the original Slapi_Value** array which
means I
could manipulate its content but that probably require resizing
it and
thus changing a pointer vs->va, to which I don't have access anyway.
you should never do this, a valueset contains more data than va
How can we fix this?
the best thing would probably be to fix slapi_attr_set_valueset or
adding a new api function which frees teh old valueset, but this
would add a dependency to specific DS version
What about something like this:
void
slapi_valueset_set_valueset(Slapi_ValueSet *vs1, const Slapi_ValueSet
*vs2)
{
if ((vs1 != NULL) && (vs1->num != 0)) {
slapi_valueset_done(vs1);
}
slapi_valueset_init(vs1);
valueset_set_valueset(vs1,vs2);
}
Another option is to fix slapi_attr_set_valueset():
int
slapi_attr_set_valueset(Slapi_Attr *a, const Slapi_ValueSet *vs)
{
if (a->a_present_values->num != 0) {
lapi_valueset_done(&a->a_present_values);
}
slapi_valueset_set_valueset( &a->a_present_values, vs);
return 0;
}
Other uses of slapi_valueset_set_valueset() are operating on newly
created Slapi_ValueSet instances.
both will be ok (for me), but we have to commit it first and you
depend on that version.
a more clumsy way would be to get the values and then use
slapi_entry_attr_replace_sv() which would free the attr and recreate it
Actually, you pointed me to a better solution:
/* Replace the attribute's value with the override */
result = slapi_entry_attr_exists(entry, override_type);
if (result == 0) {
result = slapi_attr_get_values(override_attr, &override_valueset);
result = slapi_entry_attr_delete_sv(entry, override_type, NULL);
result = slapi_entry_add_valueset(entry, override_type,
override_valueset);
}
slapi_entry_delete_values_sv(entry, attr, NULL) will clear whole
attribute and then I can add the valueset. This, unfortunately, works
via iterating over the whole valueset and adding values one by one but
in our case it would be most likely a single element anyway.
Pasted a lot of typos but fixed it already:
result = slapi_entry_attr_exists(entry, override_type);
if (result == 0) {
result = slapi_attr_get_valueset(override_attr,
&override_valueset);
result = slapi_entry_attr_delete(entry, override_type);
result = slapi_entry_add_valueset(entry, override_type,
override_valueset);
}
ok
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On Tue, 07 Oct 2014, Alexander Bokovoy wrote:
On Tue, 07 Oct 2014, Ludwig Krispenz wrote:
On 10/07/2014 12:39 PM, Alexander Bokovoy wrote:
On Tue, 07 Oct 2014, Ludwig Krispenz wrote:
On 10/07/2014 12:12 PM, Alexander Bokovoy wrote:
On Tue, 07 Oct 2014, Ludwig Krispenz wrote:
Hi Alex,
slapi_attr_set_valueset() calls
slapi_valueset_set_valueset(), but this does not free the
existing values,
Here is the problem, I cannot free original values as
slapi_attr_get_valueset() returns a copy and I never can get access to
the original Slapi_ValueSet.
good point.
I only can get access to the original Slapi_Value** array which means I
could manipulate its content but that probably require resizing it and
thus changing a pointer vs->va, to which I don't have access anyway.
you should never do this, a valueset contains more data than va
How can we fix this?
the best thing would probably be to fix slapi_attr_set_valueset
or adding a new api function which frees teh old valueset, but
this would add a dependency to specific DS version
What about something like this:
void
slapi_valueset_set_valueset(Slapi_ValueSet *vs1, const Slapi_ValueSet
*vs2)
{
if ((vs1 != NULL) && (vs1->num != 0)) {
slapi_valueset_done(vs1);
}
slapi_valueset_init(vs1);
valueset_set_valueset(vs1,vs2);
}
Another option is to fix slapi_attr_set_valueset():
int
slapi_attr_set_valueset(Slapi_Attr *a, const Slapi_ValueSet *vs)
{
if (a->a_present_values->num != 0) {
lapi_valueset_done(&a->a_present_values);
}
slapi_valueset_set_valueset( &a->a_present_values, vs);
return 0;
}
Other uses of slapi_valueset_set_valueset() are operating on newly
created Slapi_ValueSet instances.
both will be ok (for me), but we have to commit it first and you
depend on that version.
a more clumsy way would be to get the values and then use
slapi_entry_attr_replace_sv() which would free the attr and recreate
it
Actually, you pointed me to a better solution:
/* Replace the attribute's value with the override */
result = slapi_entry_attr_exists(entry, override_type);
if (result == 0) {
result = slapi_attr_get_values(override_attr, &override_valueset);
result = slapi_entry_attr_delete_sv(entry, override_type, NULL);
result = slapi_entry_add_valueset(entry, override_type,
override_valueset);
}
slapi_entry_delete_values_sv(entry, attr, NULL) will clear whole
attribute and then I can add the valueset. This, unfortunately, works
via iterating over the whole valueset and adding values one by one but
in our case it would be most likely a single element anyway.
Pasted a lot of typos but fixed it already:
result = slapi_entry_attr_exists(entry, override_type);
if (result == 0) {
result = slapi_attr_get_valueset(override_attr, &override_valueset);
result = slapi_entry_attr_delete(entry, override_type);
result = slapi_entry_add_valueset(entry, override_type,
override_valueset);
}
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On 10/07/2014 11:43 AM, Alexander Bokovoy wrote: On Tue, 07 Oct 2014, thierry bordaz wrote: A question about backend_search_filter_has_cn_uid. It checks if a filter components contains (uid|uidNumber|gidNumber|memberUid) and in this case returns SLAPI_FILTER_SCAN_STOP. This value will interrupt the filter rewriting. In addition, for each component it calls idview_process_filter_cb to override an attribute that needs to be override in the view. So I wonder if it will work for filter like: (&(=xxx) (uid=yyy)) but will stop to early for (&(uid=yyy)(=xxx)) We handle the requests which come from various NSS clients here (nss-pam-ldapd, nss_ldap, sssd, and similar). They don't do reordering like you say. Since all these searches never base queries on attributes other the ones we check (uid|uidNumber|gidNumber|memberUid), we don't need to replace other attributes here. I can see there could be a case where we get something like (actual query): (&(gidNumber=1878600500) (|(objectClass=groupOfNames) (objectClass=posixGroup)) (cn=*)(&(gidNumber=*)(!(gidNumber=0 and we need to ignore '*' and '0' if they come before explicit gidNumber=, I'll fix this one. Do you think we need to traverse the filter tree until it ends in all cases? In all filter types I've seen we are interested only in a single name and once we've got attributes filled in, we don't need to continue. In idview_process_filter_cb, there is a override of an attribute name into "ipaAnchorUUID". I do not know what attribute required this override, but my concern is that depending on the order of the attributes in the filter, this override may not occur. I agree that if no existing filter is in this case it is not required to go until the end of the filter. Now if new clients starts using such filter pattern, it will also require a change in the plugin. From the performance point of view, it requires more processing at the filter level. unless filters are very long I would not expect a significant impact. Maybe for the replacement case of idview_process_filter_cb() we can have some flag in the filter processing config that forces to go through the fliter no matter what? Yes that could be an accelerator, when idview_process_filter_cb() has override an attribute into "ipaAnchorUUID" a flag could be reported to backend_search_filter_has_cn_uid to decide to stop the filter processing. To be honest I would prefer a systematic traverse of the filter until its end, even at the cost of additional processing. It would be easier to understand what the rewrite is doing and make it compatible with client enhancements. thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On Tue, 07 Oct 2014, Ludwig Krispenz wrote:
On 10/07/2014 12:39 PM, Alexander Bokovoy wrote:
On Tue, 07 Oct 2014, Ludwig Krispenz wrote:
On 10/07/2014 12:12 PM, Alexander Bokovoy wrote:
On Tue, 07 Oct 2014, Ludwig Krispenz wrote:
Hi Alex,
slapi_attr_set_valueset() calls slapi_valueset_set_valueset(),
but this does not free the existing values,
Here is the problem, I cannot free original values as
slapi_attr_get_valueset() returns a copy and I never can get access to
the original Slapi_ValueSet.
good point.
I only can get access to the original Slapi_Value** array which means I
could manipulate its content but that probably require resizing it and
thus changing a pointer vs->va, to which I don't have access anyway.
you should never do this, a valueset contains more data than va
How can we fix this?
the best thing would probably be to fix slapi_attr_set_valueset or
adding a new api function which frees teh old valueset, but this
would add a dependency to specific DS version
What about something like this:
void
slapi_valueset_set_valueset(Slapi_ValueSet *vs1, const Slapi_ValueSet
*vs2)
{
if ((vs1 != NULL) && (vs1->num != 0)) {
slapi_valueset_done(vs1);
}
slapi_valueset_init(vs1);
valueset_set_valueset(vs1,vs2);
}
Another option is to fix slapi_attr_set_valueset():
int
slapi_attr_set_valueset(Slapi_Attr *a, const Slapi_ValueSet *vs)
{
if (a->a_present_values->num != 0) {
lapi_valueset_done(&a->a_present_values);
}
slapi_valueset_set_valueset( &a->a_present_values, vs);
return 0;
}
Other uses of slapi_valueset_set_valueset() are operating on newly
created Slapi_ValueSet instances.
both will be ok (for me), but we have to commit it first and you
depend on that version.
a more clumsy way would be to get the values and then use
slapi_entry_attr_replace_sv() which would free the attr and recreate
it
Actually, you pointed me to a better solution:
/* Replace the attribute's value with the override */
result = slapi_entry_attr_exists(entry, override_type);
if (result == 0) {
result = slapi_attr_get_values(override_attr, &override_valueset);
result = slapi_entry_attr_delete_sv(entry, override_type, NULL);
result = slapi_entry_add_valueset(entry, override_type,
override_valueset);
}
slapi_entry_delete_values_sv(entry, attr, NULL) will clear whole
attribute and then I can add the valueset. This, unfortunately, works
via iterating over the whole valueset and adding values one by one but
in our case it would be most likely a single element anyway.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On 10/07/2014 12:39 PM, Alexander Bokovoy wrote:
On Tue, 07 Oct 2014, Ludwig Krispenz wrote:
On 10/07/2014 12:12 PM, Alexander Bokovoy wrote:
On Tue, 07 Oct 2014, Ludwig Krispenz wrote:
Hi Alex,
slapi_attr_set_valueset() calls slapi_valueset_set_valueset(), but
this does not free the existing values,
Here is the problem, I cannot free original values as
slapi_attr_get_valueset() returns a copy and I never can get access to
the original Slapi_ValueSet.
good point.
I only can get access to the original Slapi_Value** array which means I
could manipulate its content but that probably require resizing it and
thus changing a pointer vs->va, to which I don't have access anyway.
you should never do this, a valueset contains more data than va
How can we fix this?
the best thing would probably be to fix slapi_attr_set_valueset or
adding a new api function which frees teh old valueset, but this
would add a dependency to specific DS version
What about something like this:
void
slapi_valueset_set_valueset(Slapi_ValueSet *vs1, const Slapi_ValueSet
*vs2)
{
if ((vs1 != NULL) && (vs1->num != 0)) {
slapi_valueset_done(vs1);
}
slapi_valueset_init(vs1);
valueset_set_valueset(vs1,vs2);
}
Another option is to fix slapi_attr_set_valueset():
int
slapi_attr_set_valueset(Slapi_Attr *a, const Slapi_ValueSet *vs)
{
if (a->a_present_values->num != 0) {
lapi_valueset_done(&a->a_present_values);
}
slapi_valueset_set_valueset( &a->a_present_values, vs);
return 0;
}
Other uses of slapi_valueset_set_valueset() are operating on newly
created Slapi_ValueSet instances.
both will be ok (for me), but we have to commit it first and you depend
on that version.
a more clumsy way would be to get the values and then use
slapi_entry_attr_replace_sv() which would free the attr and recreate it
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On Tue, 07 Oct 2014, Ludwig Krispenz wrote:
On 10/07/2014 12:12 PM, Alexander Bokovoy wrote:
On Tue, 07 Oct 2014, Ludwig Krispenz wrote:
Hi Alex,
slapi_attr_set_valueset() calls slapi_valueset_set_valueset(), but
this does not free the existing values,
Here is the problem, I cannot free original values as
slapi_attr_get_valueset() returns a copy and I never can get access to
the original Slapi_ValueSet.
good point.
I only can get access to the original Slapi_Value** array which means I
could manipulate its content but that probably require resizing it and
thus changing a pointer vs->va, to which I don't have access anyway.
you should never do this, a valueset contains more data than va
How can we fix this?
the best thing would probably be to fix slapi_attr_set_valueset or
adding a new api function which frees teh old valueset, but this would
add a dependency to specific DS version
What about something like this:
void
slapi_valueset_set_valueset(Slapi_ValueSet *vs1, const Slapi_ValueSet
*vs2)
{
if ((vs1 != NULL) && (vs1->num != 0)) {
slapi_valueset_done(vs1);
}
slapi_valueset_init(vs1);
valueset_set_valueset(vs1,vs2);
}
Another option is to fix slapi_attr_set_valueset():
int
slapi_attr_set_valueset(Slapi_Attr *a, const Slapi_ValueSet *vs)
{
if (a->a_present_values->num != 0) {
lapi_valueset_done(&a->a_present_values);
}
slapi_valueset_set_valueset( &a->a_present_values, vs);
return 0;
}
Other uses of slapi_valueset_set_valueset() are operating on newly
created Slapi_ValueSet instances.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On 10/07/2014 12:12 PM, Alexander Bokovoy wrote: On Tue, 07 Oct 2014, Ludwig Krispenz wrote: Hi Alex, slapi_attr_set_valueset() calls slapi_valueset_set_valueset(), but this does not free the existing values, Here is the problem, I cannot free original values as slapi_attr_get_valueset() returns a copy and I never can get access to the original Slapi_ValueSet. good point. I only can get access to the original Slapi_Value** array which means I could manipulate its content but that probably require resizing it and thus changing a pointer vs->va, to which I don't have access anyway. you should never do this, a valueset contains more data than va How can we fix this? the best thing would probably be to fix slapi_attr_set_valueset or adding a new api function which frees teh old valueset, but this would add a dependency to specific DS version ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On Tue, 07 Oct 2014, Ludwig Krispenz wrote: Hi Alex, slapi_attr_set_valueset() calls slapi_valueset_set_valueset(), but this does not free the existing values, Here is the problem, I cannot free original values as slapi_attr_get_valueset() returns a copy and I never can get access to the original Slapi_ValueSet. I only can get access to the original Slapi_Value** array which means I could manipulate its content but that probably require resizing it and thus changing a pointer vs->va, to which I don't have access anyway. How can we fix this? -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
Hi Alex, slapi_attr_set_valueset() calls slapi_valueset_set_valueset(), but this does not free the existing values, cf https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Plug-in_Guide/Plugin_Programming_Guide-Function_Reference-slapi_valueset_set_valueset.html ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On Tue, 07 Oct 2014, thierry bordaz wrote: A question about backend_search_filter_has_cn_uid. It checks if a filter components contains (uid|uidNumber|gidNumber|memberUid) and in this case returns SLAPI_FILTER_SCAN_STOP. This value will interrupt the filter rewriting. In addition, for each component it calls idview_process_filter_cb to override an attribute that needs to be override in the view. So I wonder if it will work for filter like: (&(=xxx) (uid=yyy)) but will stop to early for (&(uid=yyy)(=xxx)) We handle the requests which come from various NSS clients here (nss-pam-ldapd, nss_ldap, sssd, and similar). They don't do reordering like you say. Since all these searches never base queries on attributes other the ones we check (uid|uidNumber|gidNumber|memberUid), we don't need to replace other attributes here. I can see there could be a case where we get something like (actual query): (&(gidNumber=1878600500) (|(objectClass=groupOfNames) (objectClass=posixGroup)) (cn=*)(&(gidNumber=*)(!(gidNumber=0 and we need to ignore '*' and '0' if they come before explicit gidNumber=, I'll fix this one. Do you think we need to traverse the filter tree until it ends in all cases? In all filter types I've seen we are interested only in a single name and once we've got attributes filled in, we don't need to continue. Maybe for the replacement case of idview_process_filter_cb() we can have some flag in the filter processing config that forces to go through the fliter no matter what? -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On 10/01/2014 06:16 PM, Alexander Bokovoy wrote: Hi! Attached are patches to add support of FreeIPA ID views to Schema compatibility plugin (slapi-nis). There are two patches for FreeIPA and a separate patch for slapi-nis. Patches can be applied independently; if old slapi-nis is installed, it will simply work with new configuration but do nothing with respect to answering to requests using host-specific ID views. I included documentation on how slapi-nis ID views feature supposed to work, available in slapi-nis/doc/ipa/ipa-sch.txt. Any comments and fixes are welcome. There are no additional tests in slapi-nis to cover compat trees, we have multiple tests in FreeIPA for this purpose, will be run as part of FreeIPA CI effort. FreeIPA patches add ACIs for accessing ID view-applied entries over compat tree. They also include additional configuration; this configuration is needed to properly resolve ID view overrides when creating compat entries. A second FreeIPA patch adds support to override login shell. This part was missing from the original patchset by Tomas. For trusted AD users one needs patches to SSSD 1.12.2, made by Sumit Bose. There is also a regression (fixed by Sumit as well) that prevents authentication of AD users over PAM which affects authentication over compat tree. With the patch from Sumit authentication works again, both with ID view and without it. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hello Alexander, A question about backend_search_filter_has_cn_uid. It checks if a filter components contains (uid|uidNumber|gidNumber|memberUid) and in this case returns SLAPI_FILTER_SCAN_STOP. This value will interrupt the filter rewriting. In addition, for each component it calls idview_process_filter_cb to override an attribute that needs to be override in the view. So I wonder if it will work for filter like: (&(=xxx) (uid=yyy)) but will stop to early for (&(uid=yyy)(=xxx)) thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On 10/06/2014 04:57 PM, Ludwig Krispenz wrote: On 10/06/2014 04:44 PM, Alexander Bokovoy wrote: On Mon, 06 Oct 2014, Ludwig Krispenz wrote: Hi Alex, one quick comment: I'm afraid the only case where slapi_search_internal_pb() returns -1 is if you don't provide a pblock. In all other cases it returns 0 and you have to check: slapi_pblock_get(search_pb, SLAPI_PLUGIN_INTOP_RESULT, &result); Uhm, there are few more cases: - when filter string is NULL; - when scope is wrong - when building a filter struct failed due to memory or syntax error these are returns from search_internal_callback_pb(). But slapi_search_internal_pb() calls slapi_search_internal_pb() which just does: slapi_search_internal_pb() calls search_internal_pb() search_internal_callback_pb (pb, &psid, internal_plugin_result_callback, internal_plugin_search_entry_callback, internal_plugin_search_referral_callback); opresult = psid.rc; ... and does not care what search_internal_callback_pb() returns. If return from slapi_search_internal_pb() is 0, we are at least got to op_shared_search() so we are dealing with the consequence of actually running the search. I'll add one more check for the result (I had it in one of original versions before simplification), thanks. Ludwig Ludwig On 10/01/2014 06:16 PM, Alexander Bokovoy wrote: Hi! Attached are patches to add support of FreeIPA ID views to Schema compatibility plugin (slapi-nis). There are two patches for FreeIPA and a separate patch for slapi-nis. Patches can be applied independently; if old slapi-nis is installed, it will simply work with new configuration but do nothing with respect to answering to requests using host-specific ID views. I included documentation on how slapi-nis ID views feature supposed to work, available in slapi-nis/doc/ipa/ipa-sch.txt. Any comments and fixes are welcome. There are no additional tests in slapi-nis to cover compat trees, we have multiple tests in FreeIPA for this purpose, will be run as part of FreeIPA CI effort. FreeIPA patches add ACIs for accessing ID view-applied entries over compat tree. They also include additional configuration; this configuration is needed to properly resolve ID view overrides when creating compat entries. A second FreeIPA patch adds support to override login shell. This part was missing from the original patchset by Tomas. For trusted AD users one needs patches to SSSD 1.12.2, made by Sumit Bose. There is also a regression (fixed by Sumit as well) that prevents authentication of AD users over PAM which affects authentication over compat tree. With the patch from Sumit authentication works again, both with ID view and without it. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On 10/06/2014 04:44 PM, Alexander Bokovoy wrote: On Mon, 06 Oct 2014, Ludwig Krispenz wrote: Hi Alex, one quick comment: I'm afraid the only case where slapi_search_internal_pb() returns -1 is if you don't provide a pblock. In all other cases it returns 0 and you have to check: slapi_pblock_get(search_pb, SLAPI_PLUGIN_INTOP_RESULT, &result); Uhm, there are few more cases: - when filter string is NULL; - when scope is wrong - when building a filter struct failed due to memory or syntax error these are returns from search_internal_callback_pb(). But slapi_search_internal_pb() calls slapi_search_internal_pb() which just does: search_internal_callback_pb (pb, &psid, internal_plugin_result_callback, internal_plugin_search_entry_callback, internal_plugin_search_referral_callback); opresult = psid.rc; ... and does not care what search_internal_callback_pb() returns. If return from slapi_search_internal_pb() is 0, we are at least got to op_shared_search() so we are dealing with the consequence of actually running the search. I'll add one more check for the result (I had it in one of original versions before simplification), thanks. Ludwig Ludwig On 10/01/2014 06:16 PM, Alexander Bokovoy wrote: Hi! Attached are patches to add support of FreeIPA ID views to Schema compatibility plugin (slapi-nis). There are two patches for FreeIPA and a separate patch for slapi-nis. Patches can be applied independently; if old slapi-nis is installed, it will simply work with new configuration but do nothing with respect to answering to requests using host-specific ID views. I included documentation on how slapi-nis ID views feature supposed to work, available in slapi-nis/doc/ipa/ipa-sch.txt. Any comments and fixes are welcome. There are no additional tests in slapi-nis to cover compat trees, we have multiple tests in FreeIPA for this purpose, will be run as part of FreeIPA CI effort. FreeIPA patches add ACIs for accessing ID view-applied entries over compat tree. They also include additional configuration; this configuration is needed to properly resolve ID view overrides when creating compat entries. A second FreeIPA patch adds support to override login shell. This part was missing from the original patchset by Tomas. For trusted AD users one needs patches to SSSD 1.12.2, made by Sumit Bose. There is also a regression (fixed by Sumit as well) that prevents authentication of AD users over PAM which affects authentication over compat tree. With the patch from Sumit authentication works again, both with ID view and without it. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
On Mon, 06 Oct 2014, Ludwig Krispenz wrote: Hi Alex, one quick comment: I'm afraid the only case where slapi_search_internal_pb() returns -1 is if you don't provide a pblock. In all other cases it returns 0 and you have to check: slapi_pblock_get(search_pb, SLAPI_PLUGIN_INTOP_RESULT, &result); Uhm, there are few more cases: - when filter string is NULL; - when scope is wrong - when building a filter struct failed due to memory or syntax error If return from slapi_search_internal_pb() is 0, we are at least got to op_shared_search() so we are dealing with the consequence of actually running the search. I'll add one more check for the result (I had it in one of original versions before simplification), thanks. Ludwig Ludwig On 10/01/2014 06:16 PM, Alexander Bokovoy wrote: Hi! Attached are patches to add support of FreeIPA ID views to Schema compatibility plugin (slapi-nis). There are two patches for FreeIPA and a separate patch for slapi-nis. Patches can be applied independently; if old slapi-nis is installed, it will simply work with new configuration but do nothing with respect to answering to requests using host-specific ID views. I included documentation on how slapi-nis ID views feature supposed to work, available in slapi-nis/doc/ipa/ipa-sch.txt. Any comments and fixes are welcome. There are no additional tests in slapi-nis to cover compat trees, we have multiple tests in FreeIPA for this purpose, will be run as part of FreeIPA CI effort. FreeIPA patches add ACIs for accessing ID view-applied entries over compat tree. They also include additional configuration; this configuration is needed to properly resolve ID view overrides when creating compat entries. A second FreeIPA patch adds support to override login shell. This part was missing from the original patchset by Tomas. For trusted AD users one needs patches to SSSD 1.12.2, made by Sumit Bose. There is also a regression (fixed by Sumit as well) that prevents authentication of AD users over PAM which affects authentication over compat tree. With the patch from Sumit authentication works again, both with ID view and without it. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
Hi Alex, one quick comment: I'm afraid the only case where slapi_search_internal_pb() returns -1 is if you don't provide a pblock. In all other cases it returns 0 and you have to check: slapi_pblock_get(search_pb, SLAPI_PLUGIN_INTOP_RESULT, &result); Ludwig Ludwig On 10/01/2014 06:16 PM, Alexander Bokovoy wrote: Hi! Attached are patches to add support of FreeIPA ID views to Schema compatibility plugin (slapi-nis). There are two patches for FreeIPA and a separate patch for slapi-nis. Patches can be applied independently; if old slapi-nis is installed, it will simply work with new configuration but do nothing with respect to answering to requests using host-specific ID views. I included documentation on how slapi-nis ID views feature supposed to work, available in slapi-nis/doc/ipa/ipa-sch.txt. Any comments and fixes are welcome. There are no additional tests in slapi-nis to cover compat trees, we have multiple tests in FreeIPA for this purpose, will be run as part of FreeIPA CI effort. FreeIPA patches add ACIs for accessing ID view-applied entries over compat tree. They also include additional configuration; this configuration is needed to properly resolve ID view overrides when creating compat entries. A second FreeIPA patch adds support to override login shell. This part was missing from the original patchset by Tomas. For trusted AD users one needs patches to SSSD 1.12.2, made by Sumit Bose. There is also a regression (fixed by Sumit as well) that prevents authentication of AD users over PAM which affects authentication over compat tree. With the patch from Sumit authentication works again, both with ID view and without it. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
