Re: [PATCH] new setprocuid syscall

From: Peter Samuelson (
Date: Tue Feb 20 2001 - 07:52:48 EST

[BERECZ Szabolcs]
> > Race -- you need to make sure the task_struct doesn't disappear out
> > from under you.
> Yes, but we need a write_lock, not a read_lock.

No, it's a read_lock because it is locking the task *list*, which is
not being changed. The only thing being changed is data within a task
struct. The lock is merely to prevent the task itself from

> We need a userspace tool, because we must check if the user, who want
> to change the uid, knows the other user's passwd.
> Or what if user1 want to change user2's process to user3 uid?

That is a mere 'sudo'-type issue -- just a matter of figuring out who
has the right to do this to whom and under what circumstances. Root,
in any case, can do the job without a special tool.

Anyhow, according to Alan bad things can happen if the uid set is
changed unexpectedly. I assume he means certain permissions checks
could be confused by accessing ->euid more than once and getting
different answers. If so, I agree that this is a bad idea....

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Fri Feb 23 2001 - 21:00:22 EST