ignoring NEGOTIATE_UNIX_FD

[Simon McVittie]

Martin Vidner wrote:
> note that the integers in the message are not the FDs

For clarity: this is a statement about the D-Bus "wire protocol" (what
goes over the Unix socket), as documented in the D-Bus Specification.
D-Bus implementations and bindings might follow this, or might do
something else; refer to the documentation of your D-Bus implementation
to find out how it represents file descriptors.

The C API presented by GDBus is fairly close to the wire protocol in
this respect: you get a GVariant of type G_VARIANT_TYPE_HANDLE, whose
numeric value is an index into the GUnixFDList attached to the message.
For instance, if g_variant_get_handle() returns 5, that's not your file
descriptor: the actual file descriptor is whatever is returned by
g_unix_fd_list_get (list, 5, &error).

The C API presented by libdbus is different, and is what Thiago is
referring to here:

On 07/11/12 23:57, Thiago Macieira wrote:
> The 
> library converts the index into the Unix ancillary data to a real file 
> descriptor

This is specifically a statement about libdbus.

Bindings that wrap libdbus might follow libdbus' behaviour, or they
might do something else entirely. For instance, dbus-python will give
you a dbus.UnixFd object containing the fd, which is automatically
closed if the UnixFd object is destroyed without calling its take() method.

> which you *must* close.

More precisely, what libdbus returns is a new file descriptor similar to
the one returned by the C functions dup() and open() (POSIX::dup() and
POSIX::open() in Perl): so you must close it, unless you specifically
want it to remain open (either because you're still using it, or you're
deliberately "leaking" it).

"systemd inhibits the power key until I close the fd, and I want the
power key to be inhibited until I exit" is one of the few reasons why
you might want to deliberately "leak" a file descriptor.

    S