Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1576110

Summary:	Org admins not able to view system
Product:	[Community] Candlepin (Migrated to Jira)	Reporter:	Richard Bernleithner <rbernlei>
Component:	candlepin	Assignee:	candlepin-bugs
Status:	CLOSED CURRENTRELEASE	QA Contact:	Katello QA List <katello-qa-list>
Severity:	high	Docs Contact:
Priority:	high
Version:	2.5	CC:	akaiser, asakpal, bcourt, csnyder, khowell, redakkan, skallesh, sriley, wpoteat
Target Milestone:	---
Target Release:	---
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:	2018-07-11 12:09:12 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 Richard Bernleithner 2018-05-08 21:20:32 UTC

Description of problem: Org admins are not able to view some systems with invalid hypervisor reference 

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


How reproducible:


Steps to Reproduce:
1. Log on as affected org admin (ex:ende_tecnologias)
2. View affected system (ex:609bb124-da3c-4555-ba30-e26d330b40c0)
3.

Actual results:403 error Permission required


Expected results:
Able to view system

Additional info:

This appears to be an issue with these systems pointing to a bad/invalid host system. If you check the system facts for the systems that could not be accessed: 
1. They all have a system fact "virt.uuid" 
2. All of those "virt.uuid" facts point to a hypervisor that doesn't exist 
3. When we lookup these invalid virt.uuids, it can trip a bug on our backend system which causes the backend system to return a real hypervisor, but a hypervisor that isn't owned by the customer 
4. Since the (incorrectly returned) hypervisor isn't owned by the customer, he doesn't have permission to view the details about said hypervisor, which means he can't see the page as a result 

The workaround, until we fix the bug on the backend, is to have the customer update the systems' virt.uuid system facts, so that they point at a correct hypervisor. These are the incorrect values currently associated with each of the systems:

Comment 1 Shayne Riley 2018-05-09 15:08:58 UTC

After digging into this a bit more, I realized I wasn't using virt.uuid correctly. In fact, virt.uuid IS (eventually) referencing a valid hypervisor consumer, however that hypervisor consumer is not owned by the same owner of the guest.

Thus, the reason that the RHSM Web base for the affected system returns a 403 is because when RHSM Web retrieves the host information with:
GET consumers/609bb124-da3c-4555-ba30-e26d330b40c0/host
...the host belongs to a different owner that the user (an org admin) is not a part of.

So, the BZ isn't about a non-existent hypervisor. The BZ is really about how guest consumers are allowed to say they are owned by somebody else's hypervisor.

Comment 2 Shayne Riley 2018-05-09 15:23:45 UTC

Since this issue is about guest consumers being registered against a different owner's hypervisor, is there a fix/workaround that the customer can do until candlepin disallows guests belonging to a different owner's hypervisors? Like, can a virtwho config change be made so that the guests are pointing to a hypervisor they own?

Sidenotes:
- In at least one case, the customer had 0 hypervisors registered to their account. I found this weird, as I would have expected if the owner had guest consumers, then the owner should have had at least one hypervisor too, but nope.
- In another case, one customer's guests were each double registered, one to a hypervisor they owned, and one to a different owner's hypervisor.
- For whatever reason, it it always just one different owner. The guests of one owner could all be hosted by different hypervisors, but all those hypervisors are owned by the one (different) owner.

Comment 6 Shayne Riley 2018-05-22 13:58:52 UTC

How does one retrieve the virt-who configuration? What files do they need to provide?

Comment 12 Barnaby Court 2018-07-11 12:09:12 UTC

Closing as current release given that 2.3.8 just went live in production yesterday. If you are still seeing this issue please reopen.