Bug 741210 - [RFE] Validate ID ranges for local domain users
[RFE] Validate ID ranges for local domain users
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
Unspecified Linux
unspecified Severity medium
: ---
: ---
Assigned To: Stephen Gallagher
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2011-09-26 05:38 EDT by Kashyap Chamarthy
Modified: 2012-03-05 16:18 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-03-05 16:18:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
FedoraHosted SSSD 1049 None None None Never

  None (edit)
Description Kashyap Chamarthy 2011-09-26 05:38:58 EDT
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 10:24:55 EDT
Upstream ticket:
Comment 2 Dmitri Pal 2011-11-17 09:12:54 EST
Upstream ticket:
Comment 3 Stephen Gallagher 2012-03-05 16:18:21 EST
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.

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