[rfc] move activation to a helper process

[Havoc Pennington]

David Zeuthen wrote:
> 
> Well, initially I had a whole bunch of code to cope with variable length
> messages but it's much hard to audit than if you assume message size is
> the same length. And we want this code to be as simple as possible.
> 
> It's especially hard if you want the IPC between helper and bus to not
> allocate memory from the heap at all. And we want this property, e.g. no
> heap memory allocation to guarantee responses even on OOM.
> 

OK, can go with it for now.

>>   - Why not send the .service file name instead of the bus name to
>>     activate, then we don't need the inefficient
>>     _scan_service_dir_for_desktop_file
> 
> We can't send the full path, obviously, because that would violate the
> trust model (helper doesn't trust bus one bit). So we need at least to
> parse the config file and look through the directories to find the file.
> So all we would be saving would be loading all desktop files when doing
> this, not sure it's worth the effort...

If we only ever have 5 services, then it won't matter, but if we have 50 
then the expense of this is 50*50 if most of those services end up being 
run, and this expense may well be during boot. Seems like one of those 
situations where a smartass kernel developer runs strace and is all 
"stupid dbus does 2500 stats of the same files!" ;-)

I think we can save the readdir in addition to the parsing as follows: I 
bet it's OK to trust the bus to send the right service file as long as 
we don't trust the bus to send a known service file. IOW I think the bus 
could send a full path as long as the helper ensures the path is inside 
one of the directories given in the config file. If there are two 
.service files that implement the same bus name and an evil bus wants to 
run the wrong one, I don't think it's a big deal, as long as both 
.service files are root-owned and in a system directory. (checking the 
root-owned bit is probably worthwhile ...)

What we _don't_ want to allow is running a .service file in some random 
location on the disk, of course.

>>   - the fork-without-exec is inherently somewhat confusing, I think
>>     a nice way to make it clearer would be to have a single
>>     file where all code runs in the child, exporting one
>>     function like bus_activation_helper_start_child(),
>>     where this function is called in the child immediately post-fork.
>>     but I don't know if this is easily done. I think it'd be
>>     nicer to split the BusActivationHelper struct up instead of having
>>     the in_helper flag, also.
> 
> My latest version has the split into BusActivationHelper and
> BusActivationHelperPrivate. I'll move the Private stuff into a separate
> file if possible.

The big win I think is to make it very simple to tell which things are 
in the child vs. parent

> Ugh, that sounds like real boring work. Let's discuss it after I send
> the next version :-)

OK ;-)

> Yea, I see little point in making it optional other than to have more
> than one ABI lying around. Can we go ahead and nuke that option?

We probably need to keep DBUS_HAVE_INT64 since some apps may 
conditionalize on it already, but we can declare that officially it will 
always be defined and update the docs to say this.

> Btw, I've also got fixes for BusDesktopFile (it doesn't handle OOM
> correctly) and dbus_malloc + friends (not MT-safe when DBUS_BUILD_TESTS
> is enabled).

Sounds good. This fix and also the add-newlines-to-dbus-warn should 
probably be in 1.0, so maybe you could separate them out?

It would be good to avoid locking in malloc when not building tests, if 
we locked in there it'd probably be a good 10-20% slowdown I would bet 
based on past profiling where malloc and thread locks both showed up as 
hot spots.

Havoc