on 2014/04/09 04:50, Daniel Barboza wrote:
From: Daniel Henrique Barboza <danielhb(a)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(a)linux.vnet.ibm.com
Telephone: 86-10-82454397