On Fri, Jan 02, 2004 at 05:10:57PM +0100, Alexander Gottwald wrote:
On Fri, 2 Jan 2004, Chris Green wrote:
But if I run xhost in that session I will be setting xhost permissions on the Linux Slackware system which is most definitely not what is required.
No. It sets the permissions of the __xserver__ to which the session belongs.
Try it!
linux$ echo $DISPLAY
win2k.local.net:0.0
linux$ xhost 127.0.0.1
127.0.0.1 being added to access control list
linux$ xhost access control enabled, only authorized clients can connect
INET:localhost
linux$ DISPLAY=127.0.0.1:0.0 xhost
xhost: unable to open display "127.0.0.1:0.0"
win2k$ DISPLAY=127.0.0.1:0 xhost access control enabled, only authorized clients can connect INET:win2k
It seems very odd that xhost requires access to the local display in order to work as you need xhost to set permission to acces the local display - sort of catch 22.
Same with the gates of a castle. To get in, you must open it from inside.
This is the main principle of security. You can not allow those who have
no access to change the permissions.
... but I am "within the castle", I'm sitting running a script on the win2k system and I can't see how to run xwinclip there because it won't give me permission to display on the terminal that I'm already using.
Argue if you want, it won't change the way that the X security model was designed and works.
It's of little use to be able to allow xwinclip to run on the win2k system by executing something on the Linux system. One wants a means to do it from the X startup script.
Sure, one wants to, but there is not a way to do it. Patches are welcome.
Harold
