Plugins » Katello

Non-admin users cannot curl /rhsm/ endpoints even if they have proper permissions

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:

1. Before:
   User.consumer? || ::User.current.can?(:view_organizations, self)

1. 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:

1. Before:
   (User.consumer? || ::User.current.can?(:view_organizations, self))

1. 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'