[Kimchi-devel] [PATCH v2 0/4] Github #329: "YOU SHALL NOT ... run as root!"

[Daniel H Barboza]

On 04/10/2014 01:03 AM, Zhou Zheng Sheng wrote:
> on 2014/04/09 04:50, Daniel Barboza wrote:
>> From: Daniel Henrique Barboza <danielhb at linux.vnet.ibm.com>
>>
>> Changes:
>> *v2:
>> - adressed Ramon's comment about the python path in kimchid.in
>>
>> This patch series revamps the launch architecture to allow kimchi
>> to not run as root while being exposed at an open http/https port.
>>
>> The solution adopted is using a reverse http proxy (nginx) to make
>> the 'bridge' between two distinct cherrypy processes, one running
>> as frontend as a regular user and another running as backend, as root.
>> The communication with the outside will be done through nginx, running
>> as a regular user too.
>>
>> The changes were heavy in the kimchid script, but the startup and
>> usage options still the same. User-wise, there shouldn't be any
>> functional change in the way kimchi works after applying this change.
>>
>> Refer to https://github.com/kimchi-project/kimchi/issues/329 for
>> further information in all the other approaches considered and why
>> they didn't work out.
>>
> Excellent investigation work and nice patch!
>
> Since the nginx is already run in non-root mode and forward the request
> to Kimchi, it seems there is no need to separate kimchi-backend and
> kimchi-frontend. The solution in this patch series does not improve
> security but makes the internal of kimchi unnecessarily complicated.
> This is because nginx forwards requests directly to kimchi-backend and
> kimchi-frontend. The kimchi-backend and kimchi-frontend are in the same
> level. To truly make it a secure architecture, the kimchi-backend should
> sit behind kimchi-frontend, which means the following: nginx ->
> kimchi-frontend -> kimchi-backend(root). However if we had this nginx ->
> kimchi-frontend -> kimchi-backend(root), there would be no need to use
> nginx because kimchi-frontend is non-root already.
>
> A simpler solution might be that we can just have one kimchi process
> listening on localhost, and nginx on 0.0.0.0:8000/8001 and forward all
> the requests to kimchi.

I agree that using nginx on top of kimchi is enough to solve the issue. The
separation of frontend and backend makes sense in the design point of view
and it was something I had to do in my other attempts, but it wouldn't be
necessary to solve this particular bug.

>
> As regard to your RPC investigations, I'm fully agree with you on the
> opinion that objects are complex and not all objects are serialize.
> Consider the complexity and variance of third-party libraries, it's
> impossible to have an RPC solution that work seamless and transparently
> between a so-called kimchi-frontend(root) and kimchi-backend.
>
> On the other hand. There is a way that RPC should work if we don't have
> it run transparently. Suppose all models run in kimchi-backend(root),
> and it exposes a RPC interface explicitly via JSON RPC, D-BUS or
> whatever. And the objects passed to and returned from this RPC
> interfaces should be only of the simple kind such as list, string,
> integer, dict. Then all the controllers run in kimchi-frontend(non-root)
> and it listens on 0.0.0.0:8000/8001. The controller objects should make
> explicit RPC calls to the kimcih-backend(root). From my experience,
> seamless remote objects style of RPC is always a dead end, explicit
> style of RPC always works.
>
> In all, the RPC way may need more work, but it make perfect layered
> separation between the models and controllers. If we don't have a
> layered separation between the kimchi-frontend and kimchi-backend, there
> is no need to start two kimchi process, just one is enough, then have
> the nginx run in non-root and forward the requests.

I really liked the RPC idea. I still do. But, as you said, it needs more 
work
than it looks. I've made several attempts, some of the were successful
(ex: running run_command through RPC as root) but some parts of the
code were too complex to put in RPC without reworking.

Perhaps we can solve this bug  by using the nginx approach (I am ok in
firing only one cherrypy process as root) and then work gradually in the
RPC approach? Once we have a full RPC framework we can ditch nginx
and run kimchi as regular user, firing RPC calls to remote objects that
run as root. Sounds good?

>
>> Daniel Henrique Barboza (4):
>>    Github #329: kimchid script changes
>>    Github #329: new launch script and proxy template
>>    Github #329: server, root and utils changes
>>    Github #329: config.py.in, spec, readme and makefile changes
>>
>>   .gitignore                    |   2 +
>>   contrib/kimchi.spec.fedora.in |   5 +-
>>   contrib/kimchi.spec.suse.in   |   3 +
>>   docs/README.md                |   4 +-
>>   src/Makefile.am               |   9 +-
>>   src/kimchi/config.py.in       |   9 +-
>>   src/kimchi/root.py            |   6 +-
>>   src/kimchi/server.py          | 100 ++++++++++++---------
>>   src/kimchi/utils.py           |  42 ++++++++-
>>   src/kimchid.in                | 202 ++++++++++++++++++++++++++++++++++++------
>>   src/kimchid_server.in         |  45 ++++++++++
>>   src/nginx.conf.in             |  69 +++++++++++++++
>>   12 files changed, 418 insertions(+), 78 deletions(-)
>>   create mode 100644 src/kimchid_server.in
>>   create mode 100644 src/nginx.conf.in
>>
>