[rfc] move activation to a helper process

[John (J5) Palmieri]

On Mon, 2006-10-16 at 10:21 -0400, David Zeuthen wrote:
> Hi,
> 
> Here's an almost finished patch for moving activation into a helper
> process. This enables us to fork off the activation helper early and
> keep it running as root, thus being able to make activation on the
> system message bus useful.
> 
> Details
> 
>  - Move some test harness around
>  - BusContext now requires a function to clean up
>  - The bus process and the helper process communicate over a pair
>    of pipes. I specifically avoided using D-Bus as the IPC because
>    if the bus process is compromised the likely way it is compromised
>    is by libdbus being compromised. The protocol is very custom and
>    simple. Should be feasible to do security audits on it.
>  - Helper process is written with paranoia in mind - it does not trust
>    the bus process
>  - There's a new 'User' key that can be set in service files to specify
>    what user to run the activated service as
> 
> TODO's
> 
>  - What should we do if 'User' key is not set for system bus activation?
>    Just run it as root?
>  - Conversely, what to do if 'User' key is set for session bus
>    activation? Just refuse to run it?
>  - The test suite fails, says OOM handling doesn't work. I'm looking at
>    this, I think I'm doing the wrong thing if a BusTransactions fails,
>    should be feasible to fix (any quick ideas what I'm doing wrong?)
>    Apart from OOM handling the test suite works and this is good as the
>    test suite exercises a lot of the activation subsystem.
>  - Not sure how to do OOM tests for helper since it's a separate
>    process, ideas welcome
>  - Not sure how add meaningful tests to activation-helper.c, ideas
>    welcome too
>  - Some general cleanups and removing some noise I've introduced in
>    places.
> 
> Anyway, I think the patch is in a state and I'd like feedback on the
> approach and details too. Thanks!

It is a pretty large patch and I do not want it in 1.0 personally.  I
would prefer it be in 1.1 and tested for a long time.  To that end I am
sure we would add the patch to OLPC to get that testing in since we need
some of its functionality.

I will look at the patch in more depth when I have some time.  If others
think it should go in 1.0, let me know but there is a high barrier as it
is not blocking any of our core use cases for 1.0.

-- 
John (J5) Palmieri <johnp at redhat.com>