-
Senior Member
registered user
X apps in chroot
Hi,
I am wondering if anyone knows what is the best way to run X apps in a chrooted environment, The X server(run before the chroot) refuse connection of X apps from within the chroot. I know this is an authentication issue but don't know how to solve it.
thanks and regards.
-
Senior Member
registered user
Code:
#DISPLAY=ip.ad.dr.ess:0.0
#export DISPLAY
-
Senior Member
registered user
thanks, I tried localhost:0.0 but it still didn't work. Could be that I need the xhost command as well before I chroot.
-
Senior Member
registered user
I normally type startx --:1 in the chrooted environment without any modifications whatsoever. The window should display in the eighth virtual terminal (vt
. As for the authentication issue, turn off x authentication in /etc/X11/xdm/xdm-conf, and you won't have to mess with xhost or xauth.If you use kdm or gdm, they each have a config file in /etc/X11/kdm/kdm-config or /etc/X11/gdm/gdm/gdm-config, respectively. Xauth uses authentication from your current enviroment, i think, so it might have flowed thru to the chroot enviroment, but I'm not totally sure of this. I normally turn it off at both ends to prevent this sort of thing for troubleshooting purposes. When done, you might want to turn it back on, if you desire the security of your X sessions.
-
Senior Member
registered user

Originally Posted by
Durand Hicks
I normally type startx --:1 in the chrooted environment without any modifications whatsoever. The window should display in the eighth virtual terminal (vt

. As for the authentication issue, turn off x authentication in /etc/X11/xdm/xdm-conf, and you won't have to mess with xhost or xauth.If you use kdm or gdm, they each have a config file in /etc/X11/kdm/kdm-config or /etc/X11/gdm/gdm/gdm-config, respectively. Xauth uses authentication from your current enviroment, i think, so it might have flowed thru to the chroot enviroment, but I'm not totally sure of this. I normally turn it off at both ends to prevent this sort of thing for troubleshooting purposes. When done, you might want to turn it back on, if you desire the security of your X sessions.
Thanks for the info. My situation is a bit odd. I started a VNC server from the hosting rootfs and vnc into it. Then I chroot into another rootfs and tried to run X apps there. The hosting rootfs in this case don't even have a session manager(xdm etc.). What is even more complicated, I need to "su" into a normal user in this chrooted environment first before running the X apps.
This whole authentication system of X is still very confusing to me. I googled around and it seems that I can mount --bind /tmp into the chroot so as to directly use the X socket created there.
At the moment, I just bypass all this and start the vnc server within the chrooted environment, but still learning how to do it as that seems to be a pretty standard requirment of chrooting into other rootfs(under X) and run X apps, so a proper solution will help in the future.
-
Senior Member
registered user
thanks for all the help, finally get some idea of how this X security works.
By default, X clients access ~/.Xauthority to find cookies in order to talk to X server.
In order to make scenarios like "su" then run some root only programs "xhost +local:" is needed as this would allow anyone on the same machine(or access to the /tmp/.X11-unix sockets) to connect to the running display.
For a chrooted environment, /tmp in chroot is different from /tmp in hosting so the above won't work. "xhost +localhost" is needed as that means any X apps running on the local machine(not depending on the rootfs anymore) can access the X server.
The above should be good enough for a workstation used by only one person. If one wants more security, it has to resort to using the 'xauth' command to extract the cookies then import into the destination ~/.Xauthority. Though this is still not encrypted in anyway.
If one need to access X apps on another machine, just add "xhost +hostname" but that would mean any X apps from hostname can access the running X server.
hope this will help others.
-
Still a No Go
I've tried the methods suggested in this post and must be missing a step. I still get authority errors related to /home/knoppix/.Xauthority from the chrooted environment.
The xdm-config has 0 for an authentication value. Do I need to say "false" instead?
Thanks.
-
I've never actually started up X locally when remastering, I've always just started up VNC and then connected from a different computer
But I don't think that's what your trying to do here.
Similar Threads
-
By Sephiroth? in forum Customising & Remastering
Replies: 1
Last Post: 04-25-2006, 12:55 AM
-
By dvryknopper in forum General Support
Replies: 1
Last Post: 03-31-2006, 05:56 AM
-
By gursharnsingh in forum Customising & Remastering
Replies: 2
Last Post: 01-15-2004, 09:38 PM
-
By rdmelin in forum Customising & Remastering
Replies: 4
Last Post: 08-20-2003, 02:27 PM
-
By sminotti in forum Hdd Install / Debian / Apt
Replies: 2
Last Post: 08-07-2003, 07:46 PM
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules

(New) AMD Ryzen 7 5700X 8 Core 16 Thread AM4 Unlocked 3.4 GHz CPU OEM Tray
$169.99

Intel Core i9-9900K SRG19 3.60GHz 16MB 8-Core LGA1151 B Grade CPU Processor
$175.00

Apple Mac Pro 5,1 • 8‑Core 2.26GHz • 14GB RAM • 128GB SSD + 1TB HDD Dual NVIDIA
$325.00

AMD Ryzen 7 7700X 8-Core, 16-Thread Unlocked Desktop Processor
$250.00

AMD Ryzen 5 PRO 4650GE 100-000000153 6-Core 3.30GHz 8MB AM4 CPU Processor
$59.99

Intel Xeon E5 - 2667V2 / SR19W 3.30GHz 25MB 8-Core CPU Socket LGA2011
$30.00

AMD Ryzen 7 9700X 8-Core 16-Thread 40MB Cache Socket AM5 9000 Series Processor
$245.99

Intel Xeon W-2245 3.90Ghz 8 Core 16.5MB CPU Processor SRH02
$140.00

Home Assistant Server | 8GB RAM | 128GB SSD | Intel i5 Quad-Core | Dell OptiPlex
$159.99

Dell OptiPlex 5070 SFF i7-9700 (8-Core) 3.0GHz 16GB 256 SSD Windows 11
$250.00