Bug 1298629 - ID mapping - bug in computing max id for slice range
Summary: ID mapping - bug in computing max id for slice range
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Pavel Reichl
QA Contact: Steeve Goveas
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-01-14 15:20 UTC by Jakub Hrozek
Modified: 2020-05-02 18:17 UTC (History)
10 users (show)

Fixed In Version: sssd-1.13.3-14.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-10 20:26:29 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github SSSD sssd issues 3963 None closed ID mapping - bug in computing max id for slice range 2020-05-02 18:17:09 UTC
Red Hat Product Errata RHBA-2016:0782 normal SHIPPED_LIVE sssd bug fix and enhancement update 2016-05-10 22:36:00 UTC

Description Jakub Hrozek 2016-01-14 15:20:28 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/2922

There seems to be a bug in the way we assign ranges for domain when we algorithmically perform id mapping.

In sss_idmap_calculate_range() we compute the upper limit for ids *max* as being 'min + range' which means that actual range of ids is:
{{{
max - min + 1 = min + range - min + 1 = range + 1
}}}
And this differs from range by 1.

We should be even be able to see some mapping issue with secondary ranges. The last POSIX ID from a range and the first POSIX ID from the next range should return the same SID/RID. 

In the IPA code there is 'range.max = r->base_id + r->id_range_size -1;' We should amend code to the same.

Comment 2 Lukas Slebodnik 2016-01-20 17:19:20 UTC
master:
* 7db89d44b5582a0cb0a61a7aa42a2fac7ca9408f

sssd-1-13:
* 645933bcfd4acfb1729fcee2fee6c37b1acbfb92

Comment 3 Sumit Bose 2016-01-27 15:44:46 UTC
The SSSD configuration option ldap_idmap_range_size defines the number of POSIX IDs available in a range i.e. how may RIDs can be mapped to a POSIX ID. E.g. if ldap_idmap_range_size=5 we can map the RIDs 0,1,2,3,4 because counting starts with zero. Without the patch the RID 5 could be mapped as well although it is already the 6th ID.

To check this in a real setup with id_provider=ad set 'ldap_idmap_range_size=513' (cache must be removed is SSSD was used with a different value before). Now the RID 513 which belongs to the AD 'Domain Users' group should not be mapped anymore and 

getent passwd Administrator@ad.domain

should return nothing because although the RID of the Administrator 500 can be mapped the RID of the primary group cannot be mapped. Without the patch getent passwd will return a result with the patch applied it will return nothing.

Comment 6 Niranjan Mallapadi Raghavender 2016-03-19 02:23:07 UTC
While using the below configuration

[sssd]
config_file_version = 2
domains = winpki1.testpki.test
services = nss, pam

[domain/winpki1.testpki.test]
id_provider = ad
auth_provider = ad
access_provider = ad
default_shell = /bin/bash
fallback_homedir = /home/%d/%u
use_fully_qualified_names = True
debug_level = 9
enumerate = False
ldap_idmap_range_size = 513
ldap_id_mapping = True
ad_server = WIN-Q8VKBEJ7H39.winpki1.testpki.test
ad_domain = winpki1.testpki.test

I have set ldap_idmap_range_size = 513, after clearing sssd cache and restarting sssd, getent Administrator@winpki1.testpki.test is  still shown,  

Is the above expected ?

Comment 7 Sumit Bose 2016-03-19 11:18:46 UTC
Which SSSD version did you use? How does the output look like?

With older cersion of SSSD is is expected that the output is show. With newer versions of SSSD you might need to set 'ldap_idmap_helper_table_size=0' to disable the new feature which automatically adds new ranges if the configured range size is too small.

Comment 8 Niranjan Mallapadi Raghavender 2016-03-20 01:16:41 UTC
sorry about not specifying the version:

Version:
sssd-1.13.3-22.el6.x86_64

Before specifying the ldap_idmap_helper_table_size=0

[sssd]
config_file_version = 2
domains = winpki1.testpki.test
services = nss, pam

[domain/winpki1.testpki.test]
id_provider = ad
auth_provider = ad
access_provider = ad
default_shell = /bin/bash
fallback_homedir = /home/%d/%u
use_fully_qualified_names = True
debug_level = 9
enumerate = False
ldap_idmap_range_size = 513
ldap_id_mapping = True
ad_server = WIN-Q8VKBEJ7H39.winpki1.testpki.test
ad_domain = winpki1.testpki.test


[root@dhcp201-105 mc]# getent passwd Administrator@winpki1.testpki.test
administrator@winpki1.testpki.test:*:503810548:979787864:Administrator:/home/Administrator:/bin/sh

#stopped sssd and cleared everything from /var/lib/sss/db/* and /var/lib/sss/mc/*

start sssd service

$service sssd start
[root@dhcp201-105 db]# getent passwd Administrator@winpki1.testpki.test
[root@dhcp201-105 db]# 

I don't see the output in getent passwd.

I see the following in the logs

(Sun Mar 20 06:37:16 2016) [sssd[be[winpki1.testpki.test]]] [sdap_idmap_sid_to_unix] (0x0040): Object SID [S-1-5-21-2826619844-1825486024-3854887371-513] has a RID that is larger than the ldap_idmap_range_size. See the "ID MAPPING" section of sssd-ad(5) for an explanation of how to resolve this issue.

Comment 9 Sumit Bose 2016-03-20 11:43:00 UTC
Yes, this makes sense. Since there already was an entry in the cache it was returned before you removed the cache. I think you can move the ticket to verified.

Comment 11 errata-xmlrpc 2016-05-10 20:26:29 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0782.html


Note You need to log in before you can comment on or make changes to this bug.