Description of problem: su will generate this error in /var/log/secure when used in an X environment: su: pam_xauth(su-l:session): fchown: Operation not permitted strace shows: 24129 geteuid32() = 0 24129 setfsuid32(1006) = 0 24129 gettimeofday({1164746295, 904402}, NULL) = 0 24129 open("/home/visitor/.xauthgUmsNS", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 4 24129 setfsuid32(0) = 1006 24129 fchown32(4, 1006, 1009) = -1 EPERM (Operation not permitted) code is: /* Generate a new file to hold the data. */ euid = geteuid(); setfsuid(tpwd->pw_uid); fd = mkstemp(xauthority + strlen(XAUTHENV) + 1); setfsuid(euid); if (fd == -1) { pam_syslog(pamh, LOG_ERR, "error creating temporary file `%s': %m", xauthority + strlen(XAUTHENV) + 1); retval = PAM_SESSION_ERR; goto cleanup; } /* Set permissions on the new file and dispose of the * descriptor. */ if (fchown(fd, tpwd->pw_uid, tpwd->pw_gid) < 0) pam_syslog (pamh, LOG_ERR, "fchown: %m"); close(fd); Version-Release number of selected component (if applicable): pam-0.99.5.0-5.fc5 same code is in development though. How reproducible: every time Steps to Reproduce: 1. In an X environment, su to a different user Now, it seems like this code should work, so maybe it is a kernel/libc issue. Hard to tell if the second setfsuid() worked or not since: On success, the previous value of fsuid is returned. On error, the cur- rent value of fsuid is returned. so the return of 1006 is ambiguous since it could be both the previous value (1006 set above) or the current value (still 1006). Seen with kernels 2.6.18-1.2849.fc6 and 2.6.18-1.2239.fc5, libc glibc-2.4-11 and glibc-2.5-3.
Could it be a SELinux problem? I don't see it on FC6. What happens when you set SELinux to permissive mode?
Ah, it's because we use NFS home directories...
That makes a sense. The error message is harmless then.