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.
> >> 1. you need to set th DISPLAY variable (export DISPLAY=:0.0)
> >> 2. 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.
