Talk with Mark about the separation of frontend/backend. Thanks for him to contribute the following idea: We think even for backend, not all codes need to run as root, such as iso search, directory creation and so on. Gurentee safe may be minimize of use of root. For previledge cmd: run as super user and limit cmds needed to a single module. For libvirt connection: Enable libvirt connection authentication, we can add sasl user in libvirt for kimchi. On 2014年03月05日 22:49, 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.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel