> I was wondering, whether the clipboard-problem is caused
> by some (possible wrong) settings of my system or a
> normal behaviour of X/mrxvt and whether there are tricks
> to make the clibboard working "inter-user-al" :) ... it
> is so cool to use "*p !!!
The following information is 100% untested, but my
understanding is that the X server has to be authorized (via
the "MIT Magic Cookie") to accept connections from clients.
Quoting directly from Loren M. Lang's post (found at
http://groups.google.com/group/mailing.freebsd.questions/browse_thread/thread/dc2159c366eb9064/e9001ce2abaec9d3?lnk=st&q=run+x+application+as+different+user&rnum=4#e9001ce2abaec9d3
sorry for the long link)
----------------[begin quote]------------------------------
> 3)what must i put in the .Xauthority file to make the
> screensaver work with having to use xhost ?
When X first logs in to a user, it creates the .Xauthority
file in that users home directory and fills it with a random
string called a MIT-MAGIC-COOKIE. Any X client, by default,
reads that file to see what the cookie is then sends it to
the X server to authenticate itself. Anyone who can read
that file can access the display so that file is normally
only readable by the user who logged in, though root can
always read it because root is god. When you run an X
program as a different user, it will look in that users home
directory for the .Xauthority file and so won't be able to
find the right cookie unless you used the xauth command to
give that user the cookie ahead of time. By setting the
XAUTHORITY environment variable to some other file, it will
check that file for the magic cookie instead of the current
users home directory. This is useful when running a command
as root that you want to access a normal users X server.
This is a much more secure way to allow access to X than
using xhost since you know what users are able to access X,
not just which computers, which may have multiple users on
them.
In summary, don't touch xhost, just use:
XAUTHORITY=/home/user/.Xauthority xscreensaver
or you can use xauth to extract the magic cookie and then
import it into the correct users .Xauthority file. As the
user of the X server:
xauth extract my-cookie-file $DISPLAY
Saves the magic cookie to a file called my-cookie-file for
the current display. Then as the user who want to access
the X display:
xauth merge my-cookie-file
Adds the cookie stored in my-cookie file to the current
users .Xauthority file. Now user B can open an X
application on A's X server.
Oh, and don't run xscreensaver as root EVER! Instead, if
you're really paranoid about security, make a user who can
access any of your files whose sole purpose is to run
xscreensaver then use that user to run it. This is still
not that much more secure since any user that can access an
X server can essentially take it over and control your mouse
and keyboard doing what ever they want, like openning an
xterm on your display and running the passwd command to
change your passwd. Now they just gained access to all your
files as well.
----------------[end quote]------------------------------
My guess is that, as root, you want to try something like
XAUTHORITY=/home/user/.Xauthority gvim file1.txt
The old-school way of doing this was to tinker with xhost to
allow a whole host (rather than a particular user) to connect to
the X server.
The aim is to allow your alternate user (root in this case)
permission to connect to the X server so that it can access the
clipboard(s). My understanding is that the keys found in the
.Xauthority file are the way to do this...that the alternate user
has to have the key.
Or I could be talking bunk. YMMV :)
-tim
