(ps: this is the same comment I've made in github https://github.com/kimchi-project/kimchi/issues/329) I've been working in this issue for about 10 days. The approach I've chosen was to use RPC to separate the backend (the 'model' and 'mockmodel' classes) running as root from the UI running as regular user. If done right, the frontend code will use the model classes like it always did, but these classes will have root privilege because they were instanced by the RPC server (which runs as root). Now I'll explain why it didn't work so far, lol. The RPC I've been using is called PyRO (https://pypi.python.org/pypi/Pyro4). It's rather simple to make it work and at first solved the problem. As far as I could tell the UI, launched as regular user, was dealing with the RPC model object just fine. However the model test (test/test_model.py) was failing in a test called test_asynctask for a reason that at first I didn't understand. After further investigation, the core reason was that this RPC has limitations about the python objects it can provide across the wire using serialization. The Model class does not contain elemental python structures only. It contains threads, for example. And the asynctask.py (invokd by test_asynctask AND uses threads) was not behaving as it should, causing non-trivial errors in test_model (thus wouldn't be usable by the UI as well). My attempts to try to fix it weren't promising. I've tried a serializer that is more generic to transmit the RPC, but this requires an update of PyRO version. The version that Fedora 19 installs by default is 4.12, I needed the latest (4.24). After the update I've been facing a lot of misbehavior from the RPC, things that were working weren't working anymore and so on. Then it occurred to me that this wouldn't be acceptable (or would be a huge pain) to maintain in all the distros kimchi supports, such as RHEL6.5. I do not believe we can rely on another 3rd party software behavior across all the supported distros for the proper behavior of kimchi. And there's also the uncertainty that even with the latest version, there's no guarantee that the model classes would get too complex to be "serializable" by the RPC and sooner of later stop working properly. That said, I'm putting this RPC effort to a halt. What I've started to do is try to launch a second cherrypy process, running as root, running only the backend classes (no UI enabled), to provide the frontend with the info it can't get from the regular user. I believe this approach will require more work, but it's certain to work across all distros without relying in another 3rd party software. As always, any help/tips are appreciated :) On 03/05/2014 11:49 AM, 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