6:33 a.m.
Now I have send a patch V1, no more comments.
These days, I talk with ZhengSheng about the ticket of VM.
Now we are change our design as follow for we should care the VMs
created by other tools.
1. make the ticket as the sub-resource of a VM.
support GET(lookup) and PUT(update) method.
2. we will not set expire for ticket.
3. kimchi will set a initial random password for VM when create it.
4. PUT(update) method can set a password for a VM created by other tool.
but if expire is set for this VM, kimchi will not change the password.
or kimchi can change the password but not change the expire.
5. when GET method to retrieve the password, if the VM is create by
other-tools.
And expire is set, kimchi raise http 400 error when timeout.
6. pass the ticket to vnc/spice websocket in cookie, not in URL.
vnc/spice login page get the ticket from cookie.
--
Thanks and best regards!
Sheldon Feng(冯少合)<shaohef(a)linux.vnet.ibm.com>
IBM Linux Technology Center
11:21 a.m.
Ping.
On 06/11/2014 06:33 PM, Sheldon wrote:
Now I have send a patch V1, no more comments.
These days, I talk with ZhengSheng about the ticket of VM.
Now we are change our design as follow for we should care the VMs
created by other tools.
1. make the ticket as the sub-resource of a VM.
support GET(lookup) and PUT(update) method.
2. we will not set expire for ticket.
3. kimchi will set a initial random password for VM when create it.
4. PUT(update) method can set a password for a VM created by other tool.
but if expire is set for this VM, kimchi will not change the password.
or kimchi can change the password but not change the expire.
5. when GET method to retrieve the password, if the VM is create by
other-tools.
And expire is set, kimchi raise http 400 error when timeout.
6. pass the ticket to vnc/spice websocket in cookie, not in URL.
vnc/spice login page get the ticket from cookie.
--
Thanks and best regards!
Sheldon Feng(冯少合)<shaohef(a)linux.vnet.ibm.com>
IBM Linux Technology Center
11:03 a.m.
Hi Yu Xing,
I have done a live demo to show you the security vulnerability of our
kimchi.
So any comments on this?
On 06/11/2014 06:33 PM, Sheldon wrote:
Now I have send a patch V1, no more comments.
These days, I talk with ZhengSheng about the ticket of VM.
Now we are change our design as follow for we should care the VMs
created by other tools.
1. make the ticket as the sub-resource of a VM.
support GET(lookup) and PUT(update) method.
2. we will not set expire for ticket.
3. kimchi will set a initial random password for VM when create it.
4. PUT(update) method can set a password for a VM created by other tool.
but if expire is set for this VM, kimchi will not change the password.
or kimchi can change the password but not change the expire.
5. when GET method to retrieve the password, if the VM is create by
other-tools.
And expire is set, kimchi raise http 400 error when timeout.
6. pass the ticket to vnc/spice websocket in cookie, not in URL.
vnc/spice login page get the ticket from cookie.
--
Thanks and best regards!
Sheldon Feng(冯少合)<shaohef(a)linux.vnet.ibm.com>
IBM Linux Technology Center
7:34 a.m.
+1
Just one comment below
On 06/11/2014 07:33 AM, Sheldon wrote:
Now I have send a patch V1, no more comments.
These days, I talk with ZhengSheng about the ticket of VM.
Now we are change our design as follow for we should care the VMs
created by other tools.
1. make the ticket as the sub-resource of a VM.
support GET(lookup) and PUT(update) method.
2. we will not set expire for ticket.
3. kimchi will set a initial random password for VM when create it.
4. PUT(update) method can set a password for a VM created by other tool.
but if expire is set for this VM, kimchi will not change the password.
or kimchi can change the password but not change the expire.
Why not let user update password and expire time?
5. when GET method to retrieve the password, if the VM is create by
other-tools.
And expire is set, kimchi raise http 400 error when timeout.
6. pass the ticket to vnc/spice websocket in cookie, not in URL.
vnc/spice login page get the ticket from cookie.
10:27 p.m.
On 07/11/2014 07:34 PM, Aline Manera wrote:
+1
Just one comment below
On 06/11/2014 07:33 AM, Sheldon wrote:
> Now I have send a patch V1, no more comments.
>
> These days, I talk with ZhengSheng about the ticket of VM.
>
> Now we are change our design as follow for we should care the VMs
> created by other tools.
>
> 1. make the ticket as the sub-resource of a VM.
> support GET(lookup) and PUT(update) method.
>
> 2. we will not set expire for ticket.
>
> 3. kimchi will set a initial random password for VM when create it.
>
> 4. PUT(update) method can set a password for a VM created by other tool.
> but if expire is set for this VM, kimchi will not change the password.
> or kimchi can change the password but not change the expire.
Why not let user update password and expire time?
we can let user update password
and expire time.
For in kimchi, only the user with the permission can update password
and expire time
>
> 5. when GET method to retrieve the password, if the VM is create by
> other-tools.
> And expire is set, kimchi raise http 400 error when timeout.
>
> 6. pass the ticket to vnc/spice websocket in cookie, not in URL.
> vnc/spice login page get the ticket from cookie.
>
--
Thanks and best regards!
Sheldon Feng(冯少合)<shaohef(a)linux.vnet.ibm.com>
IBM Linux Technology Center
6:21 a.m.
On 6/11/2014 6:33 PM, Sheldon wrote:
Now I have send a patch V1, no more comments.
These days, I talk with ZhengSheng about the ticket of VM.
Now we are change our design as follow for we should care the VMs
created by other tools.
If I remember correctly, the ticket is just VNC password.
1. make the ticket as the sub-resource of a VM.
support GET(lookup) and PUT(update) method.
where does the VNC password originally stored, please do not duplicate.
you have no way to keep it synchronized if duplicate store it.
Think about if a user use virt-manager to changed a VM's VNC pass, how
can kimchi know it and update accordingly.
I feel quite strange to support to get password, I have ever only seen
change/reset password.
Password is user privacy, assuming that no one has the right to know it.
Thinking about security risk.
I think the ticket should not be the literal password, it should be an
encryption of the password and only the system has the key to decript it.
2. we will not set expire for ticket.
you can set an expire of vnc password, but
once it is expired, user need
to know and user need a way to change the password.
3. kimchi will set a initial random password for VM when create it.
And we should
provide UI for user to change the password.
4. PUT(update) method can set a password for a VM created by other tool.
but if expire is set for this VM, kimchi will not change the password.
or kimchi can change the password but not change the expire.
Add UI to change VNC
password and let user to control it.
5. when GET method to retrieve the password, if the VM is create by
other-tools.
And expire is set, kimchi raise http 400 error when timeout.
Kimchi should never
automatically change the password if kimchi
identified that password is set manually, why 'expire' matters here?
6. pass the ticket to vnc/spice websocket in cookie, not in URL.
vnc/spice login page get the ticket from cookie.
3808
days inactive
3848
days old
5 comments
3 participants
participants (3)
-
Aline Manera -
Sheldon -
Yu Xin Huo