Bug 741210 - [RFE] Validate ID ranges for local domain users
Summary: [RFE] Validate ID ranges for local domain users
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: 16
Hardware: Unspecified
OS: Linux
Target Milestone: ---
Assignee: Stephen Gallagher
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-26 09:38 UTC by Kashyap Chamarthy
Modified: 2020-05-02 16:27 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-03-05 21:18:21 UTC
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
FedoraHosted SSSD 1049 0 None None None Never
Github SSSD sssd issues 2091 0 None None None 2020-05-02 16:27:57 UTC

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.

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