Disabling new D-Bus protocol features by default

[Thiago Macieira]

Em Terça-feira 09 Novembro 2010, às 16:01:07, Marcel Holtmann escreveu:
> > The point is that, if the client isn't modified to tell the library that
> > it knows about the new types, the library will not negotiate the new
> > feature with the bus server. In turn, the bus server will not send the
> > new types over the connection.
> 
> and what is wrong with that. That seems to me the right approach. The
> server can just send an error back for such a message.

Nothing.

I was describing the approach that I want to take. You're agreeing with me 
here :-)

Currently, the first step is missing: the client doesn't tell the library 
whether it supports the new types.

> > Now they can't. We're pulling the rug under these applications, some of
> > which are quite sensitive, due to the system bus.
> > 
> > If you guys don't think this is serious, I'll wash my hands...
> 
> I am still not following you. So on one hand you say that the daemon
> does not forward the message to the client if that type is not
> negotiated. And the client disconnects as a safe-guard if it gets its
> anyway.

Let me try to clarify then:

My argument is that:

1) there was no feature negotiation mechanism in D-Bus 1.2

2) the message wire format is very rigid and doesn't support any extension 
adding new types. The only extension mechanism is providing extra ignorable 
options in the header.

3) the library and the bus disconnected peers that sent anything malformed 
(new types are malformation in 1.2)

4) there was nothing in the spec suggesting that new types could be added in 
the future. True, it doesn't say the list is exhaustive either.

With that in mind, and considering there hadn't been any types added in 5 
years, plus the discussions on adding float being shot down, many applications 
and bindings could have made the assumption that they knew about all types.

And in D-Bus 1.2, they did. We pulled the rug from under these apps.

> So at what point can you send a message with FD passing type to a client
> without FD passing and something bad happens to the remote application?
> Would it just return an error to the initial caller in that case?

If:

1) remote application was written in the remote past, like in June 2010

2) remote application uses libdbus-1 1.4

Then the local application can negotiate Unix FDs without the application 
knowing. And it can make a call with such a parameter contained either naked 
or in a variant. The remote application might not return an error: it might 
simply crash because one of its assumptions were violated. Or worse.

> I think this is not actually a libdbus-1 problem as you described it. If
> I am getting this right, then it is bindings that use a libdbus-1 that
> understands the new types, but the bindings itself don't understand it.

Correct.

> So I don't know how we end up in the condition that libdbus-1
> disconnects us from the bus. Since that should not happen. And if that
> happens then the dbus-daemon did something wrong.

Doesn't happen. That's why I said this specific part (stop disconnection) isn't 
needed. I was wrong in suggesting it.

> What I am thinking is that the bindings need to be extended to deal with
> the fact of unknown types from libdbus-1 (if they use libdbus-1) and
> then either return an error or something.

That's one solution. And I'm arguing that that's a lot of work, not to mention 
the tons of applications using D-Bus that need to be checked.

I'm arguing that it's much simpler to restore 1.2 behaviour that it doesn't 
enable new types unless explicitly asked to. There aren't many apps that use 
Unix FDs.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20101109/c1246dca/attachment.pgp>