On 28-Mar-00 Stephen C. Tweedie wrote:
> Hi,
>
> On Tue, Mar 28, 2000 at 10:04:58AM -0800, Jeremy Fitzhardinge wrote:
>>
>> Another way of dealing with this is to have local copies of the credentials
>> in
>> each task, as well as the shared credentials, each with change counter.
>
> Eeek. That still leaves the possibility that a setreuid() will leave
> other threads still processing data with the old uid, which probably
> violates posix.
Well, it doesn't matter what uid a thread has if its not in the kernel,
so changes only need to take effect when the uid actually matters.
If the thread is in the kernel at the time some other thread changes the
shared creds, you can't have the UID change under its feet, so it takes
effect next time that thread enters the kernel and needs to use the uid.
> It's also an incredibly ugly solution. Just signal
> each task from in user space to force them to change local uid, and
> you don't need any kernel help whatsoever.
You don't need to signal anything. The threads can poll the shared
credentials when it matters to them, and update their own credentials
as necessary. To an entirely user-bound thread, it doesn't matter if
the shared uid changes a 100 times behind its back. But I agree, it
can be done in user-mode.
> Remember, for things like file server tasks, you _want_ separate
> credentials for each thread, so that individual threads can serve data
> to different uids safely. Putting POSIX uid support into the kernel
> is insane if the functionality isn't performance-critical, since it will
> add complexity to many fast paths in the kernel.
Yes, but it needn't be as complex as putting locking everywhere. In the
case where there was no shared credential change, the fast path is still
pretty fast.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:23 EST