Applications in shells can't find display when running under NX

English Network/Internet
1

Any X experts know why my display doesn’t seem to be available in su shells when using NX? This problem does not happen using tightVNC (but it has its own problems).

**Symptom: **When running on NX (either NX Free or FreeNX), starting YaST from the application menu brings up a window that is entirely gray.

(Another thing that happens under NX but not tightVNC: In Chrome, much of the system text – bookmark names, system menu items, tab titles, etc. – is missing, but web page display is fine. Don’t know if it’s related.)

**Testing: **As I worked through the problem, I discovered that the issue is applications running in shells. The menu item for YaST uses a login program to bring up YaST in a shell with user root, similar to sudo. For testing, I tried

/sbin/yast2

in a terminal under my name, and the window came up properly (although most of the functionality was missing because it was not running as root). Then I tried

sudo /sbin/yast2

and YaST came up on the terminal in character mode (presumably it does this when it doesn’t find a display). If I try

su
<password>
/sbin/yast2

the window appears without any contents (all gray) and the terminal shows errors:

X Error: BadAccess (attempt to access private resource denied) 10
Extension: 129 (MIT-SHM)
Minor opcode: 1 (X_ShmAttach)
Resource id: 0x57
X Error: BadShmSeg (invalid shared segment parameter) 128
Extension: 129 (MIT-SHM)
Minor opcode: 5 (X_ShmCreatePixmap)
Resource id: 0x1a00010
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
Major opcode: 62 (X_CopyArea)
Resource id: 0x1a00011
… lots more BadDrawable …
X Error: BadPixmap (invalid Pixmap parameter) 4
Major opcode: 54 (X_FreePixmap)
Resource id: 0x1a00011
X Error: BadShmSeg (invalid shared segment parameter) 128
Extension: 129 (MIT-SHM)
Minor opcode: 2 (X_ShmDetach)
Resource id: 0x1a00010

It isn’t related to root; if I su to a different user, the same thing happens.

Behavior is similar with xclock.

sudo xclock
Error: Can’t open display:

The variable DISPLAY seems to be available when using su, but not sudo:

cat >dtest
echo $DISPLAY
^D
chmod +x dtest
./dtest
:1003
sudo ./dtest
<nothing>
su
./dtest
:1003

Can anyone make sense of this, or tell me what to try?

Details:

Server: Linux OpenSUSE 12.2, with NX Free 3.5.0-11 server, running on Dell custom rack server
Client: Windows 7, with NX Free 3.5.0-9 client, running on Sony VAIO Z

2

Hello,

Please use (at least in your next posts) CODE tags around your copied/pasted treminal texts. Use the # button in the toolbar of the post editor.

3

On 04/02/2013 09:16 PM, DKabcenell wrote:
> Can anyone make sense of this, or tell me what to try?

what happens if you use?


sudo -E xclock

if it works, the how to make it so it works without the -E switch is
on this page: http://en.opensuse.org/SDB:Login_as_root

if that does not work, there is another way…but, i don’t remember
it this second. :frowning:

hmmmm, maybe


su -c xclock

and another, somewhere…lost in space.

–
dd
http://tinyurl.com/DD-Caveat

4

Sorry, Henk, I wasn’t aware of that capability and will do it next time. And I’ll fix the original post… if I can figure out how to edit my posts, can’t find the button for that (or for forum help).

DenverD, thanks for the suggestion. The behavior did change with the -E flag, but only slightly. The original behavior was

sudo xclock
Error: Can't open display:

With the flag, it is:

sudo -E xclock
No protocol specified
Error: Can't open display:  :1003

So it does get the DISPLAY value, but I read somewhere that “No protocol specified” often indicates an access control problem.

This does seem like progress, though. It’s still kind of unexplained why it isn’t a problem in tightVNC.

For su, maybe the flag you’re remembering is -m, which is analogous to -E for sudo. It doesn’t seem to have any effect on the problem. Incidentally, xclock **does **work in a shell created by su, though it doesn’t under sudo.

Since the above test doesn’t work, I expected that the instructions in the link you referenced wouldn’t solve the problem either, and they didn’t; they effectively made -E the default.

I did some testing using tightVNC to see how things are different. They are, but have their own quirks.

  • DISPLAY contains a host name, not just a display number: “barracuda.araxia.com:1” vs “:1003”.
  • xclock still doesn’t work under sudo or sudo -E.

I’m now wondering whether sudo and su have anything to do with this at all. The behavior under these seems pretty much the same between NX and tightVNC. The behavior of running xclock directly, under sudo, and under /usr/bin/xdg-su is the same in the two environments, except that under NX there are the messages

Warning: Missing charsets in String to FontSet conversion
Warning: Unable to load any usable fontset

So it’s back to YaST, where the real problem is appearing.

Mystified…

Derry

5

On 04/02/2013 11:56 PM, DKabcenell wrote:
> I’m now wondering whether sudo and su have anything to do with this at
> all.

maybe not…try to make sure you have the following line in the
file /etc/sysconfig/displaymanager


DISPLAYMANAGER_ROOT_LOGIN_LOCAL="yes"

found in and/or remembered from http://tinyurl.com/6bo2cqg

NOTE: this may not work with the new systemd (which i admit i know
mostly nothing about…‘they’ also fiddled with other stuff…so
READ my sig caveat before proceeding)

–
dd
http://tinyurl.com/DD-Caveat

6

Thanks for the suggestion.

I verified that this line is present. I also changed AllowRootLogin from false to true in the kdmrc file as suggested in the link you mentioned in your post. Then I restarted the session and retested. Neither parameter had any effect on the problem. I have a feeling those have to do with whether root can go through the graphical login process in a new session.

Derry

7

On 2013-04-02 21:16, DKabcenell wrote:
> If I try
>
> su
> <password>
> /sbin/yast2
>
> the window appears without any contents (all gray) and the terminal
> shows errors:

You should use “su -”, with the dash.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

8

Thanks, Carlos.

The hyphen didn’t solve the problem – YaST still shows a completely gray window.

It’s so odd – except for this and one other problem (Chrome not displaying non-webpage text properly) NX Free is working perfectly, and performing well. So near and yet so far…

I have a new and important clue! It isn’t just having a subshell that has a problem – it must be a subshell for a different user. If I su to myself, it works correctly. So this is a permissions issue, not a display-not-forwarded issue. The error messages (BadShmSeg, BadAccess and so on) seem consistent with this idea.

One difference between NX and tightVNC is that NX uses ssh for its transport. Could that be related? I don’t understand the security system well enough to know.

Derry

9

The CODE tags are a rather hidden feature, thus we have to explain them to every new member here. You are no exception;).
Please copy/past from a terminal including the prompt, the command, the output and the next prompt. It will give often needed information without you telling to much and at least will give the impression that you post this a s a neutral observer and did not mess around with it.

And no, you can not change your old posts (it could make discussions imprehensible). And that would also be of no use because you have to copy/paste from the terminal in between the CODE tags. Doing it from an already messed up HTML page will not restore what is lost: the layout as created by the original computer commands using TABs and SPACEs.
(Well, it would make it a bit better by using fixed font and showing a clear boundary between story telling and computer facts).

About your problem. I did not go into that because I have no experience in using NX. But in general the problems of a program trying to let an X server to open a window for it are:

  1. The program must tell that X server on which display it wants the window to be opened (remember that an X server can manage several displays with several surfaces). This is done by setting the process environment variable DISPLAY. On the system itself (e.g. local on a PC) this mostly comes down to the value :0. (Meaning surface 0 on the local host)). And of course you should check the value of DISPLAY
echo $DISPLAY

You show something like that, but that being without the CODE tags is a bit bewildering.

  1. There is a security issue. The user that is owner of that display must grant access to it. Else everybody on the whole internet (forgetting firewalls) will be able to open windows at will on your display. You could try to open it for everybody (in general there will not be that many that try to open a window on your display :wink: to see if that helps:
xhost +/code}
But of course this is to be executed by the owner of the display in the session on that display. Not by the one who seeks allowance.

And again as a general remark that is allready posted above: do not use

su


but

su -l


for security reasons. And yes, you will loose then the value of your DISPLAY variable (if there was one) lik sudo dows. But loosing it, when it maybe wroing is not that important. It should be set correct (but then we come in the area of NX I assume and I have no knowledge there).
10

Thank you, Henk.

I thought the xhost idea was promising, but I tried

xhost +

and

xhost +si:localuser:root

without success. It’s definitely an access control issue, since

su derry

and

su -l derry

allow the display to be used, but

su

and

su -l

do not. If granting access to the display via xhost doesn’t work, what would? Is there some other kind of authentication that X might be doing, particularly when the original login is via an ssh connection?

Regarding your security suggestion for su: Actually I never use su, only sudo; this is only for testing. The real failure case I care about is invocation of YaST from a KDE icon, which uses xdg-su to run YaST as root.

Derry

11

I can not realy understand fully what you describe above. When you change to user derry, what user was doing the change. In other words which user changed to derry?

And when xhost + does not work, there is no reason to try a more restrictive form IMHO.

12

On 04/03/2013 06:06 PM, DKabcenell wrote:
> Actually I never use su, only sudo

neither of those result in having both root powers and root environment.

both result in root powers in the user environment.
which may give unintended/unexpected results.

–
dd
openSUSE®, the “German Engineered Automobile” of operating systems!

13

Sorry for not being clear. I am logged in as derry. If I use

su derry

creating a new shell under the same name, no problem opening YaST. If I use just

su

then it doesn’t work. It’s significant (to me, anyway) because originally I thought that running under the new shell was the problem, but it’s actually running as a different user that’s the problem.

And when xhost + does not work, there is no reason to try a more restrictive form IMHO.

I know, I was experimenting to understand the user syntax.

Thanks!

Derry

14

I repeat, I do not know the details of what you are using, but I tried to explain how the mechanism of opening windows on a display (probably owned by another user, which is for sure true if it is on another system) works.

And yes, when you are another user (being it root or noet is of no significamnce here) you may be blocked.

15

For anyone interested, I have a partial explanation of my problem, and a workaround.

The workaround first: I have discovered that if DISPLAY is something other than :0 but does not contain a hostname, programs running in the session as different users (such as under su or xdg-su) receive permission errors when trying to attach to the display. And as it turns out, for unknown reasons, when running under TightVNC the DISPLAY does include a host name, while in NX Free it doesn’t. I added to .profile a statement that prepends the hostname to DISPLAY if (a) it is not already present and (b) the host is not :0. Now everything works correctly. I will probably move this statement to /etc/profile.local.

I don’t have a good explanation why the permission problems occur, but I think that the correct authorization records are not being copied from my .Xauthority file to the temporary authority file set up in the new user. The copied authorization records are findable when the hostname is present in DISPLAY, but not when it isn’t.

I also don’t understand why :0 is different. Not only does it work fine without a hostname, but it *doesn’t *work when a hostname is present – it fails somewhere during the login process. Possibly there is a log someplace that would tell me why.

Now that I have a workaround that addresses the whole problem, I don’t have very much motivation to delve further, but if further debugging would help someone else let me know and I will be glad to do what I can. For those interested, the addition to .profile is

if  $DISPLAY == :* ]] &&  $DISPLAY != :0 ]]; then
  export DISPLAY=$HOST$DISPLAY; fi

It’s my very first bash script, so be nice!

Thank you all for the great suggestions; they helped me move in the right direction.

Derry

16

What you show there is not a script, but it is a statmeent. A very nice one! And if it helps you, that is fine.

A script is a file starting with a “shebang” like

#!/bin/bash

followed by one or more statements in the language identified by that shebang. That file should be made executable (for at least somebody like the owner). As such the file can be offered to the kernel which will then start a process with the binary named in the shebang to execute the statements in the file.

17

On 2013-04-14 12:36, hcvv wrote:
> What you show there is not a script, but it is a statmeent. A very nice
> one! And if it helps you, that is fine.

My understanding is that he added that line to the end of the default
“~/.profile” file. I’m dubious if doing this is the correct thing to do.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

18

I am not discussing where he put/typed this. Only he says he wrote a script. And I try to explain to him that a simple or complex statement is not he same as a script.

19

On 04/14/2013 05:36 AM, hcvv wrote:
>
> What you show there is not a script, but it is a statmeent. A very nice
> one! And if it helps you, that is fine.
>
> A script is a file starting with a “shebang” like
>
> Code:
> --------------------
> #!/bin/bash
> --------------------

:slight_smile: and just so that we are all educated. A script does not have to begin
with “shebang”.


:
echo "no shebang here"

Save that snippet to a file and execute it.

And regardless… the calling of a text file with shell commands using the syntax


sh myscript.sh

is considered to be a “shell script” (I can quote reference if you like).

In the ancient of days, before “shebang”, to make things more distinct, a shell
script beginning with a colon ‘:’ was a bourne shell script and a shell script
beginning with a hash ‘#’ was a csh script. While that feature is lost under
bash today, that feature still works with csh/tcsh today. Feel free to test with
the following examples (save to files testit.sh and testit.csh respectively):


:
echo "bourne shell"
setenv

Now, setenv is a csh thing… so you’ll get an error, even if executed from a
csh. Csh honors the ancient of days thing… in fact, maybe it was the only
one. csh was quite popular back in those days (even though “ventures into the
esoteric periphery of csh may yield unexpected results”).


#
echo "csh"
setenv

That program works under csh, because it gets executed under csh.

Any other ancients feel free to correct if I’m not remembering the days before
“shebang” correctly…

See also History section of http://en.wikipedia.org/wiki/Shebang_(Unix)

20

Yes, I think you’re right, Carlos. I was planning to move it to /etc/profile.local so all users get it. Do you think that’s the right place? Or is there another reason for not putting it in .profile? It should run once at login, I think, though it doesn’t hurt to run it again. And for a non-X session it won’t do anything because there’s no colon in DISPLAY.

Derry