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
[Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree
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. -- / Alexander Bokovoy From 400a6fe320ff5d92311a670e596aba486a8a3bc0 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 30 Sep 2014 14:54:50 +0300 Subject: [PATCH 2/4] Support idviews in compat tree https://fedorahosted.org/freeipa/ticket/3318 --- ACI.txt | 6 ++ install/share/71idviews.ldif| 1 + install/share/schema_compat.uldif | 8 install/updates/10-schema_compat.update | 12 ipalib/plugins/group.py | 10 ++ ipalib/plugins/user.py | 11 +++ ipaserver/install/plugins/update_managed_permissions.py | 11 +++ 7 files changed, 59 insertions(+) diff --git a/ACI.txt b/ACI.txt index cebdc2c..87c057e 100644 --- a/ACI.txt +++ b/ACI.txt @@ -54,6 +54,8 @@ dn: dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || entryusn || gidnumber || memberuid || modifytimestamp || objectclass")(target = "ldap:///cn=groups,cn=compat,dc=ipa,dc=example";)(version 3.0;acl "permission:System: Read Group Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";;) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = "member || memberhost || memberof || memberuid || memberuser")(targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Read Group Membership";allow (compare,read,search) userdn = "ldap:///all";;) +dn: dc=ipa,dc=example +aci: (targetattr = "cn || createtimestamp || entryusn || gidnumber || memberuid || modifytimestamp || objectclass")(target = "ldap:///cn=groups,cn=*,cn=views,cn=compat,dc=ipa,dc=example";)(version 3.0;acl "permission:System: Read Group Views Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";;) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = "businesscategory || cn || createtimestamp || description || entryusn || gidnumber || ipaexternalmember || ipantsecurityidentifier || ipauniqueid || mepmanagedby || modifytimestamp || o || objectclass || ou || owner || seealso")(targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Read Groups";allow (compare,read,search) userdn = "ldap:///anyone";;) dn: cn=groups,cn=accounts,dc=ipa,dc=example @@ -256,6 +258,8 @@ dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = "memberof")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Read User Membership";allow (compare,read,search) userdn = "ldap:///all";;) dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || description || displayname || entryusn || gecos || gidnumber || givenname || homedirectory || initials || ipantsecurityidentifier || loginshell || manager || modifytimestamp || objectclass || sn || title || uid || uidnumber")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Read User Standard Attributes";allow (compare,read,search) userdn = "ldap:///anyone";;) +dn: dc=ipa,dc=example +aci: (targetattr = "cn || createtimestamp || entryusn || gecos || gidnumber || homedirectory || loginshell || modifytimestamp || objectclass || uid || uidnumber")(target = "ldap:///cn=users,cn=*,cn=views,cn=compat,dc=ipa,dc=example";)(version 3.0;acl "permission:System: Read User Views Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";;) dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permis