Also, just to be explicit, this would provide process separation, but does
not address local user authentication or access control. Eg, in this
scheme plinth would have permissions to edit all configuration files and
would need to authenticate users for access control on it's own (it
doesn't do this yet IIRC).
What I would like is for the plinth process and the plinth process alone
to have access to the unix domain socket. One way to do this would be to
create a new group and use file system permissions, but "yet another
user/group" seems like a bad idea. Another way would be to have the (root
permissions) /etc/init.d/plinth script generate a secret key, register it
with the running exmachina process, and pass that secret key to plinth
which would use it to authenticate every RPC call over the pipe. This
makes me a bit queasy because I know web applications often make
accessible or dump their full environment variables and local scope as a
debug feature; surely debug mode for plinth will be disabled, but still...
-bryan
On Tue, 10 Jul 2012, bnewb...@robocracy.org wrote:
Spoke with James and a few others here at the OpenITP event, notes and a
rought plan are below. Some of this feels like reinventing the wheel; a
future/mature implementation might use:
D-Bus for message passing, PolicyKit for access control, Augeas for
read/write
or
building off ubus (IPC from OpenWrt) and netif (network interface
configuration from OpenWrt), extending with augeas configuration
or
libassuan (from GPG) to handle narrow scope trusted IPC
But for now i'm just going to bang something out so that plinth can use the
python-augeas interface through an access controlled unix domain pipe.
-----------------------------------------------------------------------------
requirements/compromises:
- scope of configuration middleware is "regular" system files, mostly in /etc
(no user/identity management)
- files should be edited "in place"
- local changes should be respected
- single root/wheel permissions level for reading, writing, and applying
changes
- configuration "versioning" taken as a seperate problem from editing
- "client code" (aka plinth) is responsible for semantic/logical validation,
and service restarts
new program: "exmachina: hand of root"
configuration management daemon which runs with root permissions,
listens on a unix domain socket with access controlled by filesystem
permissions. uses a very simple api to provide access to augeas
configuration file editing and service restarts.
plinth/apache, running not-as-root, is passed access at startup (ENV vars?
file handle pass?)
single-thread, serializes edits
simple, written in python (for now), including python "client library"
which replicates python-augeas interface
extra features (somedaymaybe):
general purpose ncurses, gui, or web interface
no-downtime reloads of daemon via HUP (a la nginx)
fine-grain ACL
dpkg installation
general purpose features: process execution, package installation, file
read/write
-bryan
_______________________________________________
Freedombox-discuss mailing list
Freedombox-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
_______________________________________________
Freedombox-discuss mailing list
Freedombox-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
