Re: [PATCH] new setprocuid syscall

Peter Samuelson (peter@cadcamlab.org)
Tue, 20 Feb 2001 06:52:48 -0600 (CST)


[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
disappearing.

> 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....

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/