Dan Williams wrote:
Hi, I spent half of yesterday banging my head on a desk trying to get the D-Bus permissions correct for Ubuntu 8.04. Can somebody explain exactly how the D-Bus permissions for NM on Debian-based systems are supposed to work? It's all group-based, right? For example, my current understanding is that the applet's permissions file should have group="netdev". But AFAIK, allowing 'root' to own a service should be universal. Some of it might have to do with D-Bus not correctly handling permission file changes underneath it while it's running, sometimes requiring a SIGHUP to completely re-read the policy after doing a 'make install'. That happens everywhere. But the more frustrating thing was nm-dhcp-client.conf, which allows 'root' to own the service but apparently that's not correct out-of-the-box on Ubuntu 8.04. Does debian's dhclient drop privileges after binding to the port? What user should nm-dhcp-client.action use? So far we have: NetworkManager.conf - should be owned by 'root' and nobody else, but should allow console/privileged users to talk to it. I assume that means that debian wants group="netdev" in addition to at_console. nm-applet.conf - should allow console users to own the service, should allow anyone to query the service, but should ONLY allow root (ie, NM) to ask for secrets nm-dhcp-client.conf - should allow the user that dhclient runs as to own the service nm-dispatcher.conf - should allow 'root' to own the service nm-openvpn-service.conf - should allow 'root' to own the service nm-system-settings.conf - should allow root to own the service, should allow anyone to query the service, but should ONLY allow root (ie, NM) to ask for secrets nm-vpnc-service.conf - should allow 'root' to own the service I'd like to get the required changes to the D-Bus permissions files upstream. I know I could have pulled stuff from somebody's PPA (and I did pull dbus-glib, thanks!) but the point is, of course, to make NM easier to both install from source, and easier for packagers to package on Debian-based distros.
Unfortunately, the situation is a bit more complicated (or diverse) as Ubuntu and Debian differ subtly in this matter.
Debian traditionally uses groups for applying permissions (the pam-console package from Redhat was never included/used in Debian). So, also the dbus at_console directive is not used/supported in Debian (might change though. more on that later). For controlling access to certain D-Bus services (like hal), there are groups like plugdev (mounting of removable media), powerdev (power management related) and netdev (mostly used for controlling access to NM).
Ubuntu has patched dbus to support libpam-foreground stamps, so their dbus version supports at_console. With the recent switch to ConsoleKit, they intend to get rid of libpam-foreground again though, and they have patched CK to write pam_console compatible stamps to /var/run/console [1].
As Debian maintainer, I usually keep both a at_console (even if its useless atm on Debian) and the group based section.
E.g. my NetworkManager.conf (for 0.6.6) currently looks like
...
<policy group="netdev">
<allow send_destination="org.freedesktop.NetworkManager"/>
<allow send_interface="org.freedesktop.NetworkManager"/>
</policy>
<policy at_console="true">
<allow send_destination="org.freedesktop.NetworkManager"/>
<allow send_interface="org.freedesktop.NetworkManager"/>
</policy>
...
This is only, to reduce the diff against the Ubuntu package and make it
easier for someone to pull the Debian package and recompile it for Ubuntu.
On to dhcp: It's correct that Ubuntu uses a separate dhcp user to run the dhclient under, Debian uses root. (Ubuntu generally uses a more aggressive approach in that direction. E.g. their syslogger has a separate user, hald-addon-storage doesn't run as root, etc.)
I'm not sure how to handle that properly upstream. You could add two sections, one for root and one for dhcp. But then dbus would complain on distros which don't have a dhcp user. Imho this is the kind of customization a distro has to do and shouldn't necessarily end upstream. Even if that means that it makes it harder for people to run it on Ubuntu from pristine SVN.
Back to the at_console issue: I'm part of the Debian dbus maintenance team, and there was a discussion to include the CK patch from Ubuntu [1], which would mean that Debian would also support at_console in the future.
The question is, if at_console still makes sense with the rise of PolicyKit. E.g. the latest hal version ships a completely open dbus policy configuration, where everyone can invoke methods. HAL internally uses PolicyKit to control the access in a much more fine-grained manner.
As NM already uses PK for the system-settings service, maybe it would make sense to go the same route.
Cheers, Michael [1]http://bugs.freedesktop.org/show_bug.cgi?id=14053 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature