Le 25/02/2020 à 09:05, Steve Litt a écrit :
On Mon, 24 Feb 2020 12:21:16 +0000
Daniel Abrecht via Dng <dng@lists.dyne.org> wrote:
...
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.
Yep, socket, signals, fifos, inotify, netlink, semaphores,
shared-memory, what else?
It's probably possible to build some well thought middleware with
these, but Dbus isn't that one.
Dbus more complicated than the others, and cast against C++
concepts, which isn't a sign of quality. It was designed to match the
needs of the two biggest integrated blobs ever written for Linux, Gnome
and KDE. The aim is to "facilitate" a few things for the user, but it's
a little gain for a huge cost.
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.
Well, suid binaries are still the only way to obtain root
priviledge. pkexec is one more; it does the same thing as login, su, and
sudo, in a different way.
Didier
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
