When you need to run graphical applications as a different user while maintaining security boundaries between accounts, X11's default behavior poses a challenge. The standard X server authentication (via .Xauthority) grants full access to all X resources once authenticated.

We'll implement a secure approach with these components:

1. Original X session (user1)
2. Secondary user account (user2)
3. XAuth for controlled access
4. Sudo privilege elevation

1. Prepare the Environment

First, verify your display number (typically :0):

echo $DISPLAY
:0

Generate a new MIT-MAGIC-COOKIE for user2:

mcookie | tee ~user2/.Xauth-temp

2. Configure XAuth

As user1, create restricted access:

xauth generate :0 . trusted timeout 3600
xauth list

Now grant user2 access to just their application:

sudo -u user2 xauth add $(xauth list | grep "$(hostname)/unix:0" | tail -n 1)

3. Create the Execution Wrapper

Create /usr/local/bin/run-as-user2:

#!/bin/bash
export XAUTHORITY=/home/user2/.Xauthority
export DISPLAY=:0
sudo -u user2 -i "$@"

Make it executable:

sudo chmod +x /usr/local/bin/run-as-user2

Running Single Applications

Launch Firefox as user2:

run-as-user2 firefox

Creating a Restricted Desktop

For a complete isolated session:

run-as-user2 xfce4-session

• The MIT cookie has limited lifetime (1 hour in our example)
• User2 cannot access user1's X resources beyond what's explicitly granted
• Consider combining with SELinux/AppArmor for additional protection

If you get "No protocol specified" errors:

# Verify permissions
ls -la ~user2/.Xauthority

# Check valid entries
sudo -u user2 xauth list

For more complex isolation requirements, consider Xpra:

sudo apt install xpra
xpra start :100 --socket-dir=/tmp/user2-xpra
DISPLAY=:100 sudo -u user2 your-application

---

When you need to run graphical applications under different Linux user accounts while maintaining security boundaries, traditional methods like direct sudo or su don't properly handle X11 authentication. Here's how to properly isolate X11 sessions between users.

The X Window System uses MIT-MAGIC-COOKIE-1 authentication by default. When user1 starts an X session, it generates a cookie in ~/.Xauthority. To allow user2 to access the same display:

# As user1:
xauth list $DISPLAY
# Example output:
# hostname/unix:0  MIT-MAGIC-COOKIE-1  a1b2c3d4e5f6

1. Prepare the Environment

First ensure both users have proper permissions:

sudo usermod -aG sudo user2  # Or appropriate group

2. Transfer the Xauth Cookie

Create a temporary transfer file with restricted permissions:

xauth extract - $DISPLAY > /tmp/xauth_token
chmod 600 /tmp/xauth_token
sudo chown user2 /tmp/xauth_token

3. Execute as Target User

Use this sudo command structure:

sudo -u user2 bash -c 'xauth merge /tmp/xauth_token && \
DISPLAY=:0 your_application'

Here's a script that encapsulates the process:

#!/bin/bash
# Run as user1

TEMP_XAUTH="/tmp/xauth_$RANDOM"
APP="firefox"  # Example application

# Extract current user's X auth
xauth extract - "$DISPLAY" > "$TEMP_XAUTH"
chmod 600 "$TEMP_XAUTH"

# Execute as user2
sudo -u user2 bash <<EOF
xauth merge "$TEMP_XAUTH"
export DISPLAY="$DISPLAY"
$APP &
EOF

# Cleanup
rm -f "$TEMP_XAUTH"

• Always set restrictive permissions (600) on Xauth files
• Prefer temporary files over permanent storage
• Consider using XAUTHORITY environment variable to point to custom locations
• Remove temporary files immediately after use

For less secure but simpler scenarios:

xhost +SI:localuser:user2
sudo -u user2 DISPLAY=:0 your_application
xhost -SI:localuser:user2

Note: This method is less secure as it allows complete display access.

Error: No protocol specified - Usually means incorrect Xauth setup. Verify with:

sudo -u user2 xauth list

Error: Can't open display - Ensure DISPLAY is properly set and forwarded.