[Users] Free IPA + oVirt setup fails

i iordanov iiordanov at gmail.com
Sun Nov 24 10:08:00 EST 2013


Hi Juan,

Thanks for your suggestions!

On Sun, Nov 24, 2013 at 5:36 AM, Juan Hernandez <jhernand at redhat.com> wrote:

> Here you are experiencing two security features of the engine. The first
> one is the multiple level administration (a.k.a. MLA). The engine
> organizes objets in hierarchy: a set of data centers, then inside each
> data center a set of clusters, and inside each cluster a set of virtual
> machines. When you assign a permission to a user or group you in fact
> assign it to one of these objects, and objects deeper in the tree
> inherit them. So if you assign the "create vm" permission to user A and
> the default data center, then that user will have permission to create
> VMs on any cluster of that data center. I guess that the two users that
> you initially created had the permission on the default data center or
> the default cluster, so they have the permissions apply to all the VMs.
> Try to go to the data center or cluster tabs and see if the users have
> permissions there, then remove them as needed.
>

When I looked at the Data Centers and Clusters tabs and examined the
permissions given to the users, UserA and UserB have UserRole permissions
granted on both the default data center and the default cluster. Moreover,
I am unable to remove them, as the "Remove" selection is always grayed out.

Furthermore, examining the permissions on UserA's VM, I can see that only
UserA has been granted UseRole permission on it. No other user is mentioned.

So do the UserRole permissions granted to UserA and UserB in the Data
Center and Cluster explain the fact that they can see and attach to "other
people's VM's"?

If so, do I have to take the data center and cluster down to remove the
UserRole permissions for the users? Also, how could I prevent this
permission from getting added to the Data Center and Cluster automatically?
I haven't added it myself and it says that it's an inherited permission
(System).


>
> The other thing you are experiencing is the prevention of hijacking of
> the console of a VM.
>

Yes, I understand. I remember seeing the option you mention when
creating/editing VMs. I mentioned this more as a way to explain why UserB
was initially not able to connect to UserA's VM where in fact, it was
possible upon a clean boot.

Any additional help is appreciated!

iordan

-- 
The conscious mind has only one thread of execution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20131124/a6cab8f5/attachment.html>


More information about the Users mailing list