4:36 a.m.
On 11/24/2013 01:57 AM, i iordanov wrote:
Hey,
I actually realized that something I wrote is inaccurate.
UserB, who was not granted permission to any VM was actually able to
connect to a freshly booted UserA's VM. Subsequently, UserA was unable to
connect to "his own VM" anymore, and the error message was:
Operation Failed: [user cannot force reconnect to vm]
When UserB then shut down UserA's VM, UserA was able to power it on and
attach to it. Subsequently, UserB was not able to connect to the VM again
with the same message UserA was getting (user cannot force connect to vm).
What I expected is that UserB would not see, not be able to power control,
and not be able to attach at all to UserA's VM, so this behavior is quite
puzzling to me!
Any clarification and help would be appreciated!
Thanks,
iordan
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.
The other thing you are experiencing is the prevention of hijacking of
the console of a VM. For desktop virtual machines the engine
automatically remember who was the last user that connected to the
console of the VM, and will not allow connections by other users. This
is to protect the console. Imagine that user A opens the console of
virtual machine X, then logs in to the operating system and opens its
very confidential document in its favorite application. Then user B,
tries to access the same console and gains access to the confidential
document. To prevent this this console hijacking is disabled by default,
in order to hijack the console the virtual machine X has to be first
rebooted, because these guarantees that the confidential document isn't
available. However, if you need to allow this console hijacking you can
use a flag in the "Console" section of the VM properties dialog, click
in "Show advanced options" and then you will see a "Advanced
parameters"
section that contains a "Disable strict user checking" checkbox.
Checking that checkbox disables this behavior. Also, you can give the
permission to hijack consoles to users editing their roles and adding
the action VM -> Administration Operations -> Override opened console
session.
On Sat, Nov 23, 2013 at 7:50 PM, i iordanov <iiordanov(a)gmail.com> wrote:
> Hi Juan,
>
> On Sat, Nov 23, 2013 at 3:03 PM, Juan Hernandez <jhernand(a)redhat.com>wrote:
>
>> Did you change it while the server was running? If so during stop the
>> server will probably overwrite the file. Try to change it after stopping
>> the server:
>>
>
> Yes, it was absolutely because the server was running and was writing out
> its configuration upon being stopped.
>
> In fact modifying the file is not good practice, you may prefer to do it
>> using LDAP:
>>
>
> I guess this method would not have suffered from the clobbered config file
> :D. Thanks for the additional tip, I'm quite new to LDAP.
>
>
>> I have just tested this in my local environment and with minssf=1 it
>> works correctly, including the ability to search for users in the LDAP
>> directory from the administration GUI and using those users to log in to
>> both the administration GUI and to the user portal.
>>
>
> I can definitely now confirm that changing minssf to 1 worked around the
> issue.
>
> However, I'm faced with either an issue or a misunderstanding of how
> things work in oVirt. I was able to add a couple of users to IPA (user A
> and user B) and then import them with UserRole into oVirt. What is puzzling
> is that both are able to see(!!) and power on/off(!!!!!) all the machines
> which were created by and for user admin@internal. Some of these machines
> are based on the Blank template and some on a different template (if that
> matters). Thankfully, at least the new users are unable to attach to the
> console of those machines.
>
> When I created a new virtual machine and in the permissions added user A
> as UserRole, user A now has access to the console of that VM. However, what
> was again puzzling is that user B can see and power on/off the new virtual
> machine, but at least cannot attach to the console (consistent with my
> previous findings).
>
> I would have thought that users would "see" and be able to power on/off
> only their own VMs, and something tells me that this is the way it was
> intended. So what do you think is broken in my test rig?
>
> Thank you very much!
> iordan
>
> --
> The conscious mind has only one thread of execution.
>
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.