Hello,

I have the following problem: I use tigervnc 1.3.1 to connect to my Debian 7.5 installation (64-bit). When I use an application which needs root privilege for all or specific tasks, I don't get a popup from Kdesu to prompt for the password.

For example: I start KDE systemsettings and klick "Date and time". Right under the heading there's written "you are not allowed to save the configuration" and when I change something and click Apply, I get a popup saying "Unable to authenticate/execute the action: 4,".

This is an issue between VNC and KDE. I don't have this problem for applications that don't use KDE for rendering the window, like Synaptic packet manager. And I don't have this problem for the "original", non-VNC desktop.

To workaround the problem, I tried to start the application with kdesu -u root "application". Then I get the popup to prompt for the password, but after entering it, the app starts as an empty, grey window!

It's not a Debian specific problem, I've seen it on other distributions as well (e.g. openSUSE). Thanks for any advice.

SH

P.S.: Debian 7.5 uses KDE 4.8.4

Some additional info: I can also use kdesudo instead of kdesu -u root , it makes no difference.

When I run kdesudo systemsettings from the Terminal, I get:

QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
X Error: BadAccess (attempt to access private resource denied) 10
Extension: 130 (MIT-SHM)
Minor opcode: 1 (X_ShmAttach)
Resource id: 0xdd
X Error: BadShmSeg (invalid shared segment parameter) 128
Extension: 130 (MIT-SHM)
Minor opcode: 5 (X_ShmCreatePixmap)
Resource id: 0x4f
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
Major opcode: 62 (X_CopyArea)
Resource id: 0x5a0001a
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
Major opcode: 62 (X_CopyArea)
Resource id: 0x5a0001a

(...and I get the empty grey window)

When I run just systemsettings, I only get the first two lines (QDBusConnection...).
(...and I get the normal window)

Sheriff Hobbes wrote:X Error: BadAccess (attempt to access private resource denied) 10
Extension: 130 (MIT-SHM)
Minor opcode: 1 (X_ShmAttach)
Resource id: 0xdd
X Error: BadShmSeg (invalid shared segment parameter) 128
Extension: 130 (MIT-SHM)
Minor opcode: 5 (X_ShmCreatePixmap)
Resource id: 0x4f

Looks similar to the permissions issue regarding the MIT-SHM extension (caused by a security fix in libqt4) reported in this openSUSE bug report:
https://bugzilla.novell.com/show_bug.cgi?id=807781

I know of the following workarounds, so try them:

- use the "native" graphics system, i.e.:

Code: Select all

kdesu systemsettings --graphicssystem native

(or set the "QT_GRAPHICSSYSTEM" environment variable to "native", in /etc/environment f.e.)

- set the QT_X11_NO_MITSHM environment variable to 1, so Qt doesn't use MITSHM:

Code: Select all

kdesu QT_X11_NO_MITSHM=1 systemsettings

(or set it globally via /etc/environment f.e.)

Hope that helps.

Thank you very much, wolfi323. Here's the result:

- use the "native" graphics system:
no change

- set the QT_X11_NO_MITSHM environment variable to 1:
Using it with kdesudo, I see a window popping up for a millisecond or so, but after that nothing.
Using it with kdesu, it works!

Now I have a workaround for the problem that the "automatic" authentication doesn't work.
One question though: Am I exposed to a security risk by setting QT_X11_NO_MITSHM=1?
Is it safer to start every application which needs it, with QT_X11_NO_MITSHM=1, rather than setting it globally in /etc/environment?

Sheriff Hobbes wrote:- set the QT_X11_NO_MITSHM environment variable to 1:
Using it with kdesudo, I see a window popping up for a millisecond or so, but after that nothing.

Well, with kdesuso the syntax may be a bit different. I never used that, as it is not part of KDE itself, but some third party app.

Maybe try:

Code: Select all

kdesudo "QT_X11_NO_MITSHM=1 systemsettings"

i.e. with quotes.

Now I have a workaround for the problem that the "automatic" authentication doesn't work.
One question though: Am I exposed to a security risk by setting QT_X11_NO_MITSHM=1?
Is it safer to start every application which needs it, with QT_X11_NO_MITSHM=1, rather than setting it globally in /etc/environment?

This has nothing to do with the authentication.

AIUI, the MIT-SHM extension uses shared memory (between X and the application) for the graphics buffer, which should make things faster, because the graphics data doesn't have to be copied around. (http://en.wikipedia.org/wiki/MIT-SHM)

Since a possible vulnerability has been fixed in Qt (see the bug report), this is not working anymore when running applications via VNC as a different user (the other user has no permission to access the graphics buffer anymore).

QT_X11_NO_MITSHM=1 tells Qt to _not_ use MIT-SHM (shared memory), so should be safer security-wise in any case.

And I'm not sure whether MIT-SHM even works or has a positive effect over VNC.

But I don't know all the details involved here myself either.

wolfi323 wrote:This has nothing to do with the authentication.

I know, but I reported 2 bugs in my initial post:
1. No automatic popup for root credential showing up when it is needed (e.g. system settings -> change time)
2. the empty window when starting the app with kdesu

Bug #1 is an authentication issue, which is still unsolved. I can workaround it with the solution for bug #2.

Sheriff Hobbes wrote:

wolfi323 wrote:This has nothing to do with the authentication.

I know, but I reported 2 bugs in my initial post:
1. No automatic popup for root credential showing up when it is needed (e.g. system settings -> change time)

Well, that doesn't use "kdesu", but KAuth, which is something completely different.

So I guess you should better open a new thread for that, as this one's title is "Kdesu does not work right in VNC session".

Btw, KAuth uses polkit for the authentication, so check that polkit-kde-authentication-agent-1 is running.
Maybe there's a problem in communicating with polkit when you run via VNC?

But probably it's just be caused by the polkit rules (org.kde.kcontrol.kcmclock.save in this particular case) that might prevent you from changing the date/time because you're not logged in locally.
AFAICS the default for this action is:

Code: Select all

  implicit any:      no
  implicit inactive: no
  implicit active:   auth_admin

which means a user logged in on an active console is asked for the root password, other users (logged in via VNC f.e?) are just prohibited completely to save the time/date.
How you would change this depends on your distribution and the version of polkit you use. You should be able to add a rule to /etc/polkit-1/, or edit /usr/share/polkit-1/actions/org.kde.kcontrol.kcmclock.policy (at least that's the path on my system), and set all three to auth_admin or even yes.