Bug 50264 - Don't override limits with settings from /etc/dbus-1/system.d/*.conf
Summary: Don't override limits with settings from /etc/dbus-1/system.d/*.conf
Status: RESOLVED WONTFIX
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Havoc Pennington
QA Contact: John (J5) Palmieri
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-23 01:00 UTC by Jiří Klimeš
Modified: 2014-09-12 11:27 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jiří Klimeš 2012-05-23 01:00:08 UTC
While performing some tests on NetworkManager I noticed an odd behaviour and it
showed up that I met max_replies_per_connection limit.
There was
<limit name="max_replies_per_connection">512</limit>
in /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf
(A relict from times when the default limit was only 32)

I remove the line. However, I have found that if there's a limit in a
configuration file in /etc/dbus-1/system.d/, it is applied (files appear to be processed alphabetically). Such handling thus allows one application to install a limit that is imposed for the whole system bus, which is not right IMO. So I propose to only read limits from /etc/dbus-1/system.d/system.conf and /etc/dbus-1/system.d/system-local.conf

Commit that increased default limits:
http://cgit.freedesktop.org/dbus/dbus/commit/?id=8d3d8ff55739eebd84d0d53a20a025329feafc3b
Comment 1 Simon McVittie 2012-06-25 04:51:12 UTC
(In reply to comment #0)
> However, I have found that if there's a limit in a
> configuration file in /etc/dbus-1/system.d/, it is applied (files appear to be
> processed alphabetically).

Those are the semantics of system.d. Applications generally shouldn't do things there with a global effect, but that's not a bug in D-Bus.

(For an example of something that's not "generally", consider a debugging tool adjusting global policy in an included file.)

> So I
> propose to only read limits from /etc/dbus-1/system.d/system.conf and
> /etc/dbus-1/system.d/system-local.conf

I don't think making D-Bus configuration even more confusing is what we want. "Files in system.d override system.conf, and are overridden by system-local.conf" is at least consistent and easy to explain.

Something I *would* support is a simple, realistic policy language for services, probably .ini-like (like D-Bus .service files, or systemd configuration), which only allows settings that apply to a particular service, and has a sensible level of complexity. Here's a sketch of how it might look:

    % cat /etc/dbus-1/system.d/org.gnome.SettingsDaemon.DateTimeMechanism.policy
    [D-Bus Policy]
    OwnByUser=root;
    SendFromAnyone=true

Then 99% of services could use these files instead of having a system.d/*.conf, and the remaining 1% would be easier to audit.

Filename: must be the service name + ".policy"

Keys:

* OwnByUsers: list of users who may own this name

* OwnByGroups: as above but for groups

* SendFromAnyone: if true, any user may send messages to any process
  that is in the queue for this name

* SendFromUsers: list of users who may send messages to any process
  that is in the queue this name

* SendFromGroups: as above but for groups

... and we might need something for SELinux etc. too, but that's about it. Finer-grained access control ("you may call method X and any method on interface Y, but nothing else") can be done by the service itself (via dbus_bus_get_unix_user), or using PolicyKit.

"List" means the Desktop Entry Specification "strings" type, i.e. zero or more items each followed by a semicolon, like "root;staff;".

If you wanted to design this in detail and/or implement it, I'd be happy to review.
Comment 2 Simon McVittie 2012-06-25 04:58:38 UTC
(In reply to comment #1)
> * SendFromAnyone
> * SendFromUsers
> * SendFromGroups

To keep things simple, these would have "or" semantics - you can send a message to the service if SendFromAnyone=true, or if you are one of those users, or if you are in one of those groups.

I'm not sure whether we even need the groups: things that are group-based should really be using PolicyKit instead. In current Debian practice, various things are of the form "user is root or group is netdev or at-console" - I believe the Red Hat equivalent is "user is root or at-console"?

Ideally, those messages would be allowed at the dbus-daemon level, and the service would ask PolicyKit before doing anything, meaning the policy could be configurable.

We do need at least "name may only be owned by root", and probably "name may only be owned by $someone" (for "daemon" users like the one that runs the gdm greeter).

"Only root may send to this" is probably not strictly needed - the service could check - but it would make life easier for lower-level services.
Comment 3 Simon McVittie 2014-09-12 11:27:40 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > So I
> > propose to only read limits from /etc/dbus-1/system.d/system.conf and
> > /etc/dbus-1/system.d/system-local.conf
> 
> I don't think making D-Bus configuration even more confusing is what we
> want. "Files in system.d override system.conf, and are overridden by
> system-local.conf" is at least consistent and easy to explain.

I think this is WONTFIX for this reason.

> Something I *would* support is a simple, realistic policy language for
> services

Bug #19593.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.