Starting the kdbus discussions

[Lennart Poettering]

On Wed, 08.01.14 08:12, Marc Deslauriers (marc.deslauriers at canonical.com) wrote:

> > Nope. This is really not how this is supposed to work. These concepts
> > are opaque to the kernel on purpose.
> 
> So you're not willing to change any of your design to cope with the community's
> requirements?

You are funny.

Discussing things doesn't mean that we will agree on anything and
everything participants suggest. We have to say no sometimes, if we
technically disagree, and you really need to understand that technically
disagreeing is really just that: disagreement on technical things.

And also, if two designs are incompatible, then there are at least two
ways to make them compatible: change the first, or change the second. I
find it kinda weird to assume that it has to be kdbus that is adapted
for apparmor and not the other way round. In particular as the kdbus
folks have no interest in apparmor, but the apparmor people apparently
in kdbus...

And anyway, since when does Canonical equal "the community"? A single
participant doesn't make a community. If we listed to the "community"
you are referring to, then we would already have stopped development of
kdbus, since your colleagure Ted suggested hat kdbus should not have
been written at all in one of his earlier mails...

> > This really misses the point. We get rid of the XML policy because it is
> > misdesigned, and not just because we want to replace XML by somer other
> > formatting.
> 
> I disagree. Removing the central location where policy can be enforced is the
> bad design. You're moving trust from the system into the applications
> themselves.

If you believe that the XML policy is such a fantastic thing, then I
think sticking to dbus-daemon would be the best option. On kdbus XML
policy is only supported to a compatibility level, and its on its way
out. 

> > addition, in many many cases looking at the mere method call
> > interactions between clients and servers will not work anyway, if you
> > don't have any context for it.
> 
> PolicyKit only works if you trust the daemon that is using this. We want a
> better security model than that, a model where you don't need to trust the
> daemon, or you can assume the daemon could be compromised.

Riiiiigght... Because trusting a single super-privileged huge program
(the kernel) is so much better than trusting neatly seperated small
processes that run at minimal priviliges each.

> Well, so much for attempting to collaborate into making something that can be
> used by everyone. Once again, we are going to be accused of doing our own thing.

You know, demanding changes from us and whining if you don't get them
about how super unfair the whole world is will get you exactly nothing.

I don't have the intention with making *everybody* happy. I don't think
that is even possible. I am quite happy if I at least make a substantial
part of developers happy, that's the most I am trying to do.

Lennart

-- 
Lennart Poettering, Red Hat