On Wed, 26.11.14 10:04, Thiago Macieira (thi...@kde.org) wrote: > On Wednesday 26 November 2014 12:27:16 Lennart Poettering wrote: > > > Please also note that the autostart solution has a valid use-case which is > > > when a D-Bus application is launched in an environment where no bus had > > > been started before. I understand this is out-of-scope for kdbus, since > > > after all a regular user won't be able to create a kdbus bus if one > > > wasn't provided by a privileged process before. In an environment where a > > > kdbus bus wasn't provided, the only alternative is to fallback to dbus1. > > > > Hmm? Creating busses requires no privileges. Users create their own > > busses without requiring any kind of privilege for that. > > How is that secure? That would imply that any process, with any UID, can > issue > KDBUS_CMD_BUS_MAKE for a bus name that another UID would expect to use. > > I must be misunderstanding something.
The kernel enforces that each bus name is prefixed with "$UID-". This is why the system bus is /sys/fs/kdbus/0-system rather than just /sys/fs/kdbus/system. This makes sure that users cannot play games with other users. > > > > Note that on dbus1 systemd systems we actually never provided > > > > UpdateActivationEnvironment correctly (since services got forked off > > > > PID 1, instead of dbus-daemon but the call would alter dbus-daemon's > > > > env block, not systemd's one), but nobody ever noticed. I really > > > > think you should just return some "not supported" error or make it a > > > > NOP if you don't want to pass this on to systemd. > > > > > > I *want* to pass this to systemd, somehow. So the first question is > > > whether we can expect there to be a connection by systemd in the buses it > > > creates. On the system bus, there's org.freedesktop.systemd1 so I expect > > > that to continue. Can we expect a similar service on systemd-user buses? > > > > Yes. systemd creates the bus and then acquires > > org.freedesktop.systemd1 on it, and does this for both the system and > > the user bus the same way. > > My argument was for a more generic name, such as something in the > org.freedesktop.DBus hierarchy. That way, if someone else wants to provide > kdbus-powered buses, they'd implement that interface instead of trying to > emulate systemd and playing catch-up and possibly bug compatibility. I am really not keen in defining a new abstract bus interface for two functions of which at least one is very questionnable anyway, and where it's not clear that there will ever be a second implementation of... I mean, the two operations are not even really abstractable since both the update-env stuff and the reload stuff have different semantics on systemd: they are much more comprehensive and apply to all services at once instead of just the bus services. I mean, it sounds OK to me to pass this to systemd for compat reasons in a quirky way. But it if we define an abstract, well-defined, standardized interface for this with inherently unclean semantics this is really nothing I want to do. > Further, if it does acquire the org.freedesktop.DBus name itself, libraries > won't have to emulate most of the compat behaviour by intercepting outgoing > messages. Intercepting means EVERY message needs to be inspected at one point > or another, instead of letting it fallback when the call actually happens. In > other words, providing a fallback service optimises for the right > use-case. This kind of half/half solution sounds messy to me. Either emulate it or don't. But having some of the calls emulated on the client-side and some elsewhere sounds messy. > > There's an ioctl for that too, that the creator can then call on the > > fd it has open. > > I guess I got confused by the wording of what you can do with what file > descriptors. I was under the impression that you'd need three file > descriptors > for a bus or an endpoint to make any useful use > > 1) one fd that opened the "control" file (to create a bus) or to the bus (to > create the endpoint) > 2) one fd that you'll want to open the bus/endpoint on so you can later send > updates to the policies > 3) one fd to actually do talking on > > My confusion was that the doc says that after CMD_xxx_MAKE the file > descriptor > can't be used again. 5.3 says "... is file descriptor will manage the newly > created endpoint resource. It cannot be used to manage further resources." I > guess I read "further resources" as including changing policies on this > bus/endpoint. > > Thanks for the clarification. I recommend adding a section on what steps to > do > to create a bus (including setting up policies, activators), one on creating > an endpoint, and then one on how a controlling process should operate to > manage the bus/endpoint properly. To create a bus you open the "control" file, issue an ioctl (MAKE_BUS) on the fd, and the fd is then *converted* into a reference to the bus. You can use it then only for updating policy and for eventually closing it to make the bus go away. To create a bus connection you open the bus file, issue an ioctl (HELLO) on the fd, and the fd is then *converted* into a connection fd. You can then use that for send/recv messages, or acquiring/releasing names. To create a bus EP you open the bus file, issue an ioctl (MAKE_EP) on the fd, and the fd is then *converted* into a reference to the EP. You can use it then only to update the EP's policy, and for eventually closing it to make the EP go away. The systemd PID 1 instance has only two fds open hence: one bus reference, and one bus connection. A sandboxing app executor has one, maybe two fds open: the EP reference, and maybe a bus connection in case it wants to offer some services... > > Well, but in those cases you can just use the user bus or system bus, > > there's no need to create a new bus just for the purpose of P2P... > > That implies changes to the user application. I want to provide a replacement > API for DBusServer. So, if this is about compat with old apps then continue to use AF_UNIX for that... No need to push them to something new... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel