4 ms·

Finally some actual feedback. Which alternative IPC + capability delegation protocol do you wish linux used instead?

by SSLy 3y ago

enriquto 3y ago
> Which alternative IPC + capability delegation protocol do you wish linux used instead? Why "alternative"? Aren't file-based operations good enough? A program reads and writes data to files/devices, which it can or cannot do according to the permissions that it sees. From the point of view of the program, nothing else is needed beyond fopen,fread and fwrite. If finer control is needed, it's not for the program to implement, but for the OS to expose. An improvement to the dbus+polkit mess would be something that programs don't link to, something that is entirely invisible to programs beyond the possibility to open certain files at runtime.
- freedomben 3y ago
  > Why "alternative"? Aren't file-based operations good enough? For some things yes, for other things no. If you're just making a basic config, yeah writing to a text file can be sufficient. Though, that requires defining a protocol/standard and following that. You could use a socket, but similarly that requires a protocol, possibly at multiple levels in the stack. Besides adding unnecessary overhead, that also loses all the OS-level information such as which user/privilege level is the caller running as? Now suppose you need it to be highly and quickly reactive (or what we used to call "event driven"). Suppose you also need to impose authentication and access controls. You could use the built-in file stuff for authn/authz, but not really event driven and most solutions to that are slow and bolted-on, and there's no pre-defined schema (so back to protocol defining). You could use socket but no built-in authn/authz. I rejoice in simplicity, and strongly prefer it when possible. But limiting only to simple solutions means there's a lot of stuff you can't do, and when you need to do those things, this is not great. And if you have to learn and use multiple solutions based on the level of complexity of the use case, then it may be simple from the dev's point of view, but it's certainly not from the operator's point of view.
  - gunapologist99 3y ago
    But if we look at the operations that dbus is actually used for, they don't seem to be as complex as all of the capabilities that dbus provides. It's like saying your init should basically be another entire operating system instead of just a service orchestrator; by reducing the API surface area, we not only increase security and decrease footprint, we also end up with composability and replaceable layers because other components might even be simpler but with the same API. By defining this as a huge, complex problem that needs to be solved, the solution area naturally has to be much larger and encompass a far greater API and provide a lot more capabilities instead of the minimum capabilities to accomplish the far more limited goal. Growing the problem domain and thus the solution is always a huge temptation but ultimately results in the opposite of modularization and good system design.
    - freedomben 3y ago
      > But if we look at the operations that dbus is actually used for, they don't seem to be as complex as all of the capabilities that dbus provides. I'm not sure this is true, certainly not for desktop users of Gnome and KDE. Just NetworkManager makes extensive use of D-Bus, and if you are writing an application that needs to care about (read or write) the state of the network, D-Bus is very useful and offers some powerful functionality. On my Fedora machine I jsut ran `busctl list | wc -l` and got 175 (meaning 174 buses available), so it is being used quite extensively. Watching `sudo busctl monitor org.freedesktop.NetworkManager` is fascinating. I'm certain that there are applications using it that aren't using the full capabilities, but if it already needs to be in place, I don't think it adds complexity to use it for simple situations where a file might be sufficient. In fact I think somewhat the opposite. If everything were in D-Bus, there's only one place to look and you learn how to use it once and it's immediately useful for many things. If every application is using a homegrown/custom/bespoke IPC solution, you have to get into the details for every single thing. That sounds a lot more complex to me. But that said, I bet we probably agree more than we disagree. If the application just needs to take in some configuration at runtime and doesn't need IPC, then using D-Bus is overkill and a bit cringey. I would much, much prefer a config file. If there's runtime changes though, that's where D-Bus starts to make sense to me.
creshal 3y ago
Honestly just a wrapper that makes it easy for programmers to have RPC over unix sockets (spawn multiple with different ACLs for fine-grained permissions, if you really need to - but usually you don't. cap delegation is overrated). And then pick any popular serialization library that is already supported in all languages and stick with it. JSON would be nice for the easy users, but you do wany to exchsnge binary data over IPC, so that would maybe be a bit too simpld. I don't have any strong preferences when it comes to binary serialization/rpc protocols, though.

Finally some actual feedback. Which alternative IPC + capability delegation protocol do you wish linux used instead?

by SSLy 3y ago

Finally some actual feedback. Which alternative IPC + capability delegation protocol do you wish linux used instead?

> Which alternative IPC + capability delegation protocol do you wish linux used instead? Why "alternative"? Aren't file-based operations good enough? A program reads and writes data to files/devices, which it can or cannot do according to the permissions that it sees. From the point of view of the program, nothing else is needed beyond fopen,fread and fwrite. If finer control is needed, it's not for the program to implement, but for the OS to expose. An improvement to the dbus+polkit mess would be something that programs don't link to, something that is entirely invisible to programs beyond the possibility to open certain files at runtime.

freedomben 3y ago
> Why "alternative"? Aren't file-based operations good enough? For some things yes, for other things no. If you're just making a basic config, yeah writing to a text file can be sufficient. Though, that requires defining a protocol/standard and following that. You could use a socket, but similarly that requires a protocol, possibly at multiple levels in the stack. Besides adding unnecessary overhead, that also loses all the OS-level information such as which user/privilege level is the caller running as? Now suppose you need it to be highly and quickly reactive (or what we used to call "event driven"). Suppose you also need to impose authentication and access controls. You could use the built-in file stuff for authn/authz, but not really event driven and most solutions to that are slow and bolted-on, and there's no pre-defined schema (so back to protocol defining). You could use socket but no built-in authn/authz. I rejoice in simplicity, and strongly prefer it when possible. But limiting only to simple solutions means there's a lot of stuff you can't do, and when you need to do those things, this is not great. And if you have to learn and use multiple solutions based on the level of complexity of the use case, then it may be simple from the dev's point of view, but it's certainly not from the operator's point of view.
- gunapologist99 3y ago
  But if we look at the operations that dbus is actually used for, they don't seem to be as complex as all of the capabilities that dbus provides. It's like saying your init should basically be another entire operating system instead of just a service orchestrator; by reducing the API surface area, we not only increase security and decrease footprint, we also end up with composability and replaceable layers because other components might even be simpler but with the same API. By defining this as a huge, complex problem that needs to be solved, the solution area naturally has to be much larger and encompass a far greater API and provide a lot more capabilities instead of the minimum capabilities to accomplish the far more limited goal. Growing the problem domain and thus the solution is always a huge temptation but ultimately results in the opposite of modularization and good system design.
  - freedomben 3y ago
    > But if we look at the operations that dbus is actually used for, they don't seem to be as complex as all of the capabilities that dbus provides. I'm not sure this is true, certainly not for desktop users of Gnome and KDE. Just NetworkManager makes extensive use of D-Bus, and if you are writing an application that needs to care about (read or write) the state of the network, D-Bus is very useful and offers some powerful functionality. On my Fedora machine I jsut ran `busctl list | wc -l` and got 175 (meaning 174 buses available), so it is being used quite extensively. Watching `sudo busctl monitor org.freedesktop.NetworkManager` is fascinating. I'm certain that there are applications using it that aren't using the full capabilities, but if it already needs to be in place, I don't think it adds complexity to use it for simple situations where a file might be sufficient. In fact I think somewhat the opposite. If everything were in D-Bus, there's only one place to look and you learn how to use it once and it's immediately useful for many things. If every application is using a homegrown/custom/bespoke IPC solution, you have to get into the details for every single thing. That sounds a lot more complex to me. But that said, I bet we probably agree more than we disagree. If the application just needs to take in some configuration at runtime and doesn't need IPC, then using D-Bus is overkill and a bit cringey. I would much, much prefer a config file. If there's runtime changes though, that's where D-Bus starts to make sense to me.

creshal 3y ago

Honestly just a wrapper that makes it easy for programmers to have RPC over unix sockets (spawn multiple with different ACLs for fine-grained permissions, if you really need to - but usually you don't. cap delegation is overrated). And then pick any popular serialization library that is already supported in all languages and stick with it. JSON would be nice for the easy users, but you do wany to exchsnge binary data over IPC, so that would maybe be a bit too simpld. I don't have any strong preferences when it comes to binary serialization/rpc protocols, though.