powerd_setuid_helper isn't a daemon; it's executed by powerd occasionally to perform various tasks.

It does the following:

a) Runs "mosys eventlog add <code>", where <code> is a hex byte like "0xa7". I think that this is used to log suspend/resume events on some systems.

b) Runs "initctl emit --no-wait runlevel <level>", where level is 6 or 0, to reboot or shut down the system.

c) Runs "ectool forcelidopen <state>", where state is 0 or 1, to prevent the EC from immediately shutting down the system when the user reboots while in docked mode.

d) Runs set_wifi_transmit_power with --tablet or --notablet to configure the wifi chipset's transmit power.

e) Runs powerd_suspend with various flags to suspend the system.

---

I don't have any idea about whether it's feasible to run mosys, initctl, or ectool as a non-root user.

set_wifi_transmit_power uses netlink. I'm not sure whether it can be used as a non-root user either.

It may be possible to change the ownership of relevant /dev and /sys nodes so that powerd_suspend can run as the same "power" user that powerd uses, but when I tried before it was challenging due to its need to interact with a bunch of random hotplugged devices.

Abhishek and I discussed this pretty extensively and given some current requirements on powerd_setuid_helper I don't think this is feasible in the short term.

Abhishek, mind linking some of the documents you wrote while figuring out the wakelock situation?

It was for alarms. Going over our email chains, I think the main issue was that the helper needed to be root to talk to initctl.

i'm not sure about that statement.  dbus access to upstart is gated by ACLs and we can control access on a per-user/group basis to endpoints/methods.

check out the /etc/dbus-1/system.d/ directory for boards ... there should be a lot of examples.

http://upstart.ubuntu.com/wiki/DBusInterface says that "the initctl, telinit and shutdown utilities included with Upstart use an alternate method [to communicate with Upstart]". I don't see any initctl-like methods documented there.

I also have slight concerns about making powerd reliant on D-Bus to communicate with Upstart, but at the same time, I wouldn't be surprised if powerd is already hosed and likely to crash or hang if dbus-daemon is broken.

if dbus goes down, the system is not usable, and the only reasonable course of action is to reboot.  our dbus.conf init script already takes care of doing that:
post-stop script
  # The system is unusable if dbus-daemon crashes; the various daemons
  # that were connected to it won't re-register their service names, so
  # they won't be able to talk to each other. Instead of attempting to
  # respawn dbus-daemon, reboot the system to get back to a sane state.
  logger -t "$UPSTART_JOB" "dbus-daemon exited unexpectedly; rebooting"
  uptime_sec=$(awk '{ print $1 }' </proc/uptime)
  metrics_client -t Uptime.DBusCrash "${uptime_sec}" 1 1000000 50
  reboot
end script

so having a hard depend on dbus in any system service should not be a problem at any level.