Notes and questions about remaining todo's and FIXME's marked 1.0

John (J5) Palmieri johnp at
Fri Sep 8 13:43:06 PDT 2006

The following are notes and questions on the remaining todo items.

/* FIXME 1.0 - we will unconditionally unlink() the path if
               * we don't support abstract namespace.  unlink() does
               * not follow symlinks, but would like independent
               * confirmation this is safe enough. See also
               * _dbus_listen_unix_socket() and comments therein.
/* FIXME discussed security implications of this with Nalin,
       * and we couldn't think of where it would kick our ass, but
       * it still seems a bit sucky. It also has non-security suckage;
       * really we'd prefer to exit if the socket is already in use.
       * But there doesn't seem to be a good way to do this.
       * Just to be extra careful, I threw in the stat() - clearly
       * the stat() can't *fix* any security issue, but it at least
       * avoids inadvertent/accidental data loss.

mclausen and I looked over this.  Since you can only unlink sockets you
have permission to there is no huge implication here.  You could unlink
another D-Bus socket but in practice this would be very unlikely.
Proposal is to remove the 1st FIXME and change the second FIXME to just
a comment.

/* setgroups() only works if we are a privileged process,
   * so we don't return error on failure; the only possible
   * failure is that we don't have perms to do it.
   * FIXME 1.0 not sure this is right, maybe if setuid()
   * is going to work then setgroups() should also work.
  if (setgroups (0, NULL) < 0)
    _dbus_warn ("Failed to drop supplementary groups: %s\n",
                _dbus_strerror (errno));

  /* Set GID first, or the setuid may remove our permission
   * to change the GID
  if (setgid (gid) < 0)
      dbus_set_error (error, _dbus_error_from_errno (errno),
                      "Failed to set GID to %lu: %s", gid,
                      _dbus_strerror (errno));
      return FALSE;

Should we change this to return an error or not?

/* Drop any service ownership. FIXME 1.0? Unfortunately, this requires
   * memory allocation and there doesn't seem to be a good way to
   * handle it other than sleeping; we can't "fail" the operation of
   * disconnecting a client, and preallocating a broadcast "service is
   * now gone" message for every client-service pair seems kind of
   * involved. Probably we need to do that though.
Is this important for 1.0?  How would I go about preallocating "service
is now gone" message for every client-service pair broadcast?

 * FIXME @todo 1.0? the error messages here would ideally be
 * so we don't need to allocate memory to send them.
 * Using the usual tactic, prealloc an OOM message, then
 * if we can't alloc the real error send the OOM error instead.

This looks involved because even if you had a preallocated message
you would need to set the destination which could throw an OOM error.
Is it important for 1.0?

* @todo 1.0? there's a memory leak on some codepath in here, I saw it
 * when running make check - probably some specific initial cookies
 * present in the cookie file, then depending on what we do with them.

Any clue if this is still an issue.  Can it be tracked down? 

 * @todo 1.0 if someone can verify it's safe, we could avoid the
 * memleak when doing an unset.

Nalin seems to think there is no safe way of doing this

* @todo 1.0? This needs to wake up the mainloop if it is in
* a poll/select and this is a multithreaded app.

Not sure what this todo is getting at.  We already do
_dbus_connection_wakeup_mainloop (connection); in this function.

* @todo 1.0? We need to be able to distinguish "out of memory" error
* from "the data is hosed" error.

The problem here is we call into virtual methods:
        return (* auth->mech->client_decode_func) (auth, encoded,
        return (* auth->mech->server_decode_func) (auth, encoded,
Can those methods return OOM?  If so the solution would be to pass a
DBusError to them.  Where are the implementations for client_decode_func
and server_decode_func?

 * @todo 1.0? when you start blocking, the timeout is reset, but it
 * really only use time remaining since the pending call was created.

This is a bit more involved than I first thought.  Timeouts are done in
intervals and not based on time stamps.  Not a big issue so I think we
should punt this for now.  It can be fixed later.

John (J5) Palmieri <johnp at>

More information about the dbus mailing list