Turns out, at least on RHEL/Centos-style systems, if you run su(1) or sudo(8) after ssh'ing into a system, you can't run X11 apps from the su{do}'d user because of the way SSH handles X authentication there - it puts the Xauth cookie into the .Xauthority file instead of an environment variable. I'm seeing references that Ubuntu & Debian don't behave like this, but don't have a live system to confirm. I vaguely recall HPUX not behaving like this, and I don't care enough to test on *BSD right now.
Since I regularly need to su/sudo to another identity on a remote CentOS system, and it's a shared system, I don't want to gratuitously grant wide-open connection to my local X display; I at least want to limit the window of vulnerability... it doesn't look like I can eliminate it entirely. Here's the best work-around I could come up with. I think it manages to avoid exposing the Xauth data or anything else, but potentially requires you to enter your password more than once if sudo(8)'s cache has expired. It also allows someone else su'd into that userid *at the same time as me* to access my Xauth cookies, but that's an acceptable window of risk for me since the cookie becomes invalid after I disconnect the SSH session. Plus, I'm not the only person with root, so that vulnerability exists no matter what :).
#!/bin/sh -e U=someuserid D=${DISPLAY/*:} E="$(hostname)/unix:${D%.0}" xauth extract - "$E" | sudo -u "$U" -- xauth merge - if [ -z "$*" ]; then sudo -u "$U" -i else sudo -u "$U" -- "$@" fi sudo -u "$U" -- xauth remove "$E"
Unfortunately, ssh(1)/sshd(8) sets DISPLAY to something like localhost:NN.0, but xauth has it recorded internally as FQDN/unix:NN ... these two $DISPLAYs are equivalent, but don't parse the same way on the command-line, hence the ugly manipulation. I think this chunk of code is safe from obvious exploits (or errors), but dissenting opinions are welcome.
N.B. long-time shell users will cringe at seeing $* instead of $@, but it turns out to be correct in this case: $@ *doesn't work* there. The reason why is left as an exercise for the reader :-).