The Debian init system general resolution returns

Lets make sure we've concluded the on-topic argument before moving on to the off-topic one about the security implications of relying on dbus.

you admit that logind does not in fact depend on anything being running on pid=1 Right? And you rescind your previous criticism that GNOME or anything else which depends on the logind API for functionality is implicitly dependent on any particular init being pid=1 right? I'll just go ahead and assume you've answered yes to those questions and we'll move on safe in the knowledge that you previously stated issues about high level software relying on a specific codebase running as pid=1 have now been address.

So... reliance on dbus in pid=1 as a security risk over other available ipc mechanisms available. I do not share your opinion that having pid=1 rely on dbus for IPC is an inherent security weakness. I personally look forward to the day when kdbus is a standard piece of kit for every process to rely on for inter process communication from pid=1 to pid=infinity+1.

Anyways... for everyone who agrees with you about the implications of relying on dbus in pid=1, then sysvinit with shim and cgmanager should work for you to keep logind for higher level bits of to rely on for now. You and those who agree with your opinion would of course be better off replacing shim with a fully independently developed codebase that implements the stable systemd dbus API.

As shim is just a fork of systemd and I don't see that being sustainable long term because users of that fork will be continually fighting against implementation decisions they don't agree with in the mainline codebase. That's not where you want to be.

Better to start fresh and build the implementation that works more consistently with your world view about the security risk of dbus. I've sort of hinted at extending runit with a helper to talk systemd APIs, as a way forward for you and people who share your opinion about the security of dbus while still keeping logind working. runit is in my estimation the best choice for you moving forward, as even upstart suffers from your perceived dbus over-reliance so you shouldn't even bother with resurrecting and extending it. The point being, logind will still operate as long as your independently developed service implementation running pid!=1 as long as it speaks the expected documented APIs logind expects to see.

-jef