Hi,
another issue found by Steeve during testing. To reproduce this you need a universal group with members from different domains. Then either look up the group by SID e.g. with
python -c "import pysss_nss_idmap; print pysss_nss_idmap.getnamebysid('S-1-5-21-3456664713-2053453454-4165325232-1234')"
and then with getent group groupname.
Or use IPA views, override the group name in the 'default trust view' on the IPA server and look up the group by the overridden name. In both case the group should not already be in the cache. Only members from the domain of the group should be show without the patch.
bye, Sumit
On Wed, Jan 28, 2015 at 03:05:00PM +0100, Sumit Bose wrote:
Hi,
another issue found by Steeve during testing. To reproduce this you need a universal group with members from different domains. Then either look up the group by SID e.g. with
python -c "import pysss_nss_idmap; print pysss_nss_idmap.getnamebysid('S-1-5-21-3456664713-2053453454-4165325232-1234')"
and then with getent group groupname.
Or use IPA views, override the group name in the 'default trust view' on the IPA server and look up the group by the overridden name. In both case the group should not already be in the cache. Only members from the domain of the group should be show without the patch.
bye, Sumit
The patch is correct, but I'm worried about the implications. What kind of requests by SID does the server receive? Do we also resolve requests for users by SID? In that case, we might be surprised that some POSIX attributes are not available in GC..
On Wed, Jan 28, 2015 at 03:27:44PM +0100, Jakub Hrozek wrote:
On Wed, Jan 28, 2015 at 03:05:00PM +0100, Sumit Bose wrote:
Hi,
another issue found by Steeve during testing. To reproduce this you need a universal group with members from different domains. Then either look up the group by SID e.g. with
python -c "import pysss_nss_idmap; print pysss_nss_idmap.getnamebysid('S-1-5-21-3456664713-2053453454-4165325232-1234')"
and then with getent group groupname.
Or use IPA views, override the group name in the 'default trust view' on the IPA server and look up the group by the overridden name. In both case the group should not already be in the cache. Only members from the domain of the group should be show without the patch.
bye, Sumit
The patch is correct, but I'm worried about the implications. What kind of requests by SID does the server receive? Do we also resolve requests for users by SID? In that case, we might be surprised that some POSIX attributes are not available in GC..
good point, I'm working on a group only alternative.
bye, Sumit
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Wed, Jan 28, 2015 at 04:21:53PM +0100, Sumit Bose wrote:
On Wed, Jan 28, 2015 at 03:27:44PM +0100, Jakub Hrozek wrote:
On Wed, Jan 28, 2015 at 03:05:00PM +0100, Sumit Bose wrote:
Hi,
another issue found by Steeve during testing. To reproduce this you need a universal group with members from different domains. Then either look up the group by SID e.g. with
python -c "import pysss_nss_idmap; print pysss_nss_idmap.getnamebysid('S-1-5-21-3456664713-2053453454-4165325232-1234')"
and then with getent group groupname.
Or use IPA views, override the group name in the 'default trust view' on the IPA server and look up the group by the overridden name. In both case the group should not already be in the cache. Only members from the domain of the group should be show without the patch.
bye, Sumit
The patch is correct, but I'm worried about the implications. What kind of requests by SID does the server receive? Do we also resolve requests for users by SID? In that case, we might be surprised that some POSIX attributes are not available in GC..
good point, I'm working on a group only alternative.
Please find attached a slightly extended version. It tries to switch to the LDAP connection in the common LDAP code. We already do similar things during group requests in the common LDAP code so I hope this is ok. This switch only happens during user_and_group request where it is not clear if the match will be a user or a group, e.g. a search by SID. I have to admit that there is a side effect because the AD provider uses GC lookups with LDAP fallback for these types of requests and will be affected by this change as well. But since the more detailed user information will be available via LDAP this might even be a benefit.
bye, Sumit
bye, Sumit
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Wed, Jan 28, 2015 at 08:18:04PM +0100, Sumit Bose wrote:
On Wed, Jan 28, 2015 at 04:21:53PM +0100, Sumit Bose wrote:
On Wed, Jan 28, 2015 at 03:27:44PM +0100, Jakub Hrozek wrote:
On Wed, Jan 28, 2015 at 03:05:00PM +0100, Sumit Bose wrote:
Hi,
another issue found by Steeve during testing. To reproduce this you need a universal group with members from different domains. Then either look up the group by SID e.g. with
python -c "import pysss_nss_idmap; print pysss_nss_idmap.getnamebysid('S-1-5-21-3456664713-2053453454-4165325232-1234')"
and then with getent group groupname.
Or use IPA views, override the group name in the 'default trust view' on the IPA server and look up the group by the overridden name. In both case the group should not already be in the cache. Only members from the domain of the group should be show without the patch.
bye, Sumit
The patch is correct, but I'm worried about the implications. What kind of requests by SID does the server receive? Do we also resolve requests for users by SID? In that case, we might be surprised that some POSIX attributes are not available in GC..
good point, I'm working on a group only alternative.
Please find attached a slightly extended version. It tries to switch to the LDAP connection in the common LDAP code. We already do similar things during group requests in the common LDAP code so I hope this is ok. This switch only happens during user_and_group request where it is not clear if the match will be a user or a group, e.g. a search by SID. I have to admit that there is a side effect because the AD provider uses GC lookups with LDAP fallback for these types of requests and will be affected by this change as well. But since the more detailed user information will be available via LDAP this might even be a benefit.
bye, Sumit
[...]
- if (state->sdap_ret == ENOENT) {
- if (state->sdap_ret == ENOENT && state->noexist_delete == true) {
I don't think this change is correct, the noexist_delete check should be in its own nested if, otherwise looking up a SID that matches neither user nor group fails with EIO: Breakpoint 3, get_user_and_group_users_done (subreq=0x18beca0) at src/providers/ldap/ldap_id.c:1799 1799 struct tevent_req *req = tevent_req_callback_data(subreq, (gdb) n 1801 struct get_user_and_group_state *state = tevent_req_data(req, (gdb) 1805 ret = users_get_recv(subreq, &state->dp_error, &state->sdap_ret); (gdb) 1806 talloc_zfree(subreq); (gdb) 1808 if (ret != EOK) { (gdb) 1812 if (state->sdap_ret == ENOENT && state->noexist_delete == true) { (gdb) 1822 } else if (state->sdap_ret != EOK) { (gdb) 1823 tevent_req_error(req, EIO); (gdb) 1824 return; (gdb) p state->sdap_ret $1 = 2 (gdb) p state->noexist_delete $2 = false (gdb) quit
On Fri, Jan 30, 2015 at 01:27:34PM +0100, Jakub Hrozek wrote:
On Wed, Jan 28, 2015 at 08:18:04PM +0100, Sumit Bose wrote:
On Wed, Jan 28, 2015 at 04:21:53PM +0100, Sumit Bose wrote:
On Wed, Jan 28, 2015 at 03:27:44PM +0100, Jakub Hrozek wrote:
On Wed, Jan 28, 2015 at 03:05:00PM +0100, Sumit Bose wrote:
Hi,
another issue found by Steeve during testing. To reproduce this you need a universal group with members from different domains. Then either look up the group by SID e.g. with
python -c "import pysss_nss_idmap; print pysss_nss_idmap.getnamebysid('S-1-5-21-3456664713-2053453454-4165325232-1234')"
and then with getent group groupname.
Or use IPA views, override the group name in the 'default trust view' on the IPA server and look up the group by the overridden name. In both case the group should not already be in the cache. Only members from the domain of the group should be show without the patch.
bye, Sumit
The patch is correct, but I'm worried about the implications. What kind of requests by SID does the server receive? Do we also resolve requests for users by SID? In that case, we might be surprised that some POSIX attributes are not available in GC..
good point, I'm working on a group only alternative.
Please find attached a slightly extended version. It tries to switch to the LDAP connection in the common LDAP code. We already do similar things during group requests in the common LDAP code so I hope this is ok. This switch only happens during user_and_group request where it is not clear if the match will be a user or a group, e.g. a search by SID. I have to admit that there is a side effect because the AD provider uses GC lookups with LDAP fallback for these types of requests and will be affected by this change as well. But since the more detailed user information will be available via LDAP this might even be a benefit.
bye, Sumit
[...]
- if (state->sdap_ret == ENOENT) {
- if (state->sdap_ret == ENOENT && state->noexist_delete == true) {
I don't think this change is correct, the noexist_delete check should be in its own nested if, otherwise looking up a SID that matches neither user nor group fails with EIO:
ah sorry, of course you are right new version attached.
bye, Sumit
Breakpoint 3, get_user_and_group_users_done (subreq=0x18beca0) at src/providers/ldap/ldap_id.c:1799 1799 struct tevent_req *req = tevent_req_callback_data(subreq, (gdb) n 1801 struct get_user_and_group_state *state = tevent_req_data(req, (gdb) 1805 ret = users_get_recv(subreq, &state->dp_error, &state->sdap_ret); (gdb) 1806 talloc_zfree(subreq); (gdb) 1808 if (ret != EOK) { (gdb) 1812 if (state->sdap_ret == ENOENT && state->noexist_delete == true) { (gdb) 1822 } else if (state->sdap_ret != EOK) { (gdb) 1823 tevent_req_error(req, EIO); (gdb) 1824 return; (gdb) p state->sdap_ret $1 = 2 (gdb) p state->noexist_delete $2 = false (gdb) quit _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Fri, Jan 30, 2015 at 02:23:43PM +0100, Sumit Bose wrote:
On Fri, Jan 30, 2015 at 01:27:34PM +0100, Jakub Hrozek wrote:
On Wed, Jan 28, 2015 at 08:18:04PM +0100, Sumit Bose wrote:
On Wed, Jan 28, 2015 at 04:21:53PM +0100, Sumit Bose wrote:
On Wed, Jan 28, 2015 at 03:27:44PM +0100, Jakub Hrozek wrote:
On Wed, Jan 28, 2015 at 03:05:00PM +0100, Sumit Bose wrote:
Hi,
another issue found by Steeve during testing. To reproduce this you need a universal group with members from different domains. Then either look up the group by SID e.g. with
python -c "import pysss_nss_idmap; print pysss_nss_idmap.getnamebysid('S-1-5-21-3456664713-2053453454-4165325232-1234')"
and then with getent group groupname.
Or use IPA views, override the group name in the 'default trust view' on the IPA server and look up the group by the overridden name. In both case the group should not already be in the cache. Only members from the domain of the group should be show without the patch.
bye, Sumit
The patch is correct, but I'm worried about the implications. What kind of requests by SID does the server receive? Do we also resolve requests for users by SID? In that case, we might be surprised that some POSIX attributes are not available in GC..
good point, I'm working on a group only alternative.
Please find attached a slightly extended version. It tries to switch to the LDAP connection in the common LDAP code. We already do similar things during group requests in the common LDAP code so I hope this is ok. This switch only happens during user_and_group request where it is not clear if the match will be a user or a group, e.g. a search by SID. I have to admit that there is a side effect because the AD provider uses GC lookups with LDAP fallback for these types of requests and will be affected by this change as well. But since the more detailed user information will be available via LDAP this might even be a benefit.
bye, Sumit
[...]
- if (state->sdap_ret == ENOENT) {
- if (state->sdap_ret == ENOENT && state->noexist_delete == true) {
I don't think this change is correct, the noexist_delete check should be in its own nested if, otherwise looking up a SID that matches neither user nor group fails with EIO:
ah sorry, of course you are right new version attached.
and now with a patch.
bye, Sumit
Breakpoint 3, get_user_and_group_users_done (subreq=0x18beca0) at src/providers/ldap/ldap_id.c:1799 1799 struct tevent_req *req = tevent_req_callback_data(subreq, (gdb) n 1801 struct get_user_and_group_state *state = tevent_req_data(req, (gdb) 1805 ret = users_get_recv(subreq, &state->dp_error, &state->sdap_ret); (gdb) 1806 talloc_zfree(subreq); (gdb) 1808 if (ret != EOK) { (gdb) 1812 if (state->sdap_ret == ENOENT && state->noexist_delete == true) { (gdb) 1822 } else if (state->sdap_ret != EOK) { (gdb) 1823 tevent_req_error(req, EIO); (gdb) 1824 return; (gdb) p state->sdap_ret $1 = 2 (gdb) p state->noexist_delete $2 = false (gdb) quit _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Fri, Jan 30, 2015 at 02:24:34PM +0100, Sumit Bose wrote:
On Fri, Jan 30, 2015 at 02:23:43PM +0100, Sumit Bose wrote:
On Fri, Jan 30, 2015 at 01:27:34PM +0100, Jakub Hrozek wrote:
On Wed, Jan 28, 2015 at 08:18:04PM +0100, Sumit Bose wrote:
On Wed, Jan 28, 2015 at 04:21:53PM +0100, Sumit Bose wrote:
On Wed, Jan 28, 2015 at 03:27:44PM +0100, Jakub Hrozek wrote:
On Wed, Jan 28, 2015 at 03:05:00PM +0100, Sumit Bose wrote: > Hi, > > another issue found by Steeve during testing. To reproduce this you need > a universal group with members from different domains. Then either look > up the group by SID e.g. with > > python -c "import pysss_nss_idmap; print pysss_nss_idmap.getnamebysid('S-1-5-21-3456664713-2053453454-4165325232-1234')" > > and then with getent group groupname. > > Or use IPA views, override the group name in the 'default trust view' > on the IPA server and look up the group by the overridden name. In both > case the group should not already be in the cache. Only members from the > domain of the group should be show without the patch. > > bye, > Sumit
The patch is correct, but I'm worried about the implications. What kind of requests by SID does the server receive? Do we also resolve requests for users by SID? In that case, we might be surprised that some POSIX attributes are not available in GC..
good point, I'm working on a group only alternative.
Please find attached a slightly extended version. It tries to switch to the LDAP connection in the common LDAP code. We already do similar things during group requests in the common LDAP code so I hope this is ok. This switch only happens during user_and_group request where it is not clear if the match will be a user or a group, e.g. a search by SID. I have to admit that there is a side effect because the AD provider uses GC lookups with LDAP fallback for these types of requests and will be affected by this change as well. But since the more detailed user information will be available via LDAP this might even be a benefit.
bye, Sumit
[...]
- if (state->sdap_ret == ENOENT) {
- if (state->sdap_ret == ENOENT && state->noexist_delete == true) {
I don't think this change is correct, the noexist_delete check should be in its own nested if, otherwise looking up a SID that matches neither user nor group fails with EIO:
ah sorry, of course you are right new version attached.
and now with a patch.
ACK
On Fri, Jan 30, 2015 at 03:15:46PM +0100, Jakub Hrozek wrote:
On Fri, Jan 30, 2015 at 02:24:34PM +0100, Sumit Bose wrote:
On Fri, Jan 30, 2015 at 02:23:43PM +0100, Sumit Bose wrote:
On Fri, Jan 30, 2015 at 01:27:34PM +0100, Jakub Hrozek wrote:
On Wed, Jan 28, 2015 at 08:18:04PM +0100, Sumit Bose wrote:
On Wed, Jan 28, 2015 at 04:21:53PM +0100, Sumit Bose wrote:
On Wed, Jan 28, 2015 at 03:27:44PM +0100, Jakub Hrozek wrote: > On Wed, Jan 28, 2015 at 03:05:00PM +0100, Sumit Bose wrote: > > Hi, > > > > another issue found by Steeve during testing. To reproduce this you need > > a universal group with members from different domains. Then either look > > up the group by SID e.g. with > > > > python -c "import pysss_nss_idmap; print pysss_nss_idmap.getnamebysid('S-1-5-21-3456664713-2053453454-4165325232-1234')" > > > > and then with getent group groupname. > > > > Or use IPA views, override the group name in the 'default trust view' > > on the IPA server and look up the group by the overridden name. In both > > case the group should not already be in the cache. Only members from the > > domain of the group should be show without the patch. > > > > bye, > > Sumit > > The patch is correct, but I'm worried about the implications. What kind > of requests by SID does the server receive? Do we also resolve requests > for users by SID? In that case, we might be surprised that some POSIX > attributes are not available in GC..
good point, I'm working on a group only alternative.
Please find attached a slightly extended version. It tries to switch to the LDAP connection in the common LDAP code. We already do similar things during group requests in the common LDAP code so I hope this is ok. This switch only happens during user_and_group request where it is not clear if the match will be a user or a group, e.g. a search by SID. I have to admit that there is a side effect because the AD provider uses GC lookups with LDAP fallback for these types of requests and will be affected by this change as well. But since the more detailed user information will be available via LDAP this might even be a benefit.
bye, Sumit
[...]
- if (state->sdap_ret == ENOENT) {
- if (state->sdap_ret == ENOENT && state->noexist_delete == true) {
I don't think this change is correct, the noexist_delete check should be in its own nested if, otherwise looking up a SID that matches neither user nor group fails with EIO:
ah sorry, of course you are right new version attached.
and now with a patch.
ACK
Very late pushmail, sorry for the delay. master: 561ed2fd03bab04cfdddbc09c4b48563c9d9b87e sssd-1-12: 8b61b994f95f351d7036f4748e5c6f467698f6ae
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Sumit Bose