Re: [Dng] idea for discussion: why 1 dbus [long e-mail]
On Wed, 25 Feb 2015 17:02:42 +0100 Godefridus Daalmans fr...@daalmansdata.eu wrote: Well, I have an idea for a discussion about re-architecting Linux, however it is very likely that this is just my lack of understanding speaking: I am aware that task #1 is providing Devuan Jessie (without systemd), and that is already enough work. Personally I consider task #2 to do a little discovery and documenting of what kinds of middle-ware I have on my Linux box and how it all interacts (things like: what is akonadi/nepomuk/colord/avahi and do I need all of that). My personal belief is that akonadi and nepomuk are every bit as evil as systemd. But that's not the main thrust of your post... So I have a weird question for discussion, to study the *design* of dbus together on this mailinglist with you lot who are probably a lot smarter than me. I think that's a good idea, either on this mailing list or some sort of DNG SIG list. Please be gentle and provide arguments if you think I'm talking crap :-) Alright, I'll be gentle. I HATE YOUR GUTS. Just kidding :-) Why is there 1 dbus program (instead of 2 or 3)? I have not looked at the source, but from the freedesktop.org documentation I learned that dbus is responsible for the following tasks in modern user-space Linux: 1. IPC between user programs in a GUI user session context (dbus --session) 2. one-way system - GUI session notification of events (dbus --system), e.g. when a USB stick is inserted 3. one-way GUI session - system root-privilege system commands (dbus --system), e.g. suspend, shutdown, reboot My impression of dbus is dbus is to your OS as a global variable is to a Python program. Everybody reads it, everybody writes it, that's how everybody communicates, and if somebody gets it wrong, the results are very hard to diagnose. By the way, I try never to use global variables in my programs. Dbus afficianados will counter that dbus has addressing schemes so that process A can tell dbus it's only interested in messages from process K and process M, and that process A must name recipients when posting to dbus. OK, fine, it's more like a global object in a Python program, but things can still go wrong. And if somebody maliciously sends to dbus... I see where your 3 way division could cut down on dbus vulnerability. Theoretically, having a field in a dbus send identifying which of the 3 the send was meant to be would do the same thing, I think. [snip] Why does this need to be a complicated and error prone message bus? Why not just an executable? Describe it for the LSB and be done with it: dbus_system shutdown = shutdown, dbus_system powersave = order the CPU to slow down, etc. The preceding is way beyond my level of knowledge. I've always tried to avoid using dbus. Like you said, a discussion would be interesting. SteveT ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] idea for discussion: why 1 dbus [long e-mail]
Well, I have an idea for a discussion about re-architecting Linux, however it is very likely that this is just my lack of understanding speaking: I am aware that task #1 is providing Devuan Jessie (without systemd), and that is already enough work. Personally I consider task #2 to do a little discovery and documenting of what kinds of middle-ware I have on my Linux box and how it all interacts (things like: what is akonadi/nepomuk/colord/avahi and do I need all of that). So I have a weird question for discussion, to study the *design* of dbus together on this mailinglist with you lot who are probably a lot smarter than me. Please be gentle and provide arguments if you think I'm talking crap :-) Why is there 1 dbus program (instead of 2 or 3)? I have not looked at the source, but from the freedesktop.org documentation I learned that dbus is responsible for the following tasks in modern user-space Linux: 1. IPC between user programs in a GUI user session context (dbus --session) 2. one-way system - GUI session notification of events (dbus --system), e.g. when a USB stick is inserted 3. one-way GUI session - system root-privilege system commands (dbus --system), e.g. suspend, shutdown, reboot From my naïve (and slightly wary) point of view, these tasks are all very important, but not of the same *nature*. For example, why is there no watershed between two different services, call them dbus_session and dbus_system, where: - dbus_session will open a UNIX type socket /var/run/session/uid/sessionid/dbus (/var/run/session/uid is -rwx--), all the user's programs have equivalent security access to this, so there is no need for crypto and security in dbus_session at all (simplifies), very fast and useful for IPC, cut-and-paste etc. This program needs to be fast because it performs tasks that happen often, e.g. copy-paste of a large photo from gimp to e-mail. Doesn't X11 have some really crappy IPC implementation already, and doesn't it use /tmp/.X11-unix/X0 UNIX type socket? - dbus_system_notification: I don't know why this must be secure. On the one hand, you might want to limit transmitting sensitive information to all users of the computer (e.g. somebody put DVD The Sound of Music into DVD drive 8), but on the other hand, how are you going to distinguish which users or even user sessions are allowed and which are not allowed to discover this information? Anyway, my naïve idea is why not read man 7 unix carefully and have some kind of group that is allowed to connect to this event subscription socket, and somehow grant those users who are actually logged in on the console or local X11 session, temporary membership of that group? (I have not tried this myself, can you tell?) These things probably are of a publish-subscribe nature so a message bus makes sense, I guess. But then a message bus where only root can write to it and the subscribers can only listen to it. Maybe this is best done with an UDP INET type socket? (I don't actually know if you can do connectionless or no-timeout one-to-many stuff over an UNIX socket) I suspect that the amount of data sent is really small and will fit into 1 packet, but latency might be a nuisance. - dbus_system_command: must be highly secure. I haven't thought as much about this one. It is silly to use crypto to talk to it over a systemwide open socket, because that means you have an instant privilege escalation problem on fast machines: a hacker can break into e.g. lpd account, and do a brute force attack via the dbus system bus to shut down the system, change the hostname, date, or whatever. The only protection is that the correct bitstream sent to the dbus daemon needs to be guessed. I suspect that all of these tasks are security-critical but not time-critical, i.e. a shutdown command doesn't matter if it takes a whole second but it does matter that a student doesn't shut down the workstation where another student is running a 3 month long quantum chemical calculation (this kind of shit happens in workstation-land, believe me). Why does this need to be a complicated and error prone message bus? Why not just an executable? Describe it for the LSB and be done with it: dbus_system shutdown = shutdown, dbus_system powersave = order the CPU to slow down, etc. If you have read all this, a 10 for effort! :-) Frits ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] idea for discussion: why 1 dbus [long e-mail]
* On 2015 25 Feb 10:03 -0600, Godefridus Daalmans wrote: Personally I consider task #2 to do a little discovery and documenting of what kinds of middle-ware I have on my Linux box and how it all interacts (things like: what is akonadi/nepomuk/colord/avahi and do I need all of that). Unless one is running KDE (whatever they call it these days), akonadi/nepomuk are not an issue. colord is billed as a means to manage color profiles--it is not installed on my Sid box although libcolord2 is installed to satisfy a dependency by libgtk-3-0. avahi implements a server for mdns, AIUI, and is needed by Pulse Audio to move sound over the network, for one example. So I have a weird question for discussion, to study the *design* of dbus together on this mailinglist with you lot who are probably a lot smarter than me. Please be gentle and provide arguments if you think I'm talking crap :-) Why is there 1 dbus program (instead of 2 or 3)? Most likely because it has mostly been restrained to its problem domain and no one has been troubled enough by it to reimplement a replacement. After this I don't know enough to comment further but I find your thoughts interesting. - Nate -- The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true. Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
