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

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

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