On 27.4.2015 11:25, Tomas Radej wrote:
The basic idea is that the server runs in a privileged container or
on
the host system, and very thin client connects to it and exchange
information about assistants and commands through an API (for example
using JSON). You may think about it as "DevAssistant as a service".
Here I'm not sure what do you refer as a server and basically, what runs
where. I'll try to make some assumptions bellow, please correct me if I
get it wrong.
The client
----------
While DevAssistant uses already a sort of a client-server
architecture, the clients are still quite thick, and not easily
replaceable. Our intention is to put only the bare minimum into the
client - an engine to construct a user interface from the received
data. That means that the command line interface will construct a help
message with assistants and commands based on what is available on the
server side. Similarly, the WebUI will construct a form based on
fields that the server sends to it, generated from the arguments
specified in an assistant. The client always runs under the user that
wishes to run an assistant.
So we'll have multiple clients: CLI and WebUI. Both running on the
system the developer is primly using to interact with DA as a process
owned by the developer, e.g. "joe".
The webserver
-------------
The webserver is the front-facing part of the entire server, which
interacts with the client. What it does is spin up a "bridge" instance
(see below) for the user under whom the "client" is running, and pass
messages between the two. The webserver itself doesn't touch the
system or containers in any way, and will probably run under a unique
user, for example 'devassistant'. I expect it will take the list of
available users from /etc/passwd. I still don't know what webserver to
use, but security is definitely what we should look at first.
Now, where runs this? I would expect this to be run in a "privileged
container" as mentioned above. Why do we care under what user this runs
than? I'm afraid this is a bit confusing to me.
The bridge
----------
This is the core part of the new system, which will contain most of
today's DevAssistant package. This part runs under the user who
actually wants to execute the assistants, and is spawned by the
webserver. It loads the available assistants, runs them with
parameters supplied through the webserver, and if necessary, delegates
the execution of superuser tasks to the "service" with elevated
privileges.
I'm again confused by the user thing. This is supposed to by run as
"joe" again? Spawned by the webserver that does not run under "joe",
but
under "devassistant" user. Is that even possible, if "devassistant"
user
has no root ACLs?
Or is this also run in a container? Different one or the same one as
webserver?
The service
-----------
Since the bridge runs under a user that doesn't necessarily have all
the permissions an assistant may require, there will be a service
(DBus?) that accepts commands and executes them as the super user.
When such a command is invoked, the service will ask an authentication
agent if the user is authorised to perform such a command, and based
on the agent's reply will carry it out appropriately. If an additional
authentication is required, the bridge sends a request to the client
for proper authentication.
How does this works on non-Linux platforms than?
The agent
---------
The last part of the system is an authentication agent. This agent,
based on its policies, decides if a given user is permitted to carry
out a command passed to the "service", and return a True/False reply.
This will probably be a PolicyKit service.
The same question.
Thanks.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok