On Mon, 24 Feb 2020 12:21:16 +0000
Daniel Abrecht via Dng <dng@???> wrote:


> So next, why is dbus needed?
> dbus is a message bus. There usually is one for the whole system, and
> one for each session.
> There are various uses and missuses for it, but I think the most
> crucial things are:
> * Notify any process interested in something of these things.
> * Tell other programs which can do something to do something.

The cost is the world's biggest modularity global variable. Everyone
can write it, everyone can read it. Yeah, there are ways of aiming a
dbus message at a specific process (I think), but just tracing stuff
through dbus is incredibly daunting.

> This can be useful for various things, for example:
> * A program may want to now if a device got rotated, so it can
> rotate a screen.

Or, you can use dmenu to call a script that rotates the screen. It's
not automagical, but it gets the ultimate railroad switchyard dbus out
of the loop.

> * A wlan management gui may want to tell it's daemon that it shall
> connect to a wlan, and it may want to know what connections it
> already has and manages.

Sockets (You address this later).

> * A phone call application may want to ring when a call arrives, or
> it may want to let the user initiate a call.

I don't understand the relationship between this one and dbus. Phone
call comes in, the app decides what to do.

>
> Now, those examples are mainly things that would need the system bus.
> I couldn't come up with a good example solely within a user
> session/bus, but I'm sure these exist too, especially because dbus
> doesn't need a graphical session.
>
> And with that, back to polkit.

My understanding is that the systemd folks have coopted/kidnapped
polkit. If that's true, my life would be simpler doing a few things
manually, or writing a few more shellscripts.

> It'd be bad if just
> everyone/everything could do system level stuff, so per default,
> noone can. But that would make dbus useless for a lot of things.
> This is the problem polkit is there to solve, there are config files
> specifying who (user, group, etc.) can see/use which methods calls,
> signals/messages, etc.

I can't think of it at a moment's notice, but there's got to be a
better way than the global switchyard dbus and the systemd coopted
polkit.
>
> Without dbus, applications & daemons could do similar things using
> unix sockets. However, then, every application would need their own
> socket, permission management, configs, etc.

The preceding is true only if every app needed to be in every other
app's business. For the vast majority of them, this just isn't true.
For the few that need this, there are sockets, fifos, and signals.


> This would have the same
> security implications as just using dbus, which also just uses unix
> sockets, but would leave a bigger attack surface, and a lot of
> scattered security critical configs with different formats.

If every app required it. In a client-server situation, the user of the
server would need to be in a specific group. If it's even that
important. I don't really care if somebody else gets into my mplayer
fifo.

>
> Now, there is also the approach of using a suid binary for the
> privileged stuff. As a good and bad thing, just like sudo, this can't
> escape a container, unlike a unix socket passed to one could.
> However, it would leave the problem of a bigger attack surface, and a
> lot of scattered security critical configs with different formats,
> and is very difficult to get right.

I think suid binaries have fallen out of favor, for the reasons you
mention.

In summary, I would fully agree with you if everything absolutely had
to talk to everything else. But such permiscuous talking leads to all
sorts of problems. Encapsulation is a wonderful thing for stability and
maintainability.

SteveT

Steve Litt
February 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive