Bug 741210

Summary: [RFE] Validate ID ranges for local domain users
Product: [Fedora] Fedora Reporter: Kashyap Chamarthy <kchamart>
Component: sssdAssignee: Stephen Gallagher <sgallagh>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16CC: jhrozek, sbose, sgallagh, ssorce
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-05 21:18:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Kashyap Chamarthy 2011-09-26 09:38:58 UTC
Description of problem:

Validate ID ranges for local domain users. 

[root@dhcp201-210 ~]# rpm -q sssd
[root@dhcp201-210 ~]# 

This came up, when I was trying the below operation and discussed w/ Jakub on IRC.
[root@dhcp201-210 home]# sss_useradd foo4
[root@dhcp201-210 home]# grep min_id /etc/sssd/sssd.conf -A 2
#min_id  = 500
#max_id  = 999
min_id = 1000
max_id = 1999
debug_level = 9
[root@dhcp201-210 home]# 
[root@dhcp201-210 home]# vim /etc/sssd/sssd.conf 
[root@dhcp201-210 home]# grep min_id /etc/sssd/sssd.conf -A 2
min_id  = 500
max_id  = 999
#min_id = 1000
#max_id = 1999
debug_level = 9
[root@dhcp201-210 home]# 
[root@dhcp201-210 home]# service sssd restart
Redirecting to /bin/systemctl  restart sssd.service
[root@dhcp201-210 home]# getent -s sss passwd foo4
[root@dhcp201-210 home]# sss_userdel -r foo4
User foo4 is outside the defined ID range for domain

Additional info:
<jhrozek> kashyap: I'm wondering why the NSS provider returns the data, though..that might be a bug
<jhrozek> kashyap: it seems that we never check ID ranges when the entry is already cached, but only when the entry is saved
<jhrozek> kashyap: for a normal provider, the entry would disappear when it expires (either on its own or when sss_cache is used)
<kashyap> I see,
<jhrozek> kashyap: I don't think there's a way to force the expiration for a local provider
<jhrozek> kashyap: feel free to file a RFE
<kashyap> jhrozek, can you elaborate a little on "..but only when the entry is saved"
<jhrozek> kashyap: consider an LDAP provider. We fetch the user from LDAP and save it to the cache. While saving the user to cache, we do a UID range check and skip the user when the UID is out of range
<jhrozek> kashyap: if the entry is already cached, we don't perform any UID check
<jhrozek> kashyap: the local provider works internally like a cache that never expires
<kashyap> ah,
<kashyap> jhrozek, do you think it'll be useful to file RFE to performa an ID check for the local provider?
<jhrozek> kashyap: I'd file it. The worst thing that can happen is CLOSED/WONTFIX :-)

Comment 1 Jakub Hrozek 2011-10-20 14:24:55 UTC
Upstream ticket:

Comment 2 Dmitri Pal 2011-11-17 14:12:54 UTC
Upstream ticket:

Comment 3 Stephen Gallagher 2012-03-05 21:18:21 UTC
We're not going to change this behavior. As far as we're concerned, if the min/max_id has changed, it's a completely new domain and the only safe way to proceed is to delete the cache file.