<br><tt><font size=2>freenx-knx-bounces@kde.org wrote on 15/08/2013 23:52:49:<br>
<br>
> Hey All,<br>
> <br>
> When I am logged into a FreeNX Session on my CentOS 6.4 server, I
<br>
> keep getting an error message when trying to run commands that load
<br>
> applications.  For example, if I run <br>
> sudo nautilus<br>
> I get this output:<br>
> <br>
> No protocol specified<br>
> Could not parse arguments: Cannot open display: <br>
> The display variable shows:</font></tt>
<br><tt><font size=2>> <br>
> echo $DISPLAY<br>
> :1000.0<br>
[SNIP]</font></tt>
<br><tt><font size=2>> RuntimeError: could not open display<br>
</font></tt>
<br><tt><font size=2>Yup</font></tt>
<br>
<br><tt><font size=2>I ran into this recently too.</font></tt>
<br>
<br>
<br><tt><font size=2>This is because the X auth cookie for that display</font></tt>
<br><tt><font size=2>is unavailable . . . .</font></tt>
<br>
<br>
<br><tt><font size=2>> Pretty much any GUI application I try to call
from the terminal <br>
> fails because it could not open the display.  <br>
</font></tt>
<br><tt><font size=2>Yup</font></tt>
<br><tt><font size=2> <br>
> Any idea what I should do?  I tried this from the CentOS FreeNX
article (<br>
> </font></tt><a href=http://wiki.centos.org/HowTos/FreeNX><tt><font size=2>http://wiki.centos.org/HowTos/FreeNX</font></tt></a><tt><font size=2>):</font></tt>
<br><tt><font size=2>> Solution: Edit /etc/nxserver/node.conf and change
the line: </font></tt>
<br><tt><font size=2>> #AGENT_EXTRA_OPTIONS_X="-nolisten tcp"
</font></tt>
<br><tt><font size=2>> to: </font></tt>
<br><tt><font size=2>> AGENT_EXTRA_OPTIONS_X="" </font></tt>
<br><tt><font size=2>> I really need to be able to launch these GUI
applications from a <br>
> FreeNX session.  My separate Ubuntu server has no problems accessing</font></tt>
<br>
<br><tt><font size=2>Yup  yup . . . " read on Macduff "</font></tt>
<br>
<br><tt><font size=2><br>
> the display in FreeNX sessions.  All help is appreciated.<br>
</font></tt>
<br>
<br><tt><font size=2>gmd kdm xdm etc don't bother setting  the</font></tt>
<br><tt><font size=2>         XAUTHORITY</font></tt>
<br><tt><font size=2> env var to the default as the default</font></tt>
<br><tt><font size=2> ( ~/.Xauthority ) generally works in </font></tt>
<br><tt><font size=2>"normal circumstances".</font></tt>
<br>
<br>
<br>
<br><tt><font size=2>The difference between su and sudo is :-</font></tt>
<br>
<br><tt><font size=2>su</font></tt>
<br><tt><font size=2>---</font></tt>
<br>
<br><tt><font size=2>. . a copy of the current cookie file is created</font></tt>
<br><tt><font size=2>        ( i.e. from the
default file in this circumstance)</font></tt>
<br><tt><font size=2>in</font></tt>
<br><tt><font size=2>the target users's home directory</font></tt>
<br><tt><font size=2>e.g.</font></tt>
<br><tt><font size=2>         /root/.xautheObDvM</font></tt>
<br><tt><font size=2>and</font></tt>
<br><tt><font size=2>su sets </font></tt>
<br><tt><font size=2>        XAUTHORITY</font></tt>
<br><tt><font size=2> for the su session to point to THAT file.</font></tt>
<br><tt><font size=2>i.e.</font></tt>
<br><tt><font size=2>      XAUTHORITY=/root/.xautheObDvM</font></tt>
<br><tt><font size=2>It all now works ( for su).</font></tt>
<br>
<br>
<br>
<br><tt><font size=2>sudo</font></tt>
<br><tt><font size=2>-----</font></tt>
<br>
<br><tt><font size=2>No copy of the .Xauthority file is created.</font></tt>
<br>
<br><tt><font size=2>sudo is designed to escalate authority for the current
user</font></tt>
<br><tt><font size=2>so</font></tt>
<br><tt><font size=2>it originally kept most of the sudoer's environment.</font></tt>
<br>
<br><tt><font size=2>This is seen a potential security risk, particularly</font></tt>
<br><tt><font size=2>keeping the sudoer's $HOME directory when running</font></tt>
<br><tt><font size=2>as root maybe with $HOME/bin in the root exe path</font></tt>
<br>
<br><tt><font size=2>so</font></tt>
<br><tt><font size=2>mostly distros will now by default change the</font></tt>
<br><tt><font size=2>home directory to the target account's</font></tt>
<br><tt><font size=2>eg.</font></tt>
<br><tt><font size=2>         /root</font></tt>
<br>
<br><tt><font size=2>using, in /etc/sudoers</font></tt>
<br>
<br><tt><font size=2>        Defaults  
 always_set_home</font></tt>
<br>
<br><tt><font size=2>but "keep" the </font></tt>
<br><tt><font size=2>        $XAUTHORITY</font></tt>
<br><tt><font size=2>envvar</font></tt>
<br>
<br><tt><font size=2>i.e.</font></tt>
<br><tt><font size=2>in /etc/sudoers</font></tt>
<br>
<br><tt><font size=2>        Defaults env_keep
+= " . . XAUTHORITY . ." </font></tt>
<br>
<br>
<br>
<br><tt><font size=2>This WOULD work fine</font></tt>
<br><tt><font size=2>IF</font></tt>
<br><tt><font size=2>         XAUTHORITY</font></tt>
<br><tt><font size=2>was</font></tt>
<br><tt><font size=2>actually set and populated,</font></tt>
<br><tt><font size=2>but</font></tt>
<br><tt><font size=2>nowadays it isn't</font></tt>
<br>
<br><tt><font size=2>so</font></tt>
<br><tt><font size=2>You have a choice of TWO options</font></tt>
<br>
<br><tt><font size=2>either</font></tt>
<br>
<br><tt><font size=2>1/ "keep" the sudoer's HOME envar</font></tt>
<br><tt><font size=2>fot the root session by commenting  out as below</font></tt>
<br>
<br><tt><font size=2>#        Defaults  
 always_set_home</font></tt>
<br>
<br><tt><font size=2>and</font></tt>
<br><tt><font size=2>ensure that</font></tt>
<br><tt><font size=2>         HOME</font></tt>
<br><tt><font size=2>is in one of the</font></tt>
<br><tt><font size=2>         Defaults
   env_keep += " . .HOME . ."</font></tt>
<br><tt><font size=2>lines in /etc/sudoers</font></tt>
<br>
<br>
<br><tt><font size=2>OR</font></tt>
<br>
<br><tt><font size=2>2/ populate and "keep" $XAUTHORITY with</font></tt>
<br><tt><font size=2>the sudoers .Xauthority file</font></tt>
<br><tt><font size=2>        ( see a "fix"
below)</font></tt>
<br>
<br>
<br><tt><font size=2>ELSE</font></tt>
<br>
<br><tt><font size=2>You will find that you are using </font></tt>
<br><tt><font size=2>        /root/.Xauthority</font></tt>
<br><tt><font size=2>which</font></tt>
<br><tt><font size=2>doesn't have the corect MIT cookie for the</font></tt>
<br><tt><font size=2>         current
$DISPLAY</font></tt>
<br><tt><font size=2>and so</font></tt>
<br><tt><font size=2>throws out error messages :-</font></tt>
<br>
<br><tt><font size=2>        No protocol specified</font></tt>
<br><tt><font size=2>        . . .  error:
Can't open display: . . . </font></tt>
<br>
<br>
<br><tt><font size=2>If you DON'T want to keep the sudo-ing users</font></tt>
<br><tt><font size=2>         $HOME  directory</font></tt>
<br><tt><font size=2>but prefer to stay "safe" from that point
of view</font></tt>
<br>
<br>
<br><tt><font size=2>A fix is :-</font></tt>
<br>
<br><tt><font size=2>to propulate bash's XAUTHORITY at login </font></tt>
<br><tt><font size=2>using</font></tt>
<br>
<br><tt><font size=2>         /etc/profile.d/custom.sh</font></tt>
<br>
<br>
<br><tt><font size=2>*** IF  ***</font></tt>
<br>
<br><tt><font size=2> XAUTHORITY isn't set ALREADY,</font></tt>
<br><tt><font size=2>else</font></tt>
<br><tt><font size=2>it changes the sudo "kept"</font></tt>
<br>
<br><tt><font size=2>        XAUTHORITY</font></tt>
<br>
<br><tt><font size=2>to contain the the path to the target user's</font></tt>
<br>
<br><tt><font size=2>         .Xauthority</font></tt>
<br>
<br><tt><font size=2>when you run</font></tt>
<br>
<br><tt><font size=2>         sudo target_user</font></tt>
<br>
<br>
<br>
<br>
<br>
<br><tt><font size=2>Add the line</font></tt>
<br>
<br><tt><font size=2>[ -z "$XAUTHORITY" ] && export XAUTHORITY=~/.Xauthority</font></tt>
<br>
<br><tt><font size=2>to</font></tt>
<br><tt><font size=2>         /etc/profile.d/custom.sh</font></tt>
<br>
<br>
<br>
<br><tt><font size=2>I think RHEL's sudoers has this as a default for ALL
target accounts</font></tt>
<br><tt><font size=2>which</font></tt>
<br><tt><font size=2>begs the question as to why Redhat "keep"
an envar they</font></tt>
<br><tt><font size=2>don't set.</font></tt>
<br>
<br>
<br>
<br><tt><font size=2>My advice (FWIW) is to choose sudo over su for the
various</font></tt>
<br><tt><font size=2>usual reasons </font></tt>
<br><tt><font size=2>eg.</font></tt>
<br><tt><font size=2>logs each run</font></tt>
<br><tt><font size=2>using the sudo-ers password, not the target account
(root) password</font></tt>
<br><tt><font size=2>runs single commands not a root shell </font></tt>
<br><tt><font size=2>        (unless you run
sudo /bin/bash or sudo -i)</font></tt>
<br><tt><font size=2>etc</font></tt>
<br>
<br>
<br>