Just to clarify a bit, I think this should probably land in the state that it is currently in, along with a conf file to add a system bus event bridge in the user session.
The reason that I think the system event bridge needs to be in the user session is so that the bus is connected to as the user, so the usual protections there (AppArmor for instance) will be able to monitor that connection. I don't think that using the system dbus event bridge is a good idea, because it could result in these mechanisms being subverted. That doesn't mean I think it couldn't be fixed, but I don't think it should block the feature landing because the work around of having two event bridges per session will work and isn't that expensive (the event bridge is small). In the next version of the dbus event bridge I think that it needs to have some way for the job to get the parameters of the signal. Both for the start criteria and to get them in the job. I'd recommend doing it similar to the DBus filter syntax where instead of parameters environment variables are set to ARG0, ARG2, etc. Also, limiting it to 32 like dbus filter rules. -- https://code.launchpad.net/~jamesodhunt/upstart/upstart-dbus-bridge/+merge/161772 Your team Upstart Reviewers is requested to review the proposed merge of lp:~jamesodhunt/upstart/upstart-dbus-bridge into lp:upstart. -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
