[Kimchi-devel] [PATCH 0/4] ticket support for guest

Yu Xin Huo huoyuxin at linux.vnet.ibm.com
Mon May 26 07:55:20 UTC 2014


On 5/26/2014 3:01 PM, Hongliang Wang wrote:
>
> On 05/26/2014 02:38 PM, Hongliang Wang wrote:
>>
>> On 05/26/2014 02:27 PM, Zhou Zheng Sheng wrote:
>>> on 2014/05/26 13:32, Yu Xin Huo wrote:
>>>> I strongly dislike the way to change password frequently.
>>>>
>>>> Password is designed for user to recognize himself for authentication.
>>>> Frequently changing password make password itself meaningless to user.
>>>>
>>>> As it is VNC password, this will almost make vnc unaccessible to user.
>>>> Personally, I dislike to use browser to console the VM at all.
>>>>
>>>> I suspect whether there is *a justification reasonable enough* to take
>>>> the way that "changing password".
>>>>
>>>> So please exactly clarify what *threat* this "change password" 
>>>> strategy
>>>> is protecting against?
>>>>
>>> Some back-end background.
>>>
>>> The problem is that noVNC and HTML5 Spice traffic is carried on
>>> websocket outside of Kimchi server. It operates as following.
>>>
>>> noVNC --websocket--> websockify --tcp-> VNC server of the hypervisor.
>>>
>>> Since Kimchi is out of this route, we don't have means to authenticate
>>> user. The user can copy the noVNC page URL to another machine without
>>> loggin to Kimchi, and he can still access VNC.
>> For this part, I'd prefer access VNC through any VNC viewer after I 
>> created a VM, instead of only access it through Kimchi.
> I checked Virt Manager just now and it works the similar as your 
> design for Kimchi. So is it possible if I want to access Kimchi VM 
> through VNC clients (e.g., my browser is relatively too old to use 
> noVNC) ? In this case, I think a possible solution is:
> 1. Create a VM with bridged network that I can access it from other 
> machines
> 2. Install VNC server in it
> 3. Configuration the VNC server
> 4. Access it through VNC clients
>
> Does it make sense? So it will be a complete solution.
For a VM configured with any type of network, 'isolated', 'NAT', 
'bridged', it must be able to be accessed through VNC console.
As VM with 'isolated' and 'NAT' network can not be accessed from 
outside, so can not depend on VNC on guest.
>>>
>>> The most practical method to prevent unauthenticated user from 
>>> accessing
>>> VNC is to set VNC password on the hypervisor side. We thought of other
>>> means, but they either requires too much work or involves too much
>>> transport redirection.
>>>
>>> The current approach is that, for VM created outside of Kimchi, we 
>>> don't
>>> set password and everyone can visit it. For VM created outside of 
>>> Kimchi
>>> but with VNC password, when the user connects it from noVNC, Kimchi
>>> reads the password and passes it to noVNC. For VM created by Kimchi, it
>>> generates a random password.
>>>
>>> So far so good. A new problem is that currently noVNC client reads
>>> password from URL, and we don't want the password get leaked from the
>>> URL. We can make the password expire in short time and change it every
>>> time we connect. The whole process is transparent to the user, the
>>> password is generated every time, and passed to noVNC. Password
>>> generation does not affect established VNC session, it only affects new
>>> sessions.
>>>
>>> Last time I mentioned this problem, most people thought that if the 
>>> user
>>> has noVNC for Kimchi's VM, he/she would not need other VNC client. I
>>> think this may be true in most cases, but it surprises you when you
>>> actually want to use TigerVNC/UltraVNC/RealVNC/Virt-Viewer.
>>>
>>> A method to mitigate the pain is that back-end only generates the
>>> password once, and have the front-end stores the generated password in
>>> cookie. Then we can change noVNC to read password from cookie to avoid
>>> exposing password in URL.
>>>
>>>> On 5/20/2014 11:27 PM, shaohef at linux.vnet.ibm.com wrote:
>>>>> From: ShaoHe Feng <shaohef at linux.vnet.ibm.com>
>>>>>
>>>>> ticket support for guest
>>>>>
>>>>> ShaoHe Feng (4):
>>>>>     update API.md
>>>>>     ticket in backend: add a set ticket action for VM resource
>>>>>     support ticket in UI.
>>>>>     set the password for spice and VNC page.
>>>>>
>>>>>    docs/API.md                      |  4 ++++
>>>>>    src/kimchi/control/vms.py        |  1 +
>>>>>    src/kimchi/model/vms.py          | 28 ++++++++++++++++++++++++++++
>>>>>    ui/js/src/kimchi.api.js          | 33 
>>>>> ++++++++++++++++++++++++++++++++-
>>>>>    ui/pages/spice.html.tmpl         |  3 ++-
>>>>>    ui/pages/websockify/console.html |  5 +++++
>>>>>    6 files changed, 72 insertions(+), 2 deletions(-)
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Kimchi-devel mailing list
>>>> Kimchi-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>
>>>
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>





More information about the Kimchi-devel mailing list