Bug 1807258

Summary: Cloned viewer role cannot view facts
Product: Red Hat Satellite Reporter: Jessica Hanley <jhanley>
Component: FactAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED ERRATA QA Contact: Ladislav Vasina <lvasina>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.6.0CC: lvasina, mhulan, pcreech, pjasbuti
Target Milestone: 6.11.0Keywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-07-05 14:27:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jessica Hanley 2020-02-25 22:48:20 UTC
Description of problem:

When the customer assigns the Viewer role to a non-admin user, that user can browse to Monitor > Facts to view a list of facts in Satellite 6.6.  However, when the customer removes the Viewer role from that non-admin user, clones the Viewer role and assigns the new (ostensibly identical) role to that same non-admin user and then logs into Satellite with that user, that user is unable to browse to Monitor > Facts to view a list of facts in Satellite 6.6.

Furthermore, simply adding the "view_facts" permission to a new role also fails to grant this access.  The built-in Viewer role appears to be the only way to grant non-admin users access to Monitor > Facts in the Satellite web UI.

This bug limits customers' ability to create custom user roles to fit their needs.

Version-Release number of selected component (if applicable):

Satellite 6.6


How reproducible:

100% of the time


Steps to Reproduce:
method 1:
1. clone the viewer role
2. assign the new role to a new user
3. log into satellite as the new user
4. browse to monitor > facts

method 2 (failed workaround):
1. create a new role with permission view_facts
2. assign that role to a new user
3. log into satellite as the new user
4. browse to monitor > facts

Actual results:

The list of facts is empty.


Expected results:

The list of facts should appear the same for the non-admin user with these permissions as it does for an admin user.

Additional info:

Comment 3 Marek Hulan 2021-03-23 08:16:38 UTC
I can not reproduce this on recent versions, can you please check with Satellite 6.8? If you still see the behavior, could you please enable debug log level, enable sql and permission logger and upload production.log from when you try to access tha page? See this KCS for the loggers configuration instructions https://access.redhat.com/solutions/1155573

Comment 5 Jessica Hanley 2021-03-24 23:29:37 UTC
Marek: I was able to reproduce this issue on my Satellite 6.8 server.  I've followed your instructions and attached the corresponding production.log file.

Comment 6 Marek Hulan 2021-03-25 08:32:52 UTC
This is really weird. I tested on my 6.8.3 instance, but I'm still unable to reproduce. The log also seems alright, the filter with id 34 is found when permissions are checked. It seems more like a organization/location issue. Did you assign the role to any organization and location? I'm reproducing without such assignment (and it works).

The ultimate SQL query from the log is

> SQL (5.1ms)  SELECT "fact_values"."id" AS t0_r0, "fact_values"."value" AS t0_r1, "fact_values"."fact_name_id" AS t0_r2, "fact_values"."host_id" AS t0_r3, "fact_values"."updated_at" AS t0_r4, "fact_values"."created_at" AS t0_r5, "taxonomies"."id" AS t1_r0, "taxonomies"."name" AS t1_r1, "taxonomies"."type" AS t1_r2, "taxonomies"."created_at" AS t1_r3, "taxonomies"."updated_at" AS t1_r4, "taxonomies"."ignore_types" AS t1_r5, "taxonomies"."description" AS t1_r6, "taxonomies"."label" AS t1_r7, "taxonomies"."ancestry" AS t1_r8, "taxonomies"."title" AS t1_r9, "taxonomies"."manifest_refreshed_at" AS t1_r10, "locations_fact_values"."id" AS t2_r0, "locations_fact_values"."name" AS t2_r1, "locations_fact_values"."type" AS t2_r2, "locations_fact_values"."created_at" AS t2_r3, "locations_fact_values"."updated_at" AS t2_r4, "locations_fact_values"."ignore_types" AS t2_r5, "locations_fact_values"."description" AS t2_r6, "locations_fact_values"."label" AS t2_r7, "locations_fact_values"."ancestry" AS t2_r8, "locations_fact_values"."title" AS t2_r9, "locations_fact_values"."manifest_refreshed_at" AS t2_r10 FROM "fact_values" INNER JOIN "hosts" ON "hosts"."organization_id" = $1 AND "hosts"."location_id" = $2 AND "hosts"."id" = "fact_values"."host_id" INNER JOIN "fact_names" ON "fact_names"."id" = "fact_values"."fact_name_id" LEFT OUTER JOIN "hosts" "hosts_fact_values_join" ON "hosts_fact_values_join"."organization_id" = $3 AND "hosts_fact_values_join"."location_id" = $4 AND "hosts_fact_values_join"."id" = "fact_values"."host_id" LEFT OUTER JOIN "taxonomies" ON "taxonomies"."id" = "hosts_fact_values_join"."organization_id" AND "taxonomies"."type" = $5 LEFT OUTER JOIN "hosts" "hosts_fact_values_join_2" ON "hosts_fact_values_join_2"."organization_id" = $6 AND "hosts_fact_values_join_2"."location_id" = $7 AND "hosts_fact_values_join_2"."id" = "fact_values"."host_id" LEFT OUTER JOIN "taxonomies" "locations_fact_values" ON "locations_fact_values"."id" = "hosts_fact_values_join_2"."location_id" AND "locations_fact_values"."type" = $8 WHERE ((("taxonomies"."id" IN ('1')) AND ("taxonomies"."id" IN ('2')))) AND ((("hosts"."organization_id" IN ('1')) AND ("hosts"."location_id" IN ('2')))) AND "hosts"."organization_id" = $9 AND "hosts"."location_id" = $10 AND (fact_names.name <> '_timestamp') AND "fact_names"."ancestry" IS NULL ORDER BY "fact_values"."value" ASC NULLS FIRST  LIMIT $11 OFFSET $12  [["organization_id", 1], ["location_id", 2], ["organization_id", 1], ["location_id", 2], ["type", "Organization"], ["organization_id", 1], ["location_id", 2], ["type", "Location"], ["organization_id", 1], ["location_id", 2], ["LIMIT", 20], ["OFFSET", 0]]

The most interesting part is 

> WHERE ((("taxonomies"."id" IN ('1')) AND ("taxonomies"."id" IN ('2'))))

That likely causes the issue, 1 is the id of the organization and 2 of the location. What I don't understand is, how comes the original viewer role works fine (note, the default one is not associated to any org/loc)

Comment 7 Marek Hulan 2021-03-25 08:34:44 UTC
Actually assigning org and loc to the role reproduces the issue!

Comment 8 Dominik Matoulek 2021-10-07 08:22:25 UTC
Created redmine issue https://projects.theforeman.org/issues/33656 from this bug

Comment 9 Dominik Matoulek 2021-10-08 09:09:33 UTC
*** Bug 1825268 has been marked as a duplicate of this bug. ***

Comment 10 Bryan Kearney 2021-11-04 13:47:42 UTC
Upstream bug assigned to dmatoule

Comment 11 Bryan Kearney 2021-11-04 13:47:44 UTC
Upstream bug assigned to dmatoule

Comment 12 Bryan Kearney 2021-11-19 12:02:00 UTC
Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/33656 has been resolved.

Comment 14 Ladislav Vasina 2022-04-25 16:03:23 UTC
VERIFIED
6.10.5
cloned viewer role does NOT work with loc && org set up
cloned viewer role DOES work with loc && org set up
cloned viewer role DOES work org set up
cloned viewer role DOES work with loc 
*********************************************************
6.11.0 snap 16.0
foreman-3.1.1.12-1.el7sat.noarch
ALL SCENARIOS ABOVE WORKS

Comment 17 errata-xmlrpc 2022-07-05 14:27:59 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: Satellite 6.11 Release), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:5498