sudo X apps fails on NFS mounted homes

Bug #157748 reported by Joerg Delker
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
sudo (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: sudo

With upgrade to gutsy, sudo and kdesu stopped working.

user@localhost ~> sudo xterm
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

Warning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm Xt error: Can't open display: %s

Note: The user's home is mounted via NFS (via default root_squash option). Moving it to a local directory makes the above work.
Some analysis with strace (see trace below) showed that sudo tries to access the user's ~/.Xauthority file, but fails due to the restricted root access on the NFS share.
This was working without problems on feisty, in exactly this configuration. For reasons of security it is probably needles to say that setting no_root_squash option on the NFS share is *no*`option.

Revision history for this message
Joerg Delker (ubuntu-delker) wrote :

blafasel@localhost ~> sudo strace -f xterm

with home on NFS share:
...
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(6010), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(39424), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
getpeername(3, {sa_family=AF_INET, sin_port=htons(6010), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
uname({sys="Linux", node="jake", ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
access("/export/home/blafasel/.Xauthority", R_OK) = -1 EACCES (Permission denied)
writev(3, [{"l\0\v\0\0\0\0\0\0\0\0\0", 12}], 1) = 12
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
read(3, "", 8) = 0
write(2, "X connection to localhost:10.0 b"..., 75X connection to localhost:10.0 broken (explicit kill or server shutdo
wn).
) = 75
exit_group(1) = ?

home on local dir:
...
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(6010), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(60940), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
getpeername(3, {sa_family=AF_INET, sin_port=htons(6010), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
uname({sys="Linux", node="jake", ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
access("/tmp/blafasel/.Xauthority", R_OK) = 0
open("/tmp/blafasel/.Xauthority", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0600, st_size=50, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f9b000
read(4, "\1\0\0\4jake\0\00210\0\22MIT-MAGIC-COOKIE-1"..., 4096) = 50
read(4, "", 4096) = 0
close(4) = 0
munmap(0xb7f9b000, 4096) = 0
writev(3, [{"l\0\v\0\0\0\22\0\20\0\0\0", 12}, {"MIT-MAGIC-COOKIE-1", 18}, {"\0\0", 2}, {"\307\273\303\17\371\334Fcg\32\227+\30\300\212\263", 16}], 4) = 48

Revision history for this message
whyhankee (paul-paulsplace) wrote :

confirmed on Kubuntu Gutsy (even when using kdesu)

Changed in sudo:
status: New → Confirmed
Revision history for this message
whyhankee (paul-paulsplace) wrote :

seems to be fixed on Hardy, can anyone confirm this?

Revision history for this message
jlp (jan-l-peterson) wrote :

FYI, I think this used to work okay in 10.04, but fails in exactly the same way as described above in 12.04.

Note, in 10.04, X was started by gdm and was passed a -auth argument that looked like this:
/var/run/gdm/auth-for-gdm-??????/database
when a user would log in, their XAUTHORITY environment variable was set to point to this same file.

On 12.04, X is started by lightdm with a -auth flag that looks like this:
/var/run/lightdm/root/:0
and when a user logs in, their XAUTHORITY environment variable points to /path/to/home/.Xauthority.

Obviously, in a NFS environment root on a local workstation doesn't have access to the user's home directory, causing the problem.

With gdm, there appeared to be code in /etc/gdm/Init/Default to handle setting the XAUTHORITY variable, and presumably gdm knew how to change the ownership of the database file to the appropriate user when they logged in. lightdm doesn't appear to be as smart as gdm. :-(

I added the following code to my .bashrc file, which seems to work around the problem:
# try to work around Ubuntu 12.04 XAUTHORITY settings
# are we on the console *and* running lightdm *and* root?
if [ `id -u` -eq 0 ]; then
  if [ "$XAUTHORITY" == "$HOME/.Xauthority" ]; then
    if [ "$DISPLAY" == ":0" ]; then
      x_cmd=`ps guaxww | grep /usr/bin/X | grep -v grep`
      case "$x_cmd" in
        *lightdm*)
          XAUTHORITY=`echo $x_cmd | sed -e 's/^.*-auth //' | awk '{print $1}'`
          export XAUTHORITY
          ;;
      esac
    fi
  fi
fi

but it only works for interactive shells, so if I do "sudo bash" and then run X programs, I'm good, but if I do "sudo xprogram", then it still doesn't work.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.