[kde-freebsd] virtualbox file dialog problem

Andriy Gapon avg at FreeBSD.org
Wed Aug 28 12:10:38 UTC 2013

on 18/07/2013 10:06 Andriy Gapon said the following:
> on 18/07/2013 03:25 Greg Rivers said the following:
>> On Wed, 17 Jul 2013, Andriy Gapon wrote:
>>> I run virtualbox in KDE environment.  A while ago (can't say exactly when) I
>>> started to have a problem where any file opening dialog would fail with this
>>> message: "Cannot talk to klauncher: Not connected to D-Bus server"
>>> I found that setting KDE_FORK_SLAVES=1 in environment works around the problem.
>> I reported this same problem in this[1] thread on freebsd-ports at .  In that post
>> I provided a link to a similar report for KDE on openSUSE that required a dbus
>> patch to fix.
>> I'm guessing that either the latest versions of VirtualBox have a bug in their
>> dbus interface, or the version of dbus we have needs to be updated.
>> [1] http://lists.freebsd.org/pipermail/freebsd-ports/2013-July/084783.html
> I saw those OpenSUSE reports but I think that they were against the much older
> version of dbus.

I have done some more investigation and the problems turns out to be dbus
related indeed.

The problem has only a tangential relation to KDE, so I plan to drop kde@ from
this thread.  It has a relation to what VirtualBox does, so I am keeping
emulation at .  It is related to dbus and gnome@ is its maintainer(s).  It is also
related to how issetugid(2) works, so I am including standards@, security@ and
hackers at .
So, please excuse me for such a wide distribution list, but I think that the
solution should be negotiated among the parties involved.

Now a description of the problem.

1. VirtualBox executable is installed setuid root.  Apparently, when it is run
it does some privileged things and then drops all of the uids and gids (real,
effective and saved) back to what they should have been originally.
VirtualBox does not do any (re-)exec of itself after the above manipulations.

2. issetugid(2) (which is apparently a BSD extension) on FreeBSD does not
consider the above manipulations as sufficient to mark an executable as
untainted.  So it would return 1 for the VirtualBox process.

3. dbus code seems to impose some limitations on communication by such "tainted"
processes.  It has the following code:
For web-impaired :) the gist is that on BSD systems the code uses issetugid but
on other systems (like Linux) it uses getresuid and getresgid and checks that
all 3 uids are the same and all 3 gids are the same.

As a result, on FreeBSD the dbus code would consider the VirtualBox process
tainted and that impairs its communication with KDE components.
On systems without issetugid or those that implement it differently, dbus would
work as for a normal process and all the communications are OK.

I've also verified this conclusion by forcing dbus to use the alternative logic
on FreeBSD.

So, possible solutions:

A. change how issetugid(2) works on FreeBSD; a comment in sys_issetugid hints
that other BSDs may have different behaviors
B. change VirtualBox to be friendly to FreeBSD issetugid(2) and exec itself
after dropping the privileges
C. patch dbus port to not use issetugid(2)
D. something else

What do you guys think?

Andriy Gapon

More information about the freebsd-security mailing list