[PATCH] setuid(2) buggy or bad docs

[PATCH] setuid(2) buggy or bad docs

[John Fremlin]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

setuid(2) differs from the OpenBSD setuid(2) in that -EPERM is
returned by the syscall even if the euid of the process matches the
uid passed to it.

Either I am non compos or the thing is very wrong. The docs
(man-pages-1.35) say

ERRORS
       EPERM  The  user  is  not the super-user, and uid does not
              match the effective or saved user ID of the calling
              process.

The following untested patch changes the kernel to match the
documentated behaviour.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: linux-2.4.4-setuid.patch --]
[-- Type: text/x-patch, Size: 459 bytes --]

--- linux-2.4.4-orig/kernel/sys.c	Tue May  1 14:34:43 2001
+++ linux-2.4.4/kernel/sys.c	Wed Jun 20 01:32:46 2001
@@ -603,7 +603,9 @@ asmlinkage long sys_setuid(uid_t uid)
 		if (uid != old_ruid && set_user(uid, old_euid != uid) < 0)
 			return -EAGAIN;
 		new_suid = uid;
-	} else if ((uid != current->uid) && (uid != new_suid))
+	} else if ((uid != current->uid)
+		   && (uid != new_suid)
+		&& (uid != old_euid))
 		return -EPERM;
 
 	if (old_euid != uid)

[-- Attachment #3: Type: text/plain, Size: 101 bytes --]

-- 
Summer job urgently sought due to last minute visa trouble!
Please see http://ape.n3.net/cv.html

Re: [PATCH] setuid(2) buggy or bad docs

[Andries.Brouwer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 686 bytes --]

> setuid(2) differs from the OpenBSD setuid(2)
> Either I am non compos or the thing is very wrong.
> The docs (man-pages-1.35) say ...

Yes, setuid() has a behaviour that varies a bit from system to system.
Moreover, it has varied in the history of Linux. The manpage may have
been correct when it was written, but it is not today, and I just
fixed it.

ERRORS
       EPERM  The  user  is  not the super-user, and uid does not
              match the real or saved user ID of the calling pro­
              cess.

Our norm is the coming POSIX standard, roughly the Austin 7 draft,
which again is based on the SUSv2. According to this, the current
kernel code is correct here.

Andries