Red Hat Bugzilla – Bug 107718
lstat() claim files owned by users with uid>64k are owned by nfsnobody
Last modified: 2013-03-06 00:56:16 EST
Description of problem:
Files and processes owned by users with uids above 64k are claimed to
be owned by user nfsnobody. Having traced this further, the correct
owner seem to be stored in the kernel and on the file system (both local
file system and NFS). The problem seem to be incorrect values retured
by lstat() (and probably the other stat-like syscalls as well).
I've written a small shell script demonstrating the problem.
Version-Release number of selected component (if applicable):
This is the kernel version on a test machine I used to isolate the
problem. We have this problem on all our ia64 systems with RedHat
Linux draco.uio.no 2.4.18-e.31smp #1 SMP Wed May 21 17:47:59 EDT 2003
Happen every time.
Steps to Reproduce:
I'll attach a small script demonstrating the problem in /tmp/. We
discovered it first on users home directories accessed over NFS,
but I wanted to provide a small self-contained test script.
Created attachment 95385 [details]
Shell script demonstrating the problem.
Run script as root on a system to check if the problem exist there.
The reason for this problem seem to be that the ia64 KERNEL is
compiled with the config flag CONFIG_UID16 set to 'y', and this
make the kernel truncate UIDs. I found more info on the problem at
<URL: http://www.x86-64.org/lists/discuss/msg04027.html>. That messsage
is related to x86_64, but the information seem to apply to ia64 as well.
This issue give a some of the machines used by the High Performance
Computing Group at the University of Oslo problems with its users. To
keep the support from RedHat and HP, we need to use a official kernel
and it is thus not an option to compile our own kernel.
ok, i agree with the first approach mentioned on the x86_64 list. That is, we
should not set CONFIG_UID16=y, and instead fix up the ia32 emulation code. I'll
post a patch shortly.
ok, so i disabled CONFIG_UID16, and applied the following patch. The test case
provided now works much better. nice test program! These changes are being
considered for U3 inclusion.
--- linux/arch/ia64/ia32/sys_ia32.c.orig 2003-10-22 17:28:59.000000000 -0400
+++ linux/arch/ia64/ia32/sys_ia32.c 2003-10-22 17:38:27.000000000 -0400
@@ -76,6 +76,25 @@
#define PAGE_OFF(addr) ((addr) & ~PAGE_MASK)
#define MINSIGSTKSZ_IA32 2048
+/* backwards compatability for 16-bit uids */
+#define high2lowuid(uid) ((uid) > 65535) ? (u16)overflowuid : (u16)(uid)
+#define high2lowgid(gid) ((gid) > 65535) ? (u16)overflowgid : (u16)(gid)
+#define low2highuid(uid) ((uid) == (u16)-1) ? (uid_t)-1 : (uid_t)(uid)
+#define low2highgid(gid) ((gid) == (u16)-1) ? (gid_t)-1 : (gid_t)(gid)
+extern int overflowuid,overflowgid;
+typedef u16 old_uid_t;
+typedef u16 old_gid_t;
extern asmlinkage long sys_execve (char *, char **, char **, struct pt_regs *);
extern asmlinkage long sys_mprotect (unsigned long, size_t, unsigned long);
extern asmlinkage long sys_munmap (unsigned long, size_t);
@@ -86,6 +105,8 @@ extern unsigned long arch_get_unmapped_a
asmlinkage long sys32_mprotect (unsigned int, unsigned int, int);
asmlinkage unsigned long sys_brk(unsigned long);
* Anything that modifies or inspects ia32 user virtual memory must hold this
* while doing so.
@@ -185,8 +206,8 @@ putstat (struct stat32 *ubuf, struct sta
err |= __put_user(kbuf->st_ino, &ubuf->st_ino);
err |= __put_user(kbuf->st_mode, &ubuf->st_mode);
err |= __put_user(kbuf->st_nlink, &ubuf->st_nlink);
- err |= __put_user(kbuf->st_uid, &ubuf->st_uid);
- err |= __put_user(kbuf->st_gid, &ubuf->st_gid);
+ err |= __put_user(high2lowuid(kbuf->st_uid), &ubuf->st_uid);
+ err |= __put_user(high2lowgid(kbuf->st_gid), &ubuf->st_gid);
err |= __put_user(kbuf->st_rdev, &ubuf->st_rdev);
err |= __put_user(kbuf->st_size, &ubuf->st_size);
err |= __put_user(kbuf->st_atime, &ubuf->st_atime);
Can we get a better desciption of the severity of this issue? As this is fixed
in the current 3.0 release.
An upgrade to 3.0 is an acceptable solution.
This fix is in the currently testing RHEL 2.1 beta, which is scheduled
to ship shortly. RHEL 3 should already be immune to this issue.
An errata has been issued which should help the problem described in this bug report.
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen
this bug report if the solution does not work for you.