on 2014/04/09 04:50, Daniel Barboza wrote:
From: Daniel Henrique Barboza <danielhb@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. 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.
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
-- Thanks and best regards! Zhou Zheng Sheng / 周征晟 E-mail: zhshzhou@linux.vnet.ibm.com Telephone: 86-10-82454397