Comment 25 for bug 306362

(In reply to comment #23)
> (In reply to comment #21)
> > Tomas - the reason I believe that there's no interface based check is that
> > it's legal for messages to be sent to any interface.
>
> Sorry, I don't understand this. Proposed patch fixes default rule that is
> supposed to allow all requested replies. Why should it be bound to any
> specific interface?

I wasn't suggesting the system.conf change should be bound to a specific interface, just that we shouldn't rely on the destination interface in general (there is a note about this in the policy docs).

> (In reply to comment #22)

> Doesn't this make my note (end of comment #19) about not being able to use
> destination in receive rules even more valid? Removing possibility to use
> interface and method attributes will only leave sender, message type and error
> name checks for use in the receive rules (I believe path falls to the same
> category as interfaces and methods). So receive rules will have to be wide
> open to actually work (as they are now).

Right...hm. How useful are the receive rules in general? I guess you'd need them if you wanted to keep a signal private between services.

> > In other words the config file for 3rd party services should just be:
> >
> > <user="root">
> > <allow service="org.freedesktop.ConsoleKit"/>
> > </user>
>
> Is this supposed to be send or receive rule? Or some new policy concept, that
> does not distinguish the two any more?
>
> Anyway, if this is expected to be full config for some 3rd party service, dbus
> will have to get the default configuration right, so that requests from
> non-root users are denied.

I was thinking this policy would allow root to own the service name, and any uid to send&receive messages from it, under the assumption that the service is using PolicyKit for fine grained permissions, or that it makes sense for any uid to be able to access it.