Results 1 to 8 of 8

Thread: X apps in chroot

Hybrid View

  1. #1
    Senior Member registered user
    Join Date
    Mar 2003
    Posts
    872

    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.

  2. #2
    Senior Member registered user
    Join Date
    Mar 2004
    Posts
    900
    Code:
    #DISPLAY=ip.ad.dr.ess:0.0  
    #export DISPLAY

  3. #3
    Senior Member registered user
    Join Date
    Mar 2003
    Posts
    872
    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.

  4. #4
    Senior Member registered user
    Join Date
    Feb 2004
    Posts
    235
    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.

  5. #5
    Senior Member registered user
    Join Date
    Mar 2003
    Posts
    872
    Quote 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.

  6. #6
    Senior Member registered user
    Join Date
    Mar 2003
    Posts
    872
    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.

  7. #7
    Junior Member
    Join Date
    Nov 2004
    Posts
    1

    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.

  8. #8
    Member registered user
    Join Date
    Feb 2003
    Location
    Vancouver BC
    Posts
    92
    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

  1. chroot in source
    By Sephiroth? in forum Customising & Remastering
    Replies: 1
    Last Post: 04-25-2006, 12:55 AM
  2. C KDE APPS and C apps printing unix commands
    By dvryknopper in forum General Support
    Replies: 1
    Last Post: 03-31-2006, 05:56 AM
  3. chroot help
    By gursharnsingh in forum Customising & Remastering
    Replies: 2
    Last Post: 01-15-2004, 09:38 PM
  4. X programs from chroot
    By rdmelin in forum Customising & Remastering
    Replies: 4
    Last Post: 08-20-2003, 02:27 PM
  5. To chroot or not to chroot
    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
  •  


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

(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 picture

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 picture

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 picture

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 picture

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 picture

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 picture

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 picture

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 picture

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 picture

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

$250.00