Template UID in body and table column differ
|Assignee:||Ruben S. Montero||% Done:|
|Category:||Core & System|
|Target version:||Release 5.4|
|Affected Versions:||OpenNebula 5.2|
<hydro-b> ONE devs: I'm pretty sure I've found a bug that only shows up in very specific conditions <hydro-b> a template owened by a owner/group is visible (listed, not able to USE it) for another user / group <hydro-b> no ACL granting the rights here on this template (only owner allowed to ADMIN / MANAGE <hydro-b> shows up in both CLI / SUNSTONE <hydro-b> _and_ the UID of the user (that is able to see the template) should be the same as the UID of the TEMPLATE <hydro-b> I've spend already 5 hours to recreate this on a clean bootstrapped ONE, but not happening there <hydro-b> I can reproduce in a test-environment (clone of production) <hydro-b> spent* <hydro-b> in a multi tenant environment this might leak sensitive info <hydro-b> I'have not seen this happening for any other resource (VNET, IMAGE, etc.) <hydro-b> If I change ownership for template to "oneadmin" and back to original owner, the template is not visible anymore for the user <hydro-b> there is no difference between a "template show -x template_id" before and after changing ownership <hydro-b> ... but ... looking in the database there _is_ a difference <hydro-b> select * from template_pool where name='template_name'; -> uid from template is the same as newly created user <hydro-b> not in the XML definition in the database, but in the "uid" table <hydro-b> column* <hydro-b> hmm, reverted back to original situation. uid is already of a _non existent_ user in database ... before the actual users gets created <hydro-b> how is that possible? <hydro-b> Is this something a "onedb fsck" should spot?
#2 Updated by Ruben S. Montero almost 4 years ago
- Status changed from Pending to Closed
- Resolution set to worksforme
I've doubled checked the code:
1.- Chown is a generic method operating on the ObjectSQL interface. So in the overall logic there is no difference regarding the UID update.
2.- Once uid is changed the object the xml is generated based on that, I do not see how this may lead to the DB status described (apart from a DB related error)
ACL's are "compiled" and updated every TIMER interval, it may be related to this. However ownership are implicit ACLs not updated in this process.
I'll close this as work for me. 5.4 disables the object cache that may be also causing this problem. We will reopen if this happens in 5.4