[lkml]   [2002]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2.5.30+] Fourth attempt at a shared credentials patch
>>>>> " " == Dave McCracken <> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.056 / U:0.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site