![]() | |||||||||||||
Messages in this thread |
[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/ | ||||||||||||
| Last update: 2005-03-22 13:17 [W:1.903 / U:0.130 seconds] ©2003-2008 Jasper Spaans | |||||||||||||