Shell confusion

[Gordon Messmer]

Dave Bolt IT Solutions wrote:
> When I start a terminal as dave I get a prompt [dave at Test-Host ~]$
> When I do su amandabackup I get a prompt bash-3.2$
>> From the first prompt I can launch gedit, from the second I get an 
>> error, No 
> protocol specified, gedit:4724, Gtk-WARNING ** cannot open display.
> Since both of these users are apparently configured for bash, can anyone 
> explain what is happening?

You've got a lot of advice regarding the use of "su", but all of that is 
unrelated to the problem that you've actually got.  What you're seeing 
is an X11 security issue.

What you need to know is this: X11 is a network accessible display 
server.  When an X11 client (such as gedit) starts, it uses the 
environment variables DISPLAY and XAUTHORITY to determine how to connect 
to the X11 server.  When you "su amandabackup" your environment is 
preserved, so you should have both the DISPLAY and XAUTHORITY variables 
in your shell as the amandabackup user.  To check, you can simply "echo 
$DISPLAY" and "echo $XAUTHORITY" in the amandabackup shell.  The DISPLAY 
setting tells gedit where to connect, and has an appropriate value.  The 
XAUTHORITY setting points to a file which contains "magic cookies" that 
are used as passwords to authenticate the client to the X11 server. 
Since the amandabackup user can't read that file, it can't authenticate 
to the X11 server, and you get the error message that you posted.

So, with that in mind, there are three ways to work with X11's security 
to allow "amandabackup" to access the display server.

1: This is included only for completeness.  DON'T DO THIS.  You could 
just allow everyone read access to the magic cookie file.  "chmod +r 
$XAUTHORITY".  Once you do that, any user in the system can set their 
XAUTHORITY setting to the proper value and connect to the display 
server.  You could be somewhat more secure by making amandabackup a part 
of the "dave" group, and doing "chmod g+r $XAUTHORITY" instead, but 
that's still more or less a waste of effort.

2: Allow the "amandabackup" user access without authentication.  "xhost 
+SI:localuser:amandabackup" will instruct the X11 server to allow the 
amandabackup user access to the display without any cookies.  This is 
better than the first option, but only works for users on the same host.

3: Use ssh's X11 forwarding.  "ssh amandabackup at localhost -XC".  When 
using ssh, amandabackup will get its own cookie and display setting. 
gedit authenticates itself to the ssh server's display-forwarding 
server.  If it's successful, then ssh will act as a proxy for X11 
traffic to your display server.  "ssh" has to be run locally, since it 
uses your DISPLAY and XAUTHORITY settings to connect to the display on 
your end.  The advantage of this method is that it will work for local 
users, and can also forward X11 applications from remote hosts.