[Kimchi-devel] [RFC] Github #329: Kimchi must not run as root

[Daniel H Barboza]

(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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>