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 1551141 - ipa hbacrule-mod cannot change servicecategory once for all, while in web UI it can.
Summary: ipa hbacrule-mod cannot change servicecategory once for all, while in web UI ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.4
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: ipa-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-02 21:09 UTC by Seldon Sun
Modified: 2018-10-17 07:57 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-17 07:57:32 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Seldon Sun 2018-03-02 21:09:39 UTC 
Description of problem:
"ipa hbacrule-mod rulename --servicecat='all'" returns this error:

ipa: ERROR: service category cannot be set to 'all' while there are allowed services

But in the hbacrule property page on web UI, you can set "Service category the rule applies to" to "Any Service" from "Specified Services and Groups", then save the hbacrule, and it clears out all existing services and service groups automatically. no errors return.

Version-Release number of selected component (if applicable):
ipa-server-4.5.0-21.el7.x86_64

How reproducible:


Steps to Reproduce:
1. in web UI, create a hbacrule with "services" and "service groups" defined in the bottom of its property page. by default it is "Any Service". change it to "Specified Services and Groups", then add some random services or service groups below.

2. run "ipa hbacrule-mod <rulename> --servicecat='all'" from console, you should see the fore-mentioned error messages:
ipa: ERROR: service category cannot be set to 'all' while there are allowed services

3. in the web UI, in the same hbacrule property page, change "Service category the rule applies to" from "Specified Services and Groups" to "Any Service", then click Save. now you can see all previously defined services and service groups are cleared out and save is successful.

Actual results:
described above

Expected results:
"ipa hbacrule-mod <rulename> --servicecat='all'" should be able to clear all defined services or service groups automatically, just like what is being done in web UI.

Additional info:
Comment 2 fbarreto 2018-03-05 21:45:29 UTC 
Upstream ticket:
https://pagure.io/freeipa/issue/7428
Comment 5 Florence Blanc-Renaud 2018-10-17 07:57:32 UTC 
Hi,

the behavior described in this BZ is not an issue but rather a design choice:
- when an admin uses the GUI to change servicecategory='all' for an HBAC rule, he can see *before modification* if the rule already contains services because they would be displayed in the "Services" table. This means he is fully aware of the current HBAC rule definition, and that selecting 'Any service' will erase the list of services.
- when the CLI is used, the admin may not realize that servicecategory='all' would erase a potentially long list of services. The decision was made to protect from unintentional deletion by adding the check and the error "ERROR: service category cannot be set to 'all' while there are allowed services".

Hence this BZ will be closed as NOTABUG.
Note You need to log in before you can comment on or make changes to this bug.