[PATCH] sys_setpriority() euid semantics fix

What _is_ inconsistent is kernel/sys.c's setpriority()/set_one_prio().

It checks current->euid|uid against p->uid, which makes little sense, but
is how we've been doing it ever since.  It's a Linux quirk documented in
the manpage.  To make things funnier, SuS requires current->euid|uid match
against p->euid.

The patch below fixes it (and brings the logic in line with what
setscheduler()/setaffinity() does), but if we do it then it should be done
only in 2.6.12 or later, after good exposure in -mm.

(Worst-case this could break an application but i highly doubt it: it at
most could deny renicing another task to positive (or in very rare cases,
to negative) nice values, which no application should crash on something
like that, normally.)
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

kernel/sys.c

@@ -216,12 +216,13 @@ int unregister_reboot_notifier(struct notifier_block * nb)
 }
 
 EXPORT_SYMBOL(unregister_reboot_notifier);
+
 static int set_one_prio(struct task_struct *p, int niceval, int error)
 {
 	int no_nice;
 
 	if (p->uid != current->euid &&
-		p->uid != current->uid && !capable(CAP_SYS_NICE)) {
+		p->euid != current->euid && !capable(CAP_SYS_NICE)) {
 		error = -EPERM;
 		goto out;
 	}