Messages in this thread | | | Date | Mon, 12 Aug 2002 22:08:46 +0200 | Subject | Re: [PATCH 2.5.30+] Fourth attempt at a shared credentials patch | From | Trond Myklebust <> |
| |
>>>>> " " == Dave McCracken <dmccr@us.ibm.com> writes:
> I think I mostly nailed the intermezzo case. I did go through > it.
Are you sure? AFAICS, the intermezzo code assumes that ngroups/groups won't change while you inside the intermezzo layer itself. Look at the way they stuff current->ngroups into the record 'size', then do the actual copy in journal_log_prefix()...
>> Finally, you also want all those reads and changes to more than >> one value in the credential such as the stuff in >> security/capability.c, or net/socket.c,... to be atomic. (Note: >> This is where 'struct ucred' with COW gives you an efficiency >> gain).
> I disagree. It won't generate bogus values of any of these > fields. There may be some cases where it'll pick up a > combination of before and after values, but I don't see where > any of that is fatal.
It doesn't have to be fatal in order to be a security risk. The kernel simply does not know whether or not formula A (random combination of uid/gid/groups) will be secure as opposed to the before/after states. >> Please also note that you only need spinlocking for the >> particular case of tasks that have set CLONE_CRED. In all other >> cases, it adds a rather nasty overhead...
> Spinlock isn't nasty overhead, if it's not contested. It seems > to me that checking whether it's shared is as much overhead as > just taking the lock.
spinlocking is designed so as to invalidate the processor caches.
Cheers, Trond - 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/
| |