1:51 a.m.
On 03/05/2014 10:49 PM, Daniel H Barboza wrote:
Information about the issue:
https://github.com/kimchi-project/kimchi/issues/329
We had some ideas about it in the last weekly scrum:
- creating an user 'kimchi' with a lot of privileges. It is the
simplest of the solutions but
implies in a lot of annoyances (different system paths between
distros, libvirt does not
work the same way in all distros). There is no tell about the amount
of new bugs and
issues that shall emerge from such change.
- Separating the UI and the backend. This is my personal favourite but
I believe it is also
the hardest. We can implement this by separating frontend and backend
as 2 separate cherrypy processes, the backend runs as root and the
frontend runs as a
regular user. The communication would be done using the REST API. The
other approach
would be the backend running as a regular python daemon, with root
privileges, and
kimchi would communicate with it using RPC. I believe the latter is
more elegant and the
former is easier to implement.
from the cherrypy doc, we can customized the components of cherrypy
flexibly.
Not sure, we can customized WSGI components or other components.
And the let cherrypy daemon start with root, and it fork one process
with root user, let this process
to handle the libvirt API or other API need root privilege.
The father cherrypy daemon then changes him self user to "kimchi".
It handle other request does not need root privilege.
Maybe we need process communication between these processes.
That's need to look into the CherryPy mechanism to see the feasibility.
[DOC]:
Finally, there is the CORE LAYER, which uses the core API's to construct
the default components which are available at higher layers. You can think
of the default components as the 'reference implementation' for CherryPy.
Megaframeworks (and advanced users) may replace the default components
with customized or extended components. The core API's are:
* Application API
* Engine API
* Request API
* Server API
* WSGI API
These API's are described in the CherryPy specification:
Things to consider:
- Distro support: Ubuntu, for example, behaves very different from
Fedora as far as
libvirt is concerned. The packaging model (apt-get instead of yum)
differs in support
as well. I think it's a fair guess that RHEL 6 and Suse will have
different behavior as well.
- VM visibility: in the first idea (different user) only the VMs
created by this specific user
would be visible to kimchi, unless we do something about it (tweaking
libvirt configuration
perhaps?).
- User authentication. Right now the user authentication presented in
kimchi exists simply
to authenticate it as a regular user of the host. The owner of the
process will be root, doesn't
matter which user logs in (and I guess this is the critical security
flaw we have). Do we need
ro rethink the authentication model as well?
Please provide your input and ideas!
Daniel
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
--
Thanks and best regards!
Sheldon Feng(冯少合)<shaohef(a)linux.vnet.ibm.com>
IBM Linux Technology Center