-
Bug
-
Resolution: Unresolved
-
Major
-
6.18.0, 6.18.1
-
False
-
Proton Refinement Backlog
-
sat-proton
-
None
-
None
-
None
-
None
-
No
Problem Summary
The RHSM endpoint /rhsm/owners/sm_org/system_purpose is failing with:
NoMethodError: undefined method `allows_taxonomy_filtering?' for Katello::Api::Rhsm::CandlepinProxiesController:Class
This endpoint worked 6+ months ago but started failing in recent versions.
Root Cause
When the Bug Was Introduced
Commit 3a2b9592d (September 10, 2025) - "Fixes #38731 - Include user's taxonomies in authorization checks"
This commit enhanced the authorization system to include user taxonomy scoping in permission checks. It added new logic that calls allows_taxonomy_filtering? on resource classes during
authorization.
The Underlying Bug
The actual bug has existed since 2014 in the Katello codebase:
File: /home/vagrant/katello/app/controllers/katello/api/rhsm/candlepin_proxies_controller.rb
Lines: 534 and 537
::User.current.can?(:view_organizations, self)
The problem: self refers to the controller instance, not a model. When passed to Authorizer#can?:
1. The authorizer treats self.class as the resource class
2. This evaluates to Katello::Api::Rhsm::CandlepinProxiesController (a controller class)
3. The September 2025 enhancement tries to call allows_taxonomy_filtering? on this controller class
4. Controllers don't have this method (only ActiveRecord models do) → crash
Why It Worked Before
Before commit 3a2b9592d, the authorization code didn't call allows_taxonomy_filtering? on the resource class, so the bug remained dormant.
Solution
Remove the self parameter from all can? calls in the authorize_proxy_routes method.
Analysis: Searched the entire candlepin_proxies_controller.rb file and found exactly TWO occurrences of .can? being called with self as a parameter. Both are in the
authorize_proxy_routes method and both need to be fixed.
File: /home/vagrant/katello/app/controllers/katello/api/rhsm/candlepin_proxies_controller.rb
Change 1 (line 534) - Affects rhsm_proxy_owner_pools_path:
# Before:
User.consumer? || ::User.current.can?(:view_organizations, self)
# After:
User.consumer? || ::User.current.can?(:view_organizations)
Affected endpoints:
- /rhsm/owners/:organization_id/pools (when no consumer param)
Change 2 (line 537) - Affects rhsm_proxy_owner_servicelevels_path and rhsm_proxy_owner_system_purpose_path:
# Before:
(User.consumer? || ::User.current.can?(:view_organizations, self))
# After:
(User.consumer? || ::User.current.can?(:view_organizations))
Affected endpoints:
- /rhsm/owners/:organization_id/servicelevels
- /rhsm/owners/:organization_id/system_purpose ← User's failing endpoint
These are the ONLY two occurrences of this bug pattern in the entire controller.
Implementation Notes
- This changes the authorization check from a specific-object check to a global permission check
- The user will be authorized if they have view_organizations permission for ANY organization (filtered by their taxonomy scope)
- This is the correct behavior - the route-level authorization should check if the user has the permission at all, not on a specific object
- The organization-specific authorization happens elsewhere (in set_organization_id and find_organization methods)
Testing
After the fix, the user should be able to successfully call:
curl --silent --show-error --insecure --user sm-user:**** \
--request GET 'https://cct-617.usersys.example.com:443/rhsm/owners/sm_org/system_purpose'