> * What could we gain by providing access to the system D-Bus in a > labeled zone ? > What would work that is useful that doesn't now ? > What new things could we do using D-Bus that would benefit labeled > zones ? > Are there existing things we could solve easier ?
Right the only system bus service is HAL, and HAL consumers on Solaris include: - removable storage manager (gnome-volume-manager) - printer autoconfiguration (project Presto) - power management (battery applet, gnome-power-manager) - libusb and libusb-based applications (PDA sync, PTP cameras, etc) It does not mean, however, that making system bus available in zones would suddenly make all this functionality magically available to zones. NetworkManager is also a system bus service, but it is not yet part of Solaris (and not clear if or when it will be). > * What type of information is on the system D-Bus ? > How sensitive is that likely to be ? > Remember that we must be very careful about opening up > channels that could be used to communicate between labeled zones. HAL broadcasts messages (signals) about devices being plugged and unplugged, which is not very sensitive, but sensitive enough that the Tamarack-on-Sun Ray effort has been stalled due to it. Ability to route signals only to certain users (or better, sessions) is not present in current DBus. I suspect the information NetworkManager publishes on the bus is of comparable sensitivity. Don't forget about method calls. DBus has pluggable authentication, but what's available now might not be sufficient. Also remember that in addition to session and system bus mode (over unix sockets), it also supports network mode (inet sockets) - which is not widely used, but something to consider wrt virtual environments. If you let your imagination go, DBus can be used for all kinds of information. If DBus sounds too foreign to you, think of sysevents and doors. They are as generic and subject to similar risks to DBus. > * Is access always read/write or would read only access be useful / > available ? I think we would be getting ahead of ourselves if we tried to answer this now. > * Would a trusted proxy be needed to filter what information can be > seen? [ I and Stephen both suspect so but lets not assume that is the > only solution ]. To a certain extent, the dbus-daemon itself is a proxy. Clients are not directly connected to services. dbus-daemon does authentication, routes messages, isolates connected clients from each other. It could, in theory, be made zone-aware, and run in "zone mode". Attempting to cascade two daemon instances and/or bridge two busses would be tricky and likely rejected by the DBus community (we tried that before). DBus is successful because of its simplicity and any intent to beef it up would be an uphill battle. Are there easier ways to get what you want? That's a million dollar question. Especially considering where you started your inquiry, i.e. not exactly knowing what you want ;) -Artem
