[Freedombox-discuss] FBx config mgmt update

[bnewbold at robocracy.org]

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, bnewbold at 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 at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
>