Xpra: Ticket #1710: gksu interface not accepting input

version: Xpra gtk2 client version 2.1.3-r17247 64-bit platform: Linux 4.9.0-4-amd64 x86_64 Debian

When starting a server as follows:

xpra start --start="gksu /usr/sbin/gparted"

Attaching a client gives no error messages to STDERR or anything of interest in the log (ie. only lines that exist in a normal properly operating connection).

However, what actually happens is awful and stressful:

1] The client grabs control of the entire screen space instead of 800x600, and paints it all black

2] The lower right hand corner of the display does offer the gksu dialog, with a blinking cursor in the input field.

3] No input is echoed to the input field.

4] Input keystrokes are sent to the environment that spawned the client, ie. keystrokes that would go to the spawning terminal are sent there, and keystrokes that would be intercepted by the window manager would be intercepted there.

4.1] However, the xpra client would not release control of the entire visible display (I think in X11 terminology it's called the 'seat').

4.2] Because C-c is being sent to the spawning environment, which was the terminal that issued the xpra attach command, it closes the client and restores the X11 seat's display.

4.3] During experimentation, it was possible to regain control of the display by switching to a different virtual terminal, ie. C-M-F1.



Mon, 27 Nov 2017 03:50:53 GMT - Antoine Martin: owner changed

1] The client grabs control of the entire screen space instead of 800x600, and paints it all black

Why would it only use 800x600?

2] The lower right hand corner of the display does offer the gksu dialog, with a blinking cursor in the input field.

Can you take a screenshot? Is your vfb configured correctly? (does the current server resolution as shown with xrandr match your client's?)

My distro (Fedora) doesn't support gksu (see https://fedoraproject.org/wiki/Features/gksudo), so I can't test this right now.

In any case, to get applications like gksu to work properly, it is likely that you will need to use a dedicated seat for each xpra session. See start-via-proxy=yes and the system wide proxy server.


Tue, 28 Nov 2017 00:18:18 GMT - Boruch:

1] The client grabs control of the entire screen space instead of 800x600, and paints it all black

Why would it only use 800x600?

Probably because my window manager (i3wm) is set up to display all unexpected windows that way.

2] The lower right hand corner of the display does offer the gksu dialog, with a blinking cursor in the input field.

Can you take a screenshot?

Done.

Is your vfb configured correctly? (does the current server resolution as shown with xrandr match your client's?)

The output of xrandr matches the resolution listed in the xpra logs.

In any case, to get applications like gksu to work properly, it is likely that you will need to use a dedicated seat for each xpra session.

See start-via-proxy=yes and the system wide proxy server.

I do have gksudo (I think the interface is actually identical to gksu. They do share the same man page), just I don't have anyone configured with sudo privileges.

What I can easily try is to gksu to another unprivileged user account to, say, open an xterm as that second user. To temporarily set up sudo would be something I'm not happy about diving into, but its not impossible.


Tue, 28 Nov 2017 00:20:30 GMT - Boruch: attachment set


Wed, 13 Dec 2017 16:42:41 GMT - Boruch:

In any case, to get applications like gksu to work properly, it is likely that you will need to use a dedicated seat for each xpra session. See start-via-proxy=yes and the system wide proxy server.

If I'm looking in the correct place on the wiki, it says

Your init system should start the service on xpra's default port

But I don't see any init script in /etc/init.d, nor when I perform dpkg -L xpra | grep "/etc"


Wed, 13 Dec 2017 17:04:44 GMT - Antoine Martin:

But I don't see any init script in /etc/init.d, nor when I perform dpkg -L xpra | grep "/etc"

We ship systemd unit files, though an init script is also available in the source: browser/xpra/trunk/src/service.

I have no idea how we would ship both or how we to ensure that the package also works with non-systemd installs.


Wed, 13 Dec 2017 18:12:03 GMT - Boruch:

We ship systemd unit files, though an init script is also available in the source: browser/xpra/trunk/src/service. I have no idea how we would ship both or how we to ensure that the package also works with non-systemd installs.

Well, then, I might be the guinea pig.

1] The init script should be copied to /etc/init.d/ with 755 permissions. Steps 2 & 3 are optional, and is commonly done by the person packaging the program for a specific distribution, but see my comments later for a few minor gotchas I discovered, that would be you to address.

2] The install should run update-rc.d xpra defaults to build the symlinks to the init script from the default run-level directories.

3] If you want the install procedure to automatically start the service, then the command would be: service xpra start, but that's a debate between those who want services started upon install, and those who feel its over-reach and presumptuous.

In my case, I have followed my own instructions and have hit a snag in a config file /etc/default/xpra: Syntax error: "(" unexpected. The offending line reads: XPRA_LOG_FORMAT=%(message)s.

What is happening is that line 23 of the init script, [ -e /etc/default/xpra ] && . /etc/default/xpra is 'source'ing

/etc/default/xpra expecting it to be in a shell-script compatible format, but the idion %(...)s isn't a /bin/sh form.

What I did was put the idiom in double-quotes.

The good news is that the small change succeeded in starting the service and outputting a log to /var/log/xpra/log. Is that change systemd-compatible?

The bad news is the log's output, at this point:

 $cat /var/log/xpra.log
14500
2017-12-13 12:51:25,748 Warning: failed to create socket directory '/root/.xpra/E15-2016-/root'
2017-12-13 12:51:25,749  [Errno 2] No such file or directory: '/root/.xpra/E15-2016-/root'
2017-12-13 12:51:25,749 Error: failed to create socket '/root/.xpra/E15-2016-/root/.xpra':
2017-12-13 12:51:25,749  [Errno 2] No such file or directory
xpra initialization error:
 failed to create socket /root/.xpra/E15-2016-/root/.xpra
2017-12-13 12:51:25,750 closing tcp socket 0.0.0.0:14500
close failed in file object destructor:
IOError: [Errno 9] Bad file descriptor

I then added to line 29 of the init script: --socket-dir=/tmp, but it seems that xpra isn't creating sub-directories (maybe what's missing is something like the -p option to mkdir?):

#cat /var/log/xpra.log
14500
2017-12-13 13:00:55,470 Warning: failed to create socket directory '/tmp/E15-2016-/root'
2017-12-13 13:00:55,471  [Errno 2] No such file or directory: '/tmp/E15-2016-/root'
2017-12-13 13:00:55,471 Error: failed to create socket '/tmp/E15-2016-/root/.xpra':
2017-12-13 13:00:55,471  [Errno 2] No such file or directory
xpra initialization error:
 failed to create socket /tmp/E15-2016-/root/.xpra
2017-12-13 13:00:55,472 closing tcp socket 0.0.0.0:14500
close failed in file object destructor:
IOError: [Errno 9] Bad file descriptor

Wed, 13 Dec 2017 18:31:33 GMT - Antoine Martin:

The init script should be copied...

I think that's the easy part, ensuring that this plays nice with systems that have systemd as init system is harder, and the packaging of it all is likely to be a nightmare (from past experience with all the hidden magic in the debian-helper scripts).

What I did was put the idiom in double-quotes.

Please supply a patch or just the updated file so I don't make mistakes applying the change.

The good news is that the small change succeeded in starting the service and outputting a log to /var/log/xpra/log. Is that change systemd-compatible?

I don't understand the question. systemd doesn't use that file.

The bad news is the log's output, at this point: (..)

r17620 should help.


Wed, 13 Dec 2017 19:04:20 GMT - Boruch:

I think that's the easy part, ensuring that this plays nice with systems that have systemd as init system is harder, and the packaging of it all is likely to be a nightmare (from past experience with all the hidden magic in the debian-helper scripts).

Yeah, been there. Leave that all to the people doing the packaging for each distro.

What I did was put the idiom in double-quotes.

Please supply a patch or just the updated file so I don't make mistakes applying the change.

Here you go:

TCP_AUTH=sys
AUTH=peercred
#DEBUG=auth,proxy
DEBUG=
#skip datetime prefix since the log goes to a system logger:
XPRA_LOG_FORMAT="%(message)s"

r17620 should help.

I just now manually applied the patch, and it seems like a success ...

#cat /var/log/xpra.log
14500
2017-12-13 13:44:28,962 created unix domain socket: /run/xpra/system
2017-12-13 13:44:30,694 serving html content from: /usr/share/xpra/www
2017-12-13 13:44:30,724 xpra proxy version 2.3-r17613 64-bit
2017-12-13 13:44:30,725  uid=0 (root), gid=0 (root)
2017-12-13 13:44:30,725  running with pid 3120 on Linux Devuan 1.0 jessie
2017-12-13 13:44:30,759 xpra is ready.

but now ...

 $xpra start --start="gksu /usr/sbin/gparted" --start-via-proxy=yes
xpra initialization error:
 failed to start-via-proxy: failed to connect to '/run/xpra/system':
 [Errno 13] Permission denied

No new entries in /var/log/xpra.log and no new logs in ~/.xpra

The directory /run/xpra has 700 permissions, for some reason! I manually changed it to 755, and after a long wait ...

$xpra start --start="gksu /usr/sbin/gparted" --start-via-proxy=yes
2017-12-13 13:55:02,363 server failure: disconnected before the session could be established
2017-12-13 13:55:02,363 server requested disconnect: server error (failed to start a new session)
xpra initialization error:
 failed to start-via-proxy: FAILURE

Here`s a re-cap of the ENTIRE /var/log at this point, including a repeat of the above:

$cat /var/log/xpra.log
14500
2017-12-13 13:44:28,962 created unix domain socket: /run/xpra/system
2017-12-13 13:44:30,694 serving html content from: /usr/share/xpra/www
2017-12-13 13:44:30,724 xpra proxy version 2.3-r17613 64-bit
2017-12-13 13:44:30,725  uid=0 (root), gid=0 (root)
2017-12-13 13:44:30,725  running with pid 3120 on Linux Devuan 1.0 jessie
2017-12-13 13:44:30,759 xpra is ready.
2017-12-13 13:54:36,800 New unix-domain connection received on /run/xpra/system
2017-12-13 13:54:42,727 Error: pam_open_session failed: 6
2017-12-13 13:54:42,727  Permission denied
xpra initialization error:
 cannot open log file '${HOME}/.xpra/S6794.log': [Errno 2] No such file or directory: '${HOME}/.xpra/S6794.log'
2017-12-13 13:54:47,336 Error: displayfd failed
2017-12-13 13:54:47,338  did not provide a display number using displayfd
2017-12-13 13:55:02,358 Error: failed to start server subprocess:
2017-12-13 13:55:02,358  failed to identify the new server display!

No new log at ~/.xpra


Wed, 13 Dec 2017 19:17:11 GMT - Antoine Martin:

XPRA_LOG_FORMAT="%(message)s"

Thanks, applied in r17624.

The directory /run/xpra has 700 permissions, for some reason! I manually changed it to 755, and after a long wait ...

Normally, this directory is created with another systemd component: browser/xpra/trunk/src/tmpfiles.d/xpra.conf. This sets the correct permission. No idea how we're supposed to do that without tmpfiles.d.

Error: pam_open_session failed: 6 Permission denied

We use pam to login as that user. Maybe the pam configuration file needs tweaking for your non-systemd setup. It does work on a stock "stretch" distro, I've tried it again just yesterday.

cannot open log file '${HOME}/.xpra/S6794.log': [Errno 2] No such file or directory: '${HOME}/.xpra/S6794.log'

This could be the problem. Maybe $HOME is not being substituted or something. We normally place those log files in $XDG_RUNTIME_DIR.


Thu, 14 Dec 2017 05:35:58 GMT - Antoine Martin:

The directory /run/xpra has 700 permissions...

Try r17625.

cannot open log file '${HOME}/.xpra/S6794.log': [Errno 2] No such file or directory: '${HOME}/.xpra/S6794.log'

Try r17626.


Thu, 14 Dec 2017 19:29:11 GMT - Antoine Martin:

Just stumbled upon this: pam_ck_connector. (see CKCON_X11_DISPLAY) I believe that when we start via the proxy, pam login will take care of this. (the pam configuration files are a mess and vary widely from distro to distro)

So, it looks like ConsoleKit won't let you register without privileges? So we're back to using the system wide proxy server. (it runs as root and takes care of those things before changing uid)


Sat, 23 Dec 2017 12:59:59 GMT - Antoine Martin: status changed; resolution set


Sat, 23 Jan 2021 05:31:42 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1710