>>>>> " " == 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/
This archive was generated by hypermail 2b29 : Thu Aug 15 2002 - 22:00:29 EST