Hi Juan,

Thanks for your suggestions!

On Sun, Nov 24, 2013 at 5:36 AM, Juan Hernandez <jhernand@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.