[FreeNX-kNX] CentOS 6.4 FreeNX Session - sudo Cannot open display

[Chris]

freenx-knx-bounces at kde.org wrote on 15/08/2013 23:52:49:

> Hey All,
> 
> When I am logged into a FreeNX Session on my CentOS 6.4 server, I 
> keep getting an error message when trying to run commands that load 
> applications.  For example, if I run 
> sudo nautilus
> I get this output:
> 
> No protocol specified
> Could not parse arguments: Cannot open display: 
> The display variable shows:
> 
> echo $DISPLAY
> :1000.0
[SNIP]
> RuntimeError: could not open display

Yup

I ran into this recently too.


This is because the X auth cookie for that display
is unavailable . . . .


> Pretty much any GUI application I try to call from the terminal 
> fails because it could not open the display.  

Yup
 
> Any idea what I should do?  I tried this from the CentOS FreeNX article 
(
> http://wiki.centos.org/HowTos/FreeNX):
> Solution: Edit /etc/nxserver/node.conf and change the line: 
> #AGENT_EXTRA_OPTIONS_X="-nolisten tcp" 
> to: 
> AGENT_EXTRA_OPTIONS_X="" 
> I really need to be able to launch these GUI applications from a 
> FreeNX session.  My separate Ubuntu server has no problems accessing

Yup  yup . . . " read on Macduff "


> the display in FreeNX sessions.  All help is appreciated.


gmd kdm xdm etc don't bother setting  the
         XAUTHORITY
 env var to the default as the default
 ( ~/.Xauthority ) generally works in 
"normal circumstances".



The difference between su and sudo is :-

su
---

. . a copy of the current cookie file is created
        ( i.e. from the default file in this circumstance)
in
the target users's home directory
e.g.
         /root/.xautheObDvM
and
su sets 
        XAUTHORITY
 for the su session to point to THAT file.
i.e.
      XAUTHORITY=/root/.xautheObDvM
It all now works ( for su).



sudo
-----

No copy of the .Xauthority file is created.

sudo is designed to escalate authority for the current user
so
it originally kept most of the sudoer's environment.

This is seen a potential security risk, particularly
keeping the sudoer's $HOME directory when running
as root maybe with $HOME/bin in the root exe path

so
mostly distros will now by default change the
home directory to the target account's
eg.
         /root

using, in /etc/sudoers

        Defaults    always_set_home

but "keep" the 
        $XAUTHORITY
envvar

i.e.
in /etc/sudoers

        Defaults env_keep += " . . XAUTHORITY . ." 



This WOULD work fine
IF
         XAUTHORITY
was
actually set and populated,
but
nowadays it isn't

so
You have a choice of TWO options

either

1/ "keep" the sudoer's HOME envar
fot the root session by commenting  out as below

#       Defaults    always_set_home

and
ensure that
         HOME
is in one of the
         Defaults    env_keep += " . .HOME . ."
lines in /etc/sudoers


OR

2/ populate and "keep" $XAUTHORITY with
the sudoers .Xauthority file
        ( see a "fix" below)


ELSE

You will find that you are using 
        /root/.Xauthority
which
doesn't have the corect MIT cookie for the
         current $DISPLAY
and so
throws out error messages :-

        No protocol specified
        . . .  error: Can't open display: . . . 


If you DON'T want to keep the sudo-ing users
         $HOME  directory
but prefer to stay "safe" from that point of view


A fix is :-

to propulate bash's XAUTHORITY at login 
using

         /etc/profile.d/custom.sh


*** IF  ***

 XAUTHORITY isn't set ALREADY,
else
it changes the sudo "kept"

        XAUTHORITY

to contain the the path to the target user's

         .Xauthority

when you run

         sudo target_user





Add the line

[ -z "$XAUTHORITY" ] && export XAUTHORITY=~/.Xauthority

to
         /etc/profile.d/custom.sh



I think RHEL's sudoers has this as a default for ALL target accounts
which
begs the question as to why Redhat "keep" an envar they
don't set.



My advice (FWIW) is to choose sudo over su for the various
usual reasons 
eg.
logs each run
using the sudo-ers password, not the target account (root) password
runs single commands not a root shell 
        (unless you run sudo /bin/bash or sudo -i)
etc


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/freenx-knx/attachments/20130816/4b726780/attachment.html>