DBus is an internal dependency for KAuth. With the wrapper users don't have to link with QtDBus.

Applications are supposed to do that?

Yes, UnixFileDescriptor allows to use existing methods Action::setArguments() and ActionReply::setData().

Without UnixFileDescriptor you could try to write

int fd = ...
Action action(...);
action.addArgument(QStringLiteral("fd"), fd);

but then KAuth won't be able to detect that it'a file descriptor and will pass it to a helper as int.

In D24245#539508, @volkov wrote:

Without UnixFileDescriptor you could try to write

int fd = ...
Action action(...);
action.addArgument(QStringLiteral("fd"), fd);

but then KAuth won't be able to detect that it'a file descriptor and will pass it to a helper as int.

Would it make more sense to add a new function

Action::addFileDescriptor(const QString &, int)?

This way we don't have to expose UnixFileDescriptor to the world

It will require adding the following methods:

Action::setFileDescriptors()
Action::addFileDescriptor()
Action::fileDescriptors()
ActionReply::setFileDescriptors()
ActionReply::addFileDescriptor()
ActionReply::fileDescriptors()

and

ExecuteJob::fileDescriptors()
ExecuteJob::newFileDescriptors()

with the condition that for progress data they can be used only with direct signal-slot connections,
because without UnixFileDescriptor we cannot guarantee the open state of file descriptors.
It doesn't seem better than exposing this class.

ok, fair enough.

Am i correct in understanding this breaks the wire-protocol for the dbus messages?

Are we sure that's fine?