RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1068723 - Setting int option to 0 yields the default value
Summary: Setting int option to 0 yields the default value
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: Jakub Hrozek
QA Contact: Kaushik Banerjee
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-21 18:21 UTC by Jakub Hrozek
Modified: 2020-05-02 17:38 UTC (History)
10 users (show)

Fixed In Version: sssd-1.11.2-47.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 10:04:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 3299 0 None None None 2020-05-02 17:38:43 UTC

Description Jakub Hrozek 2014-02-21 18:21:31 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/2257

I would have expected that 0 would be returned instead, effectively disabling the cache. Reported by adelton.

Comment 1 Jenny Severance 2014-02-21 18:42:23 UTC
Please add steps to set up, reproduce and verify this issue.

Comment 2 Jakub Hrozek 2014-02-21 19:16:22 UTC
(In reply to Jenny Galipeau from comment #1)
> Please add steps to set up, reproduce and verify this issue.

Jan Pazdziora has an automated script that you can use easily. The rough steps to reproduce are:

0) Set up IPA client. On the server, set up a rule that would allow access.
1) In sssd.conf, set ipa_hbac_refresh=0. Restart SSSD.
2) Attempt to log in. This time the login should succeed.
3) Change the rule on the server to not match or disable it.
4) Log in again. Since refresh is timeout is set to 0 seconds, you'd expect SSSD do fetch the updated rule and deny access. But because of the bug, the default timeout of 5 seconds would be used and the cached (allow) rule would be used.

The trick is to make 2) - 4) happen faster than the default 5 seconds timeout, so using a script might make more sense.

Comment 5 Jakub Hrozek 2014-02-26 14:30:35 UTC
Fixed upstream:
    master:
        90afedb00608547ae1f32aa7aafd552c4b306909
        ddd21d5dc3c89712d9286d1f66f4b2af73651cf2 
    sssd-1-11:
        802220cc4ef437d8f169c51c7ce073a51f507b92
        d07cb60c1f4b9a7e1618b50ca2fc817298e5db12

Comment 7 Namita Soman 2014-03-21 16:09:18 UTC
Can reproduce the issue in old client, but still seeing issue in new client.

Env:
Using a master with sssd-1.11.2-58.el7.x86_64. 
Added the setting ipa_hbac_refresh=0 to sssd.conf and restarted sssd.
Two clients are added to this master:
nocp12.testrelm.test with sssd-1.11.2-58.el7.x86_64
blade05.testrelm.test with sssd-1.11.2-42.el7.x86_64


Steps taken on master (all this in a script as suggested above to be able to test faster than the default 5 seconds timeout):
# ipa hbacrule-disable allow_all
# echo one | ipa user-add one --first=one --last=one --password
# ipa passwd one
# kinit one
# kinit admin
# ipa hostgroup-add testhostgrp --desc=testhostgrp
# ipa hostgroup-add-member testhostgrp --hosts=nocp12.testrelm.test
# ipa hbacrule-add rule1068723
# ipa hbacrule-add-service rule1068723 --hbacsvcs=sshd
# ipa hbacrule-add-user rule1068723 --users=one
# ipa hbacrule-add-host  rule1068723 --hostgroups=testhostgrp
# ipa hbacrule-show rule1068723
# kinit one
# ssh -q -o StrictHostKeyChecking=no -l one nocp12.testrelm.test echo 'login successful'
   logged in successfully
# kinit admin
# ipa hbacrule-remove-user rule1068723 --users=one
# kinit one
# ssh -q -o StrictHostKeyChecking=no -l one nocp12.testrelm.test echo 'login successful'

Actual results:
   logged in successfully

Expected results:
   user one should not be allowed to log in

Added sleep 5 before the last ssh, and user one was denied access

Looks like caching still happens with value set to 0 or should a different sequence of steps be used?

Comment 9 Lukas Slebodnik 2014-03-24 15:37:26 UTC
(In reply to Namita Soman from comment #7)
> Can reproduce the issue in old client, but still seeing issue in new client.
> 
> Env:
> Using a master with sssd-1.11.2-58.el7.x86_64. 
> Added the setting ipa_hbac_refresh=0 to sssd.conf and restarted sssd.

HBAC rules are evaluated on client. "ipa_hbac_refresh=0" should be added to sssd.conf on clients and not on the machine where ipa-server is installed.

> Two clients are added to this master:
> nocp12.testrelm.test with sssd-1.11.2-58.el7.x86_64
> blade05.testrelm.test with sssd-1.11.2-42.el7.x86_64
>

Comment 10 Namita Soman 2014-03-24 16:10:32 UTC
Verified using sssd-1.11.2-58.el7.x86_64

Output from automated script:

----------------
Added user "one"
----------------
  User login: one
  First name: one
  Last name: one
  Full name: one one
  Display name: one one
  Initials: oo
  Home directory: /home/one
  GECOS: one one
  Login shell: /bin/sh
  Kerberos principal: one
  Email address: one
  UID: 858800054
  GID: 858800054
  Password: True
  Member of groups: ipausers
  Kerberos keys available: True
New Password: 
Enter New Password again to verify: 
----------------------------------------
Changed password for "one"
----------------------------------------
Password for one: 
Password expired.  You must change it now.
Enter new password: 
Enter it again: 
Password mismatch.  Please try again.
Enter new password: 
Enter it again: 
Password for admin: 
-----------------------------
Added hostgroup "testhostgrp"
-----------------------------
  Host-group: testhostgrp
  Description: testhostgrp
  Host-group: testhostgrp
  Description: testhostgrp
  Member hosts: nocp12.testrelm.test
-------------------------
Number of members added 1
-------------------------
-----------------------------
Added HBAC rule "rule1068723"
-----------------------------
  Rule name: rule1068723
  Enabled: TRUE
  Rule name: rule1068723
  Enabled: TRUE
  Services: sshd
-------------------------
Number of members added 1
-------------------------
  Rule name: rule1068723
  Enabled: TRUE
  Users: one
  Services: sshd
-------------------------
Number of members added 1
-------------------------
  Rule name: rule1068723
  Enabled: TRUE
  Users: one
  Host Groups: testhostgrp
  Services: sshd
-------------------------
Number of members added 1
-------------------------
  Rule name: rule1068723
  Enabled: TRUE
  Users: one
  Host Groups: testhostgrp
  Services: sshd
Password for one: 
Could not chdir to home directory /home/one: No such file or directory
login successful
Password for admin: 
  Rule name: rule1068723
  Enabled: TRUE
  Host Groups: testhostgrp
  Services: sshd
---------------------------
Number of members removed 1
---------------------------
Password for one: 


...and user one did not get the "login successful" here. Verified rule wasn't cached

Comment 11 Ludek Smid 2014-06-13 10:04:55 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.


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