Re: D-Bus permissions on Debian-based systems

[Dan Williams <dcbw redhat com>]

On Fri, 2008-05-23 at 18:21 +0200, Michael Biebl wrote:
> 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.

Ugh; I was hoping to avoid that.

> 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).

Right, I had assumed the same of ubuntu but of course am wrong.  Thanks
for the clarification.

> 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].

Yeah, at_console is going to die soon so don't worrry about it.  You
dodged that bullet, though it's worked OK for the past few years.

> 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.

That's what I was assuming I could do upstream.

> 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.

Yeah, you're probably right.  Or, we could use the DISTRO tag more
aggressively to do the right thing.  I'm looking at using it to
customize the path to the dhclient config file that NM would use.  I'm
not sure this is all that scalable though.

> 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.

Yeah, skip at_console since people are trying to make it go away.

dan

> 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
>