Re: [PATCH 2.5.30+] Fourth attempt at a shared credentials patch

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == 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