On Sun, 2005-11-13 at 19:56 +0000, Darren Salt wrote:
I demand that Andre Bischof may or may not have written...
Stefan Lucke wrote: ...
[snip]
So vdr is running with another userid as you are logged in.
- you need to set th DISPLAY variable (export DISPLAY=:0.0)
- the user who wants to access your display needs permissions to do that For my tests, when running vdr from root I do sux which keeps authorisation to x-server contact.
I can't manage to do that. If I try to run vdr as user root, vdr-kbd complains to refuse to run with root priviledges.
ITYM "complains, refusing" (unless there's something called "refuse" to which it is complaining).
If I do "su vdr" whoami tells me to be still root - is that what you meant by "sux"? Because I don't know sux, and nothing like this is installed.
My guess is that user vdr's default shell is /bin/false.
# su - vdr -s /bin/bash
[snip]
Xlib: connection to ":0.0" refused by server Xlib: Invalid MIT-MAGIC-COOKIE-1 key xset: unable to open display ":0.0"
[snip]
I'm not used to exporting displays and don't know how to manage it for the user vdr - do you still have the patience helping me again?
Hack: as root, copy ~$USER/.Xauthority into ~vdr.
Proper method: set user vdr's shell to /bin/sh and password to something appropriate, then connect using "ssh -X vdr@localhost". You'll probably want to set things up so that vdr is automatically started on login.
To me, using ssh seems like a hack.
IMHO, more correct is either:
1. Work out how to make su preserve Xauthority. (Distribution specific?) In particular use "su" not "su -"
2. Make sure ~$USER/.Xauthority is readable by the vdr user and do export XAUTHORITY=~$USER/.Xauthority
OR
3. As user do: xauth extract /tmp/key :0 As vdr user: xauth merge /tmp/key
OR (HACK)
4. ln -s ~$USER/.Xauthority ~/vdr And make sure vdr user can read the file
Anyway, this should give you the correct idea.