-
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

Vintage Mainframe Computer Disk Drive Pack Dyson SMD 5 Level Disks
$79.00

Vintage Intel Mainframe Server MCM CPU Substrate Lot Prototyping PGA Validation
$500.00

Vintage Telex 952003-112 Mechanical Terminal Keyboard IBM 3270 Mainframe DB25
$799.00

HP 13210-60001 Disc Drive Interface PCB HP 7900A 7901A Vintage
$166.24

Vtg IBM Mainframe Prototype Chip Module Lot 146 pc 1988-1993 ES/9000 Lab Arcive
$649.00

Commodore 64 PC with Model 1541 Diskette Drive and Flight Simulator II *READ*
$199.99

Mainframe Computer Data Punch Card Lot of 50 Orange 80 Column IBM comp Vtg NOS
$15.00

Colorado Jumbo 250 Internal Tape Backup System Complete Set Mainframe Collection
$129.99

Vintage UNIVAC 3620670-01 Mainframe Logic Board 15MHz Sperry Computer PCB
$98.95

HP 5060-8359 8K Semiconductor Memory Module 5080-9747 Vintage HP Computer
$165.58